클린코드

성능이 나쁜 코드불필요한 연산이 들어가서 개선의 여지가 있는 코드의미가 모호한 코드이해하기 어려운 코드, 네이밍과 그 내용이 다른 코드중복된 코드비슷한 애용인데 중복되는 코드들은 버그를 낳는다.나쁜 코드는 깨진 유리창 처럼 계속 나쁜 코드가 만들어지도록 한다.나쁜 코드

SOLID 란?클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 제시한 내용을 포스팅하도록 하겠다.한 클래스는 하나의 책임만 가져야 한다클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.SRP 책

코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다.자신이 저지른 난장판을 주석으로 설명하지 말고 개선하는데 시간을 보내야 한다.코드의 변화에 따라가지 못하고, 주석은 방치된다.코드는 컴파일되어 호출되지만, 주석은 그저 주석이기 때문에 그 자리에 방치되

내 for 문은 뭐지..?이제 이해하기 좋다!코드를 수월하게 읽어나갈 수 있다.아마추어처럼 보이지 않는다.포맷팅으로 인해 코드를 잘못해석해 버그를 발생할 위험을 줄인다!~200 lines < 500 lines"코드 길이를 200줄 정도로 제한하는 것은 반드시 지킬

절차적인 코드는 새로운 자료구조를 추가하기 어렵다. 함수를 고쳐야 한다.객체지향 코드는 새로운 클래스를 추가하기가 쉽다. 하지만 함수를 추가해야 한다.자료구조를 사용하는 절차적 코드는 기본 자료구조를 변경하지 않으면서 새 함수를 추가하기가 쉽다.절차적인 코드는 새로운

옛날에는 오류를 나타낼 때 에러코드를 던졌다.하지만 예외를 던지는 것이 명확하고, 처리 흐름이 깔끔해진다.오류가 발생한 부분에서 예외를 던진다. (별도의 처리가 필요한 예외라면 checked exception으로 던진다.)checked exception에 대한 예외처리

오픈소스, 라이브러리를 안쓰는 프로젝트는 없다.우리가 만든 코드에 외부에서 들어온 코드를 병합해야 한다.외부 코드는 외부에서 만든 코드인데, 외부 시스템과 호출하거나 단순히 외부에서 만들어진 코드일 수 있다.우리 코드와 외부 코드를 깔끔하게 통합시키기 위해 경계를 잘

테스트 코드는 실수를 바로 잡아준다.테스트 코드는 반드시 존재해야하며, 실제 코드 못지 않게 중요하다.테스트 케이스는 변경이 쉽도록 한다. 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트다. 테스트 케이스가 있으면 변경이 두렵지 않다. 테스트

객체의 실제 구현을 외부로부터 감추는 방식클래스를 개발할 때 기본적으로 구현을 감추고, 외부 객체와 상호작용하는 부분만 노출한다.외부의 잘못된 사용을 방지한다.경계에서 배웠던 부분! MapStack 예제필드를 private로 제한, get으로 읽기수정은 push, po

소프트웨어 시스템은 (어플리케이션 객체를 제작하고 의존성을 서로 연결 하는) 준비 과정과 (준비 과정 이후에는 이어지는) 런타임 로직을 분리해야 한다.객체의 생성과 객체를 사용하는 부분을 분리한다.시작 단계는 모든 어플리케이션이 풀어야할 관심사이다.main 함수에서 시

하위 계층에는 없는 특성이나 행동이상위 계층(전체 구조)에서 자발적으로 돌연히 출연하는 현상.각각의 개미는 집을 지을 능력이 없지만, 작은 개미들의 상호작용을 통해 집이라는 결과물이 나오는 것처럼작은 요소들의 상호작용의 반복이 전체구조에 영향을 미친다단순한 4가지를 반

외부 서비스의 응답을 기다리면서 아무일도 하지 않으면 CPU 사이클이 낭비된다.낭비되는 자원을 줄이자!내 어플리케이션의 효율성을 높여야 한다.더불어 내 어플리케이션이 동작하는 머신의 환경이 효율적으로 돌아가도록내 어플리케이션에 메모리 누수나 자원이 낭비되지 않도록 신경