범위

1. 추천사

2. 0장. 들어가면서

3. 1장. 깨끗한 코드

추천사

책임있는 전문가라면 프로젝트를 시작할 때 생각하고 계획할 시간을 확보해야 한다.

소프트웨어는 80% 이상이 소위 “유지보수”다.

0장. 들어가면서

• 장인정신 = 이론 + 실전

• 이 책을 그저 “기분 좋은 책”으로 읽지 마라.

  1장. 깨끗한 코드

코드가 존재하리라

• 코드가 종말할 리는 없다. 인간조차도 고객의 막연한 기대만으로 성공적인 시스템을 구현할 수 없기 때문이다.

• 코드는 요구사항을 표현하는 언어!

르블랑의 법칙 ; 나중은 결코 오지 않는다.

각자가 정의하는 깨끗한 코드

바야네 스트롭스트룹: 깨끗한 코드란 한 가지를 잘 한다

그래디 부치: 깨끗한 코드는 잘 쓴 문장처럼 읽힌다

큰 데이브 토마스: 깨끗한 코드란 다른 사람이 고치기 쉽다

마이클 페더스: 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다

워드 커닝햄: 깨끗한 코드는 짐작했던 그대로 기능한다

보이스카우트 규칙 ; 캠핑장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

💡 부끄럽지만 후배 생각이 많이 났다. 나는 아무것도 모르고 개발을 시작했다. 그리고 어쩌면 아직은 숨이 붙어 있었을 프로젝트를 넘겨받아 결국은 끔찍한 괴물을 만들었다. 내내 탓했다. 그것은 처음부터 프로젝트를 철학 없이 만든 사람의 잘못이라고. 후배가 생기고 난 뒤에야 알게되었다. 프로젝트를 망친 사람은 나라는 것을. 내가 “유지보수”가 훨씬 중요하다는 것을 망각했기 때문에 현재의 요구사항을 도저히 충족할 수 없는 처음의 프로젝트 설계를 계속 붙잡고 늘어졌다. 프로젝트를 넘겨받은 후배는 나보다 더 명석한 아이였다. 무엇이 문제인지 빠르게 찾아내고 끊임없이 나를 몰아붙였다. 나는 받아칠 수가 없었다. 개발하면서 그런 고민을 해본 적이 없었으니까. 남의 손에서 속수무책 쏟아져 나오는 나의 실수와 무지는 정말 너무나 쓰라렸다… ”사고는 수습이 더 중요하다.” 내가 아르바이트를 하면서 가장 크게 얻은 교훈이다. 코드도 마찬가지가 아닌가 싶다. 이제까지 수도 없는 많은 사고를 코드 안에서 치고 다녔다. 개과천선 할 나 자신. 이제 내가 할 일은 매 개발마다, 온 힘을 다해, 장인정신으로, 내가 구현해야하는 요구사항을 아주 심플하지만 정교한 예술로 만들도록 노력하는 것이다. 르블랑…. 나중은 어떻게든 오긴 오더라…. 기획자가 저얼대 안 바뀐다던 그 영역…. 미안하다며 기획요청서 날리는 모습을 내가 무수히 봤다…. 그 때를 노려 보여줄게 달라진 내 코드….