목차

1. 추천사
2. 들어가면서
3. 깨끗한 코드

앞으로 Clean Code를 읽으며 중요하다고 생각되는 부분의 글 내용을 작성하며, 동시에 중간중간 내 느낀 점과 요약한 내용을

이 공간 안에 적을 것입니다.

참고하여 보시면 감사하겠습니다.

1. 추천사

• "사소한 곳에서 발휘하는 정직은 사소하지 않다"

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

• 1951년 TPM(Total Productive Management)이라는 품질 관리론이 일본 업계에 등장했다.
  TPM은 생산이 아니라 유지보수에 초점을 맞췄다.
  TPM을 지탱하는 기둥 하나는 5S 원칙이다.

  1. Sort(정리, 또는 조직): 적절한 명명법 등과 같은 방법을 사용해 무엇이 어디에 있는지 알아야 한다.
  2. Seiton(정돈, 또는 단정함): 코드는 누구나 예상하는 위치에 있어야 한다.
  3. Seiso(청소, 또는 정리): 과거 이력이나 미래 바람을 기억한 주석, 혹은 주석으로 처리한 코드는 제거한다.
  4. Seiketsu(청결, 또는 표준화): 그룹 내에서 일관적인 구현 스타일과 기법의 필요성을 뜻한다.
  5. Shutsuke(규율, 또는 생활화): 관례를 따르고, 자기 작품을 자주 돌아보고, 기꺼이 변경하는 규율을 뜻한다.

• "청결은 경건과 마찬가지이다.", "작은 것에도 충실한 사람이 큰 것에도 충실하다.", "호미로 막을 일을 가래로 막지마라.", "일찍 일어나는 새가 벌레를 잡는다.", "오늘 할 수 있는 일을 내일로 미루지 마라.", "티끌 모아 태산이다.", "유비무환", "일일 만보면 무병장수다." ...

  결국 섬세함, 꾸준함, 정직함을 강조한다.

2. 들어가면서

• 올바른 코드를 짜기 위해서는 장인 정신이 필요하다.
  이 장인 정신을 익히는 과정은 이론과 실전으로 나뉜다.
  우선, 장인에게 필요한 원칙, 패턴, 기법, 경험이라는 지식을 습득한다. 그리고 습득한 지식을 바탕으로 꾸준히 연습하여 지식을 몸과 마음으로 체득한다.

  이 책이 그 과정을 도와줄 것이다.

• 깨끗한 코드를 작성하는 방법은 매우 어렵다.
  단순히 지식을 알고있다고 깨끗한 코드가 나오지 않는다. 고생을 해야 한다.

3. 깨끗한 코드

나쁜 코드

• 80년대 후반, 유명한 앱을 구현한 회사가 있다. 이 앱은 엄청난 인기를 끌었으며 수많은 전문가가 구매해 사용했다.
  그런데 제품 출시 주기가 점차 늘어지고, 이전 버전에 있었던 버그가 다음 버전에도 그대로 남아있었다.
  프로그램 시동 시간도 길어지고 프로그래밍 죽는 횟수도 늘어났다. 회사는 얼마 못가 망했다.

  20여년이 지난 후 그 회사 초창기 직원을 우연히 만나 자초지종을 들었다.
  그들은 출시에 바빠 코드를 마구 짰다.
  기능을 추가할 수록 코드는 엉망이 되어갔고, 결국은 감당이 불가능한 수준에 이르렀다.
  회사가 망한 원인은 바로 나쁜 코드 탓이었다.

• 우리는 모두 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다.
  나중은 결코 오지 않는다.

  르블랑의 법칙

• 빨리가는 유일한 방법은, 언제나 코드를 최대한 **깨끗하게 유지하는 습관이다.

깨끗한 코드란?

• 비야네 스트롭스트룹 (C++ 창시자):

  1. 나는 우아하고, 효율적인 코드를 좋아한다.
  2. 논리가 간단해야 버그가 숨어들지 못한다.
  3. 의존성을 최대한 줄여야 유지보수가 쉬워진다.
  4. 깨끗한 코드는 한 가지를 제대로 한다.

  여기서 '우아한' 이라는 단어가 사용된다.
  우아한이란, 외양이나 태도가 기품있고 단아하며 보기에 즐거운, 교모하고 단순해 보기에 즐거운이라는 뜻이다.
  결국 비야네가 말하는 깨끗한 코드는 보기에 즐거운 코드이다.

  또한 효율이 떨어지는 (메모리를 낭비하거나, CPU 자원을 낭비하는) 코드는 우아하지 못하다.

