클린코드

모든 테스트를 통과한다.중복이 없다.시스템 내 모든 설계 아이디어를 표현한다.클래스, 메서드, 함수 등을 최대한 줄인다.

의도가 명확한 이름 짓기재미난 이름보다 명료한 이름을 선택하라그릇된 정보를 피하라약어 사용하지 않기흡사한 이름을 사용하지 않도록 주의의미있게 구분하라컨테이너 유형(List, Array, ...)을 변수명에 넣지 않는 편이 바람직customerInfo/customer,

20줄도 길다if/else/while 문 등에 들어가는 블록은 한 줄이어야 한다중첩 구조가 생길만큼 함수가 커져서는 안된다의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다내려가기 규칙: 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.

나쁜 코드에 주석을 달지 마라. 새로 짜라자신이 저지른 난장판을 주석으로 설명하려 애쓰는 시간에 깨끗이 치우자법적인 주석 - 첫머리의 저작권 정보, 소유권 정보정보를 제공하는 주석 - 그래도 가능하면 함수 이름에 정보를 담는편이 좋다의도를 설명하는 주석의미를 명료하게

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다.일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다신문 기사처럼 작성하라 개념은 빈 행으로 분리하라일련의 행 묶음은 완결된 생각 하나를 표현한다. 생각 사이는 빈 행을 넣어 분리해야 마땅하다세로 밀집도줄바꿈이 개념을

추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.인터페이스나 조회/설정 함수만으로는 추상화가 이루어지지 않는다.개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 고민해야 한다.객체 지향 코드에서 어려운 변

오류 코드 대신 예외를 던지자확인된 예외를 사용하면 throws 경로에 위치하는 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다.일반적인 애플리케이션은 의존성이라는 비용이 이익보다 크다.예외를 던질 때는 전후 상황을 충분히 덧붙인다.오류 메세지

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다외부 코드를 우리 코드에 깔끔하게 통합해야 한다.Map(혹은 유사한 경계 인터페이스를)을 이용하는 클래스나 클래스 계열 밖으로 노출하지 않도록 주의외부 패키지 테스트가 우리 책임은 아니지만 우리가 사용할 코

실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.지저분한 테스트 코드는 테스트를 안하는 것보다 못하다.테스트 코드는

변수 목록 -> 정적 공개 상수 -> 정적 비공개 변수 -> 비공개 인스턴스 변수 -> 공개 함수 -> 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다추상화 단계가 순차적으로 내려간다.클래스도 함수와 마찬가지로 '작게'가 기본 규칙이다.함수는 물리적인 행 수로

"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다."시스템 수준에서 깨끗함을 유지하는 방법제작과 사용은 아주 다르다는 사실을 명심한다.소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비

창발적 설계로 깔끔한 코드를 구현하자모든 테스트를 실행한다.중복을 없앤다.프로그래머의 의도를 표현한다.클래스와 메서드 수를 최소로 줄인다.테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다.결합도가 높으면 테스트 케이스를 작성하기 어렵다 \- DIP

객체는 처리의 추상화다. 스레드는 일정의 추상화다.동시성과 깔끔한 코드는 양립하기 아주 어렵다동시성은 결합(Coupling)을 없애는 전략이다.무엇과 언제를 분리하는 전략이다.응답 시간과 처리량 개선많은 사용자를 동시에 처리하면 시스템 응답 시간을 높일 수 있다.대량의