[클린코드] 1장. 깨끗한 코드

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다.

---

1장. 깨끗한 코드

- 클린 코드의 책의 목표는 아래와 같다.

• 좋은 코드와 나쁜 코드를 구분하는 능력을 갖춘다.
• 좋은 코드를 작성하는 방법을 익힌다.
• 나쁜 코드를 좋은 코드로 바꾸는 실력을 만든다.

1. 코드가 존재하리라

- 코드는 요구사항을 상세히 표현하는 수단이다.

- 기계가 실행할 정도로 상세하게 요구사항을 명시하는 직업, 이것이 프로그래밍이다.

- 프로그래밍 언어에서 추상화 수준은 점차 높아지겠지만, 코드가 사라지진 않을 것이다.

- 고도로 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세 역시 코드이다.

2. 나쁜 코드

- 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고(리팩토링) 생각한 경험이 있다.

- 어떠한 이유로 나쁜 코드를 작성하였더라도 수정할 수 있는 나중은 결코 돌아오지 않는다.

3. 나쁜 코드로 치르는 대가

- 나쁜 코드는 개발 속도를 크게 떨어뜨린다.

- 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.

- 인력을 투자 하더라도 기존 설계 의도를 파악하지 못하면 나쁜 코드를 더 양산하게 된다.

3-1. 원대한 재설계의 꿈

- 나쁜 코드에 의해 생산성이 바닥이 되면 반기를 들고 재설계를 하는 경우가 생긴다.

- 관리자는 재설계에 자원을 쏟아붓기 싫지만 나쁜 코드로 인해 생산성이 안 좋다는 것을 부인할 수 없다.

- 오랜 시간에 걸쳐 기존 시스템을 따라잡을 즈음이면, 초창기 재설계팀은 모두 팀을 떠나고 새로운 팀워들이 새 시스템을 설계하자고 한다.(Why? 현재 시스템이 너무 엉망이기 때문)

- 결론은 처음부터 깨끗한 코드를 만들어야 한다.

3-2. 태도

- 나쁜 코드의 잘못은 무조건 프로그래머의 문제이다.

- 관리자의 시간 독촉은 관리자의 책임이기 때문이다.

- 좋은 코드를 사수하는 일은 프로그래머의 책임이다.

- 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따르는 행동은 전문가답지 못하다.

3-3. 원초적난제

- 나쁜 코드는 업무 속도를 늦춘다.

- 기한을 맞추려 나쁜 코드를 양산하는 것은 오히려 개발을 더디게 한다.

- 언제나 코드를 최대한 깨끗하게 유지하는 습관이 중요하다.

3-4. 깨끗한 코드라는 예술?

- 깨끗한 코드가 무엇인지 모르면 깨끗한 코드를 만들 수 없다.

- 깨끗한 코드를 작성하려면 '청결'이라는 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다.

- 열쇠는 '코드 감각'이다. 이는 타고날 수도 있고, 노력으로 얻을 수 있다.

• 코드 감각이 있으면 좋은 코드와 나쁜 코드를 구분한다.
• 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.

- '코드 감각'이 없는 프로그래머도 때로는 나쁜 모듈을 알아보지만 그것으로 끝나고, 코드 감각이 있는 프로그래머는 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 생각한다.

3-5. 깨끗한 코드란?

- 아래는 각 분야의 유명한 프로그래머들의 클린 코드에 대한 의견이다.

• 비야네 스트로스 트룹
  • 논리가 간단해야 버그가 숨어들지 못한다.
  • 의존성을 최대한 줄여야 유지보수가 쉬워진다.
  • 오류는 명백한 전략에 의거해 철저하게 처리한다.
  • 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.
  • 깨끗한 코드는 한 가지를 제대로 한다.
• 그래디 부치
  • 깨끗한 코드는 단순하고 직접적이다.
  • 깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
  • 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다.(가독성)
  • 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
• 큰 데이브 토마스
  • 깨끗한 코드는 작성자뿐만 아니라 다른 사람도 읽기 쉽고 고치기 쉽다.
  • 단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
  • 테스트 케이스가 없다면 아무리 우아하고 가독성이 높아도 깨끗하지 않다.
  • 의존성은 최소이며, 각 의존성은 명확히 정의한다.(작을수록 좋다)
  • 특정 목적을 달성하는 방법은 하나만 제공한다.
  • API는 명확하며 최소로 줄였다.
• 마이클 페더스
  • 깨끗한 코드는 주의 깊게 짰다는 느낌을 준다.
  • 고치려고 살펴봐도 딱히 손댈 곳이 없다.
  • 누군 가 시간을 들여 깔끔하고 단정하게 정리한 코드이므로 고칠 궁리를 하다 보면 언제나 제자리로 돌아온다.
• 론 제프리스
  • 모든 테스트를 통과한다.
  • 중복이 없다.
  • 시스템 내 모든 설계 아이디어를 표현한다.
  • 클래스, 메서드, 함수 등을 최대한 줄인다.(작게 추상화)
  • 초반부터 간단한 추상화 고려까지 포함하는 것이 깨끗한 코드를 만드는 비결이다.
• 워드 커닝햄
  • 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드이다.
  • 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드이다.

4. 우리들 생각

- 깨끗한 변수 이름, 깨끗한 함수, 깨끗한 클래스를 만드는 방법

- 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다.

- 이 책을 통해 수십 년에 걸친 경험과 반복적 시행착오로 습득한 교훈과 기법을 권고한다.

- 우리는 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10:1 이 넘는다. 그러므로 쉽게 짜려면 읽기 쉽게 만들어야 한다.

5. 우리는 저자다

- 새로운 코드 작성 시 대부분 기존 모듈을 파악하는 대에 시간을 사용한다.

- 새 코드를 짜면서 끊임없이 기존 코드를 읽는다.

- 따라서 읽기 쉬운 코드는 매우 중요하다.

5-1. 보이스카우트 규칙

- 잘 짠 코드가 전부는 아니다.

- 시간이 지나도 언제나 깨끗하게 유지해야 한다.

- 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.

- 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나 개선하고, 조금 긴 함수 하나 분할하고, 약간의 중복을 제거하고, 복잡한 if 문 하나를 정리하면 충분하다.

- 지속적 개선이야 말로 전문가 정신의 본질이다.

5-2. 프리퀄과 원칙

- 이 책은 저자가 작성한 Agile Software Development: Principles, Patterns and Practicess (PPP) 객체 지향 설계의 원칙을 설명하는 책에서 하는 이야기를 이어간다.(SOLID 원칙 관련)

6. 결론

- 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.

- '코드 감각'을 얻는다는 보장도 없다.

- 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다.

- 다양한 경험적 교훈과 체계, 절차, 기법도 열거한다.

- 항상 끊임없이 연습해야 한다.