• 그래디 부치(Object Oriented Analysis and Design with Application 저자):

  1. 깨끗한 코드는 단순하고 직접적이다.
  2. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
  3. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.

  가독성을 강조한다.
  그리고, 코드는 추측이 아니라 사실에 기반해야 한다.
  반드시 필요한 내용만 담아야 한다.

• '큰' 데이브 토마스 (OTI 창립자이자 이클립스 전략의 대부):

  1. 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
  2. 깨끗한 코드에는 의미 있는 이름이 붙는다.
  3. 특정 목정을 달성하는 방법은 하나만 제공한다.
  4. 의존성은 최소이며 각 의존성을 명확히 정의한다.
  5. 코드는 문학적으로 표현해야 마땅하다.

  마찬가지로 가독성을 강조하지만, 특별히 다른 사람이 고치기 쉽다고 단언한다.
  실제로 읽기 쉬운 코드와, 고치기 쉬운 코드는 엄연히 다르다.

• 마이클 페더스 (Working Effectively with Legacy Code 저자):

  1. 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다.
     고치려고 살펴봐도 딱히 손 댈 곳이 없다.
     작성자가 이미 모든 사항을 고려했으므로, 고칠 궁리를 하다보면 언제나 제자리로 돌아온다.

  한 마디로 요약하면 '주의'이다.
  저자가 말하길, 이 책의 부제를 붙이라면 '코드를 주의 깊게 짜는 방법'이 적당하겠다고 한다.

• 론 제프리스 (Extreme Programming Installed 와 Extreme Programming 저자):

  1. 모든 테스트를 통과한다.

  2. 중복이 없다.

  3. 시스템 내 모든 설계 아이디어를 표현한다.

  4. 클래스, 메서드, 함수 등을 최대한 줄인다.

     같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다.

     프로그래밍을 공부하는 사람이라면 코드의 중복에 대한 경계심은 항상 있을 것이다.

     저자에게 있어 표현력은 의미 있는 이름과 여러 기능을 수행하는 객체나 메서드이다.
     객체가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러 개로 나눈다.

     중복과 표현력만 신경 써도 깨끗한 코드라는 목표에 성큼 다가선다.
     지저분한 코드를 손볼 때 이 두 가지만 고려해도 코드가 크게 나아진다.
     여기에 추가로 초반부터 간단한 추상화 고려하기까지 포함한 것이, 저자의 깨끗한 코드를 만드는 비결이다.

     중복을 제거하고, 이름 잘 짓고, 클래스나 메서드를 인터페이스와 구현체로 나눈다.

• 워드 커닝햄 (위키 창시자, 코드를 사랑하는 프로그래머들의 대부):

  1. 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라고 불러도 되겠다.
     코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.

우리는 저자다

Javadoc에 @author 필드는 저자를 소개한다. 우리는 저자다. 저자에게는 독자가 있다.
그리고 저자에게는 독자와 잘 소통할 책임도 있다.

이 글을 읽고 코드를 짜는 것이, 단순히 기계에 명령을 하는 것이 아니라 하나의 글쓰기. 또는 하나의 예술 행위로 봐도 무방하다고 느꼈다.
앞으로 나를 위한 코드가 아닌 읽는 사람을 위한 코드를 짜도록 열심히 노력해봐야겠다.

새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.
기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다.

보이스카우트 규칙

"캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라."

체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.
한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.
변수 이름을 하나 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문을 하나로 정리하면 충분하다.

사소함과 정직함을 또 다시 강조하는 듯 하다.

지금까지 있었던 깨끗한 코드에 대해 종합하자면 공통적으로
코드를 보기 좋게, 읽기 쉽게, 단순명료하게, 친절하게, 주의깊게 짜야 한다. 추가로 이름을 잘 붙이고, 중복이 없어야 한다는 것이다.

그리고 사실 여기까지 읽으면서도 느낀 바가 많았다.
최근 알고리즘 문제를 해결함에 있어 제한된 시간안에 주어진 문제를 해결하기 위해 코드를 조금 더럽게 짜는 경우가 생긴다.
실제로 그럴 때마다 항상 디버깅하는 것이 문제였고, 문제 해결에 있어 어려움을 겪었다.
사실 여기서 언급한 이름을 잘 짓고, 다른 사람이 읽었을 때에도 수정하기 쉬운 코드 짜기를 전부터 신경써 왔지만 알고리즘 문제의 경우 문제를 해결하면 끝인 경우가 있었다.
이제부터는 코드를 간결히 짜고