[책] Clean Code, 로버트 C. 마틴, 인사이트, 2013

Summary

• 저자가 스스로 서술한 대로, '열심히 독파해야 하는 책'이라고 동의함

Site

• 책 소개 링크1: http://book.naver.com/bookdb/book_detail.nhn?bid=7390287
• 책 소개 링크2: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/

Note

• 서문: ... 스크럼과 애자일에 관심이 모아진 현재는 '제품'을 신속하게 시장에 출시하는 방법론을 강조한다. ... 스크럼은 이런 일본 자동차 제조업, 즉 생산 라인의 세계에서 많은 영향을 받았다. ... 하지만 심지어 자동차 업계도 대다수 활동은 제조가 아니라 유지보수다. ... 소프트웨어는 80% 이상이 소위 "유지보수"다.

• 서문: TPM(Total Productive Management)에서의 5S 원칙 --> 이후 Lean의 토대가 됨
• - 정리(Seiri) / 조직 / 정렬(Sort)
• - 정돈(Seiton) / 단정함 / 체계화
• - 청소(Seiso) / 정리 / 광내기
• - 청결(Seiketsu) / 표준화
• - 생활화(Shutsuke) / 규율

• p4. Leblanc's Law - 나중은 결코 오지 않는다.
• p7. 기한을 맞추는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관
• p8. Literate Programming - 인간이 읽기 좋은 코드를 작성하라
• p9. 깨끗한 코드 = '보기에 즐거운' 코드
• p22. "의도가 분명하게 이름을 지으라" : 변수, 함수, 클래스 이름
• p44. 함수는 한 가지를 해야하 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
• p49. 서술적인 이름을 사용하라
• p54. 부수 효과를 일으키지 마라. -> 함수는 하나의 작업만 하도록 구성할 것
• p60. 반복하지 마라. -> 코드의 중복을 없애기
• p61. 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다.

• [KP78] Kernighan and Plaugher, The Elements of Programming Style, 2d. ed., 1978

• p110. ... 선언문과 할당문을 별도로 정렬하지 않는다. 정렬하지 않으면 오히려 중대한 결합을 찾기 쉽다. (코드 내부의) 선언문 정렬이 필요할 정도로 목록이 길다면, 문제는 목록의 길이지 정렬 부족이 아니다.
• p119. 자료 추상화 -> 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. ... 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다.
• p155. TDD 법칙 세가지
• 1) 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
• 2) 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
• 3) 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
• p157. 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
• p164. (가능하다면) 테스트 당 assert 하나
• - given-when-then 관례를 사용하면 테스트 코드를 읽기는 쉽지만, 중복되는 테스트 코드가 많아짐
• p166. 테스트 당 개념 하나씩 테스트하는 것이 바람직
• p167. F.I.R.S.T
• - Fast, Independent, Repeatable, Self-Validating, Timely
• p221. 표현하라.
• 1) 좋은 이름을 선택한다.
• 2) 함수와 클래스 크기를 가능한 줄인다.
• 3) 표준 명칭을 사용한다.
• 4) 단위 테스트 케이스를 꼼꼼히 작성한다.
• * 나중에 읽을 사람을 고려해 조금이라도 읽기 쉽게 만들려고 노력한다.
• p321. 나쁜 일정은 다시 짜면 된다. 나쁜 요구사항은 다시 정의하면 된다. 나쁜 팀 역학은 복구하면 된다. ... 나쁜 코드도 개선할 수 있다. 단, 비용이 엄청나게 많이 든다.