"기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다. 이렇게 명시한 결과가 바로 코드다." (p.2)
💻 의도를 분명히 밝혀라 💻 그릇된 정보를 피하라
"함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다." (p.42) "함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다." (p.44)
"자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에 그 난장판을 깨끗이 치우는 데 시간을 보내라!" (p.69)
"코드 형식은 의사소통의 일환이다." (p.96) "신문이 사실, 날짜, 이름 등을 무작위로 뒤섞은 긴 기사 하나만 싣는다면 아무도 읽지 않으리라." (p.98)
"변수를 private으로 선언하더라도 각 값마다 getter, setter 함수를 제공한다면 구현을 외부로 노출하는 셈이다. 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다." (p.119)
논리 코드와 오류 코드를 분리하라. 각 개념을 독립적으로 살펴보고 이해할 수 있도록 하라. 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 하는 코드를 작성하라.
🚩 외부 코드를 기존 코드에 깔끔하게 통합하는 기법
실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
"도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?" (p.177)
"체계적이고 탄탄한 시스템을 만들고 싶다면 흔히 쓰는 좀스럽고 손쉬운 기법으로 모듈성을 깨서는 절대로 안 된다." (p.196)
단순하지만 중요한 네 가지 규칙을 따라 설계를 하면, 창발성이 촉진되어 우수한 설계를 완성할 수 있게 된다.
"프로그래밍은 과학보다 공예에 가깝다. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다." (p.254)