[BOOK - 클린코드] Chapter 1. 깨끗한 코드

코드는 존재하리라

---

• 코드를 자동으로 생성하는 시대가 오더라도 프로그래머가 필요 없다는 말은 헛소리이다.
  • 요구사항을 모호하게 줘도 우리 의도를 정확히 꿰뚫어 프로그램을 완벽하게 실행하는 기계는 절대로 불가능한 기대이다.
• 코드는 요구사항을 상세히 표현하는 수단이다.
  • 추상화도 불가능하다. 정확히 명시해야만 한다.
• 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 '프로그래밍'이다.

 

나쁜 코드

• 나쁜 코드로 만들어진 서비스나 제품은 회사가 망할 정도의 타격을 입는다.
• 우리 모두는 어떤 이유(바쁨, 마감 기한 등)로 인해 대충 짠 프로그램을 나중에 손 보겠다고 한다.
  • 하지만 르블랑의 법칙에 의해 나중은 결코 오지 않는다.

 

나쁜 코드로 치르는 대가

• 나쁜 코드가 쌓일 수록 팀 생산성은 떨어지며 결국은 생산성이 제로에 수렴한다.
  • 생산성을 증가시키려고 나름대로 인력을 증원시킨다.
  • 하지만 새로 투입된 인력은 시스템 설계에 대한 조예가 깊지 않고, 성과에 대한 압박에 시달려 결국은 나쁜 코드를 더 많이 생산한다.

 

원대한 재설계의 꿈

• 더 이상 답이 보이지 않을 땐 팀을 재구성해 고도화 작업을 진행한다. 하지만 그 마저도 쉽지 않다.
  • 기존 시스템 기능과 변경 사항까지 모두 제공해야 기존 시스템을 대체할 수 있다.
  • 새 시스템이 기존 시스템을 따라잡을 즈음이면 초창기 팀 인력들은 많이 사라져 있다.
  • 결국 새 시스템도 나쁜 코드로 변질되고, 다시 새롭게 새 시스템을 설계하는 악순환을 반복한다.
• 결국 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이다.

 

태도

• 어떤 이유가 있더라도 좋은 코드를 사수하는 일은 프로그래머들의 책임이다.
  • 일정과 요구사항을 강력하게 밀어붙이는 이해관계자들은 그것이 그들의 책임이기 때문에 그렇다.
• 비유를 들어, 수술을 받아야 할 환자가 시간이 오래 걸린다고 위생을 신경쓰지 말라고 해도 의사는 위생을 신경써야 한다.

 

원초적 난제

• 기한을 맞추려면 빨리 가려고 시간을 들이지 못하고, 나쁜 코드를 양산할 수 밖에 없다고 느낀다.
• 하지만 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다.
• 기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

 

깨끗한 코드라는 예술

깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷하다. 그림을 보면 대부분의 사람은 잘 그렸는지 엉망으로 그렸는지 안다. 그렇지만 잘 그린 그림을 구분하는 능력이 그림을 잘 그리는 능력은 아니다. 다시 말해, 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.

• 깨끗한 코드를 작성하려면 '청결'이라는 힙겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다.
• '코드 감각'을 타고 나는 사람이 있는 반면에 힘겹게 투쟁해서 얻는 사람이 있다.
• 코드 감각이 있는 사람은 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.

 

깨끗한 코드란?

---

깨끗한 코드의 정의는 프로그래머 수만큼이나 다양하겠지만, 우리 분야에서 아주 유명하고 노련한 프로그래머들의 의견을 정리한다.

 

비야네 스트롭스트룹

• 의존성을 최대한 줄여야 유지보수가 쉬워진다.
• 오류는 명백한 전략에 의거해 철저히 처리한다.
• 깨끗한 코드는 한 가지를 제대로 한다.
• 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 '유혹'에 빠지지 않는다.
  • 창문이 깨진 건물은 누구도 상관하지 않는다. 창문이 더 깨져도 상관하지 않는다. 마침내 자발적으로 창문을 깬다.
  • 일단 창문이 깨지고 나면 쇠퇴하는 과정이 시작된다.

 

그래디 부치

• 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 즉, 가독성이 좋다.
• 설계자의 의도를 숨기지 않는다.
• 명쾌한 추상화와 단순한 제어문으로 가득하다.

 

데이브 토마스

• 작성자가 아닌 사람도 읽기 쉽고, 고치기 쉽다.
• 깨끗한 코드에는 의미 있는 이름이 붙는다.
• 단위/인수 테스트 케이스가 존재한다.

 

마이클 페더스

• 깨끗한 코드는 언제나 누군가 '주의 깊게' 짰다는 느낌을 준다.
• 클린 코드의 주제도 '코드를 주의 깊게 짜는 방법'이라고 한다.

 

론 제프리스

• 모든 테스트를 통과한다.
• 중복이 없다.
• 시스템 내 모든 설계 아이디어를 '표현'한다.
  • 표현력은 의미 있는 이름을 포함한다.
  • 이름 외에도 여러 기능을 수행하는 객체나 메서드를 찾아 분리시키고,
  • 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러 개로 나눈다.
• 클래스, 메서드, 함수 등을 최대한 줄인다.
• 중복 피하기, 한 기능만 수행하기, 표현력 높이기, 작게 추상화 하기

 

워드 커닝햄

• 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드이다.
  • 코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다.
• 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라고 불러도 된다.
  • 언어를 단순하게 보이도록 만드는 책임이 우리에게 있다는 뜻이다.

 

우리는 저자다

---

저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다.
다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억해라.

• 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.
• 주변 코드를 읽지 않으면 새 코드를 짜지 못한다. 그래서 읽기 쉬운 코드를 짜야한다.
• 급하다면, 서둘러야 한다면 더더욱 읽기 쉬운 코드를 짜야한다.

 

보이스카우트 규칙

---

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

• 잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.
• 많은 시간과 노력을 투자할 필요 없다.
  • 변수 이름 개선, 조금 긴 함수를 분할, 중복 제거, 복잡한 if문 하나를 정리하는 것으로 충분하다.
• 지속적인 개선이야말로 전문가 정신의 본질이다.

 

결론

---

• 예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다.
  • 책은 단지 다른 예술가가 사용하는 도구와 기법, 그리고 생각하는 방식을 소개할 뿐이다.
• 이 책 역시 마찬가지다.
  • '코드 감각'을 확실히 얻는다는 보장도 없다.
  • 단지 뛰어난 프로그래머가 생각하는 방식과 기술과 기교와 도구를 소개할 뿐이다.
• 나머지는 우리에게 달렸다.