0장. 들어가기 전에 - 1

들어가기 전에

2010년 번역판 옮긴이 서문

이 책은 평상시에 놓치기 쉽고 실수하기 쉬운 여러 가지 패턴을 실제 예를 들면서 소개하고 있기에 어느 정도 자바 프로그램에 익숙한 사람이 보면 느끼는 바가 많을 것이다... 그런데 이 책은 대충 읽고 넘기는 책이 아니다.
...
개인적으로 프로그래밍 실력은 계단식으로 성장한다고 생각한다... 프로그램을 잘 짜는 사람과 같이 일하면 가장 좋다. 같이 일하면서 그 사람이 생각하는 방식을 배운다면 프로그래밍 실력이 순식간에 껑충 뛴다. 그게 어려우면 남이 잘 짜놓은 프로그램을 보는 방법이 효과적이다.

추천사

사소한 것은 중요하다. 이 책은 사소한 듯 보이나 실제로는 사소하지 않은 내용을 다룬다. 신은 세세함에 깃들어 있다... 세세함에 주의를 기울이는 태도는 (그 어떠한 비전보다) 전문가에게 더더욱 필수적인 자질이 되었다.
...
소프트웨어는 80% 이상이 소위 "유지보수"다. 좋은 소프트웨어를 만드려면 좀 더 건축 업계의 수리공이나 자동차 업계의 수리공처럼 생각해야 한다. 일본 관리층은 뭐라고 말할까?
1951년 TPM(Total Productive Management)라는 품질 관리론이 등장했다. TPM은 생산이 아닌 유지보수에 초점을 맞춘 5S 원칙을 제시했다. 5S 원칙은 사실상 린(Lean)의 토대다. 5S원칙은 선택이 아니라 필수다.

1. 정리(조직, 정렬): 적절한 명명법 등
2. 정돈(단정함, 체계화): 코드는 누구나 예상하는 위치에 있어야 한다.
3. 청소(정리, 광내기): 과거 이력이나 미래 바람을 기억한 주석, 혹은 주석으로 처리한 코드는 제거하기 바란다.
4. 청결(표준화): 작업 공간을 청소하는 방식에 그룹이 동의한다.
5. 생활화(규율): 관례를 따르고, 자기 작품을 자주 돌아보고, 기꺼이 변경하는 규율

책임있는 개발자라면 제품 생명주기까지 고려해야 한다는 의미이다.

모든 설계 행위는 작은 규모로 이뤄지는 국부적인 수리 행위이며, 전체 구조를 훌륭히 만드는 것만이 장인으로서 건축가가 유일하게 해야 할 역할의 범위이다.
- 크리스토퍼 알렉산더

품질은 하늘에서 뚝 떨어진 위대한 방법론이 아니라 사심 없이 기울이는 무수한 관심에서 얻어진다.
우리는 우리 코드를 숭고한 설계 노력이 낳은 아름다운 산물로 봐야 한다. 설계는 과정이지 고착된 종착점은 아니다.
- 제임스O. 코플리엔

들어가면서

깨끗한 코드를 작성하는 방법은 배우기 어렵다... 고생을 해야 한다. 이 책을 읽는 동안 마음 고생할 준비를 하기 바란다... 이 책은 세 부분으로 나눠진다.

처음 몇 장은 깨끗한 코드를 작성하는 원칙, 패턴, 실기를 설명한다.
둘째 부분은 좀 더 어렵다. 여러 사례 연구를 소개하는데, 문제가 있는 코드를 문제가 더 적은 코드로 바꾸는 연습이다. 상세히 살펴보려면 집중력이 필요하다.
셋째 부분은 결말이다. 사례 연구를 만들면서 수집한 냄새와 휴리스틱(heuristic, 사람들이 발견한 해결법 등)을 마지막 장에서 열거한다.

휴리스틱 자체가 아닌, 사례 연구에서 코드를 정리하면서 내린 각 결정과 휴리스틱 사이의 관계가 중요하다.

코드가 존재하리라

프로그래밍: 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업
코드: 프로그래밍을 통해 명시한 결과

나쁜 코드

리팩토링을 일로 주는 회사는 없다.

우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다(leblan'c Law).

나쁜 코드로 치르는 대가

태도

코드가 왜 그렇게 되었을까? 우리는 멍청한 관리자와 조급한 고객과 쓸모없는 마케팅 부서 탓이라고 돌리지만, 그들에게는 잘못이 없다. 그렇다 관리자와 마케팅은 우리에게 정보를 구한다. 우리에게 정보를 구하지 않더라도 우리가 적극적으로 정보를 제공해야 마땅하다. 

"아니 잠깐만요! 상사가 시키는 대로 하지 않으면 짤린다구요!"

글쎄다. 대다수 관리자는 진실을 원한다. 좋은 코드를 원한다... 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.