7p. 우리 모두는 자신 이 짠 쓰레기 코드를 쳐자보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간가는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 아중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않았다.
정말 나중은 오지 않는다,,, 개인 프로젝트라면 진짜 나중이 없다.
11p. 실제로 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다!
이 책을 처음 읽었을 때 이 말을 제대로 이해하지 못했던 것 같다. 그때는 추상화라는 것을 이해하지 못했으니 당연히 의존적인 코드도 몰랐고, 읽기 쉽다고 너가 고칠 수 있는 건 아니니까 직접 고쳐 봐라라는 의미로만 받아들였다.
지금은 인터페이스 없는 의존적인 코드도 이름을 잘 지으면 읽기 쉬운 코드일 수도 있다는 의미로 받아들여진다.
p19. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.
깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다. -그래디 부치
<좋은 코드 규칙>
- 중복을 피하기
- 한 기능만 수행
- 짐작했던 기능을 그대로 수행하도록 의미있는 이름 짓기
- 초반부터 간단한 추상화 고려하기 (일단은 추상클래스, 추상메서드로 만들고 필요한 부분만 구현해놓은 후 나중에 마저 구현하기)
