[클린코드(CleanCode)] 1장 깨끗한 코드

개요

이 책을 읽고 있다면 이유는 두 가지

• 프로그래머라서
• 더 나은 프로그래머가 되려고

이 책은 좋은 프로그램 작성 요령을 설명하는 책

• 읽고 나면 코드에 대해 많은 사실을 배울 수 있음
• 좋은 코드와 나쁜 코드를 구분하는 능력도 생김
• 좋은 코드를 작성하는 방법도 익힘
• 나쁜 코드를 좋은 코드로 바꾸는 실력도 쌓임

---

코드가 존재하리라

코드가 자동으로 생성하는 시대가 왔다고 하지만 코드가 사라질 가망은 전혀 없음

코드는 요구사항을 상세히 표현하는 수단이기 때문!

• 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세히 표현하고 추상화하는 것이 불가능
• 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이며, 이렇게 명시한 결과가 코드임

언어의 추상화 수준은 높아지고 특정 응용 분야에 적합한 프로그래밍 언어 수도 많아질 예정이지만 그래도 코드는 사라지지 않음

• 결국 고도로 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세 역시 코드
• 어떤 언어를 사용하든 코드는 기계가 이해하고 실행할 정도로 엄밀하고 정확하고 상세하게 정형화되어야 함

요구 사항에 더욱 가까운 언어를 만들고 요구사항에서 정형 구조를 뽑아내는 도구를 만들 수 있음

• 하지만 어느 순간에는 정밀한 표현이 필요한데 그 필요성을 없을 방법은 없음
• 그러므로 코드도 항상 존재하리라

---

나쁜 코드

Killer App 하나를 구현한 회사가 있는데 커다란 인기를 끌었지만 이전 버전에 있었던 버그가 다음 버전에도 그대로 남아 있어 프로그램 시동 시간이 길어지고 프로그램 죽는 횟수도 늘어나서 사람들이 다시 사용하지 못해 망했음

• 원인은 출시에 바빠 코드를 마구 짰고 기능을 추가할수록 코드는 엉망이 되었고 결국 감당하지 못했음
• 회사가 망한 원인은 바로 나쁜 코드 탓

나쁜 코드에 발목을 잡혀 고생하는 것을 고행(wading)이라고 한다

• 우리는 나쁜 코드를 헤쳐나가며 발버둥 치지만 소용이 없다

프로그래머라면 급해서 제대로 코드를 짤 시간이 없다며 나중에 손보겠다고 한 적이 많다.

• 그러나 나중은 결코 오지 않는다

---

나쁜 코드로 치르는 대가

남들이 짜놓은 나쁜 코드로 고생하고 하도 엉망이라 프로젝트 진도가 안 나간 경험이 있을 것

• 이처럼 나쁜 코드는 개발 속도를 크게 떨어뜨림
• 프로젝트 초반엔 빨라도 시간 지나면 엉뚱한 곳에 문제 생겨 코드를 해독하느라 시간이 걸림

나쁜 코드가 쌓일수록 팀 생산성은 떨어짐

=> 나름대로 복수는 시도하려고 인원을 추가

=> 그 인원은 기존에 있었던 시스템 설계에 대한 조예가 싶지 않아 설계 의도에 맞는 변경 어려움

=> 결국 나쁜 코드 양산

=> 생산성은 더더욱 떨어져 거의 0이 됨

원대한 재설계의 꿈

결국 팀에서 더 이상 일하지 못하겠다고 관리층에 재설계를 요구

=>  결국 새 팀이 만들어져 기본의 시스템을 완전히 대체할 수 있는 시스템을 만들려고 함 

=>  원래 팀과 새 팀이 서로 경주를 하며 개발을 해나아가는데 이것이 길면 10년이 넘게 걸릴 수도 있음

=>  이렇게 경주를 하면서 따라잡기 위해 새 팀에서도 나쁜 코드를 양산하게 됨

=>  새 팀이 기존 팀을 따라잡을 정도가 되면 다시 생산성이 0가 되어버려서 또 새로운 팀을 만들게 됨

• 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길

태도

한 줄만 고치면 되리라 예상했다가 모듈을 수백 새 건드린 경험도 있을 것

왜 코드가 그렇게 되었을까?

• 코드에 잘 모르는 관리자들 탓일까? 촉박한 업무에 대한 문제일까?
• 결국은 잘못은 전적으로 프로그래머에게 있음
• 좋은 코드를 사수해야 하는 일은 바로 우리 프로그래머들의 책임

원초적 난제

기한을 맞추려고 나쁜 코드를 양산할 수밖에 없다고 느끼지만 결국 그 기한을 맞추는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관

깨끗한 코드라는 예술?

깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷

• 그림을 보면 대부분의 사람은 잘 그렸는지 엉망인지 앎
• 그런데 잘 그린 그림을 구분하는 능력이 그림을 잘 그리는 능력은 아님
• 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아님

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

• 열쇠는 '코드 감각'
  • 코드 감각이 있으면 좋은 코드, 나쁜 코드를 구분함
  • 그리고 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악
  • 코드 감각이 없는 프로그래머도 나쁜 모듈을 알아보지만 좋은 모듈로 개선할 방안을 떠올리는 건 아님

• 깨끗한 코드를 작성하는 프로그래머는 빈 캔버스를 우아한 작품으로 바꿔가는 화가와 같음

깨끗한 코드란?

유명하고 노련한 프로그래머들의 의견

1. 비야네 스트롭스트룸
   • 우아하고 효율적인 코드
     • 우아함: 보기에 좋은 코드
     • 효율: 속도뿐만 아니라 CPU 자원을 낭비하는 것도 의미
   • 논리가 간단해야 버그가 숨어들지 못함
   • 의존성을 최대한 줄여야 유지 보수가 쉬워짐
   • 오류는 명백한 전략에 의거해 철저히 처리
     • 세세한 사항까지 꼼꼼하게 처리(오류 처리)
   • 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않음
   • 깨끗한 코드는 한 가지를 제대로 함
     • 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞여 목적이 흐려짐
     • 깨끗한 코드는 한가지에 집중
2. 그래디 부치
   • 단순하고 직접적
   • 잘 쓴 문장처럼 읽힘
   • 결코 설계자의 의도를 숨기지 않음. 오히려 명쾌한 추상화와 단순한 제어문으로 가득
     • 코드는 추측이 아니라 사실에 기반해야 하고 반드시 필요한 내용만 담아야 함
3. 데이브 토마스
   • 작성자가 아닌 사람도 읽기 쉽고 고치기 쉬움
   • 단위 테스트 케이스와 인수 테스트 케이스가 존재
   • 의미 있는 이름이 붙음
   • 특정 목적을 달성하는 방법은 하나만 제공
   • 의존성은 최소이며 각 의존성을 명확히 정의
   • API는 명확하며 최소로 줄임
   • 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드는 문학적으로 표현해야 마땅함
4. 마이클 페더스
   • 언제나 누군가 주의 깊게 짰다는 느낌을 줌
     • 고치려고 봐도 딱히 손댈 곳이 없음
5. 론 제프리스
   • 모든 테스트를 통과
   • 중복이 없음
   • 시스템 내 모든 설계 아이디어를 표현
   • 클래스, 메서드, 함수 등을 최대한 줄임
6. 워드 커닝햄
   • 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행
   • 코드가 그 문제를 풀기 위한 언어처럼 보임

---

우리들의 생각

깨끗한 코드의 정의

• 깨끗한 변수 이름
• 깨끗한 함수
• 깨끗한 클래스

이 책에서 설명하는 교훈이 저자들에겐 절대적인 진리

• 그러나 저자들의 생각이 절대적으로 '옳다'라는 단정은 금물

---

우리는 저자다

저자에게는 독자가 있고, 저자는 잘 소통할 책임도 존재

코드를 짤 때는 자신이 저자라는 사실을, 여러분들의 노력을 보고 판단을 내릴 독자가 있다는 사실 기억

코드를 읽는 시간이 작성하는 시간보다 많음

• 실제 읽기와 쓰기에 들이는 시간은 대력 10:1
• 새 코드를 작성하기 위해서는 옛 코드를 읽어야 하기 때문

급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 됨

---

보이스카우트 규칙

잘 짠 코드가 전부는 아니며 시간이 지나도 언제가 깨끗하게 유지해야 함

미국 보이스카우트 규칙

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

한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없음

변수 이름을 하나 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 됨

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

---

프리퀄과 원칙

이 책은 Agile Software Development: Principles, Patterns, and Practices (PPP)의 프리퀄

• PPP 책은 객체 지향 설계의 원칙을 설명하고 전문 개발자들이 사용하는 실무 기법을 소개

SRP(Single Responsibility), OCP(Open Closed Principle), DIP(Dependency Inversion Principle) 등 다양한 설계 원칙을 산발적으로 거론하므로 PPP를 읽어보는 것이 좋음

---

결론

예술에 관한 책을 읽는다고 예술가가 된다는 보장은 없음

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

이 책이 보여주는 것

• 좋은 코드 소개
• 나쁜 코드 소개
• 나쁜 코드를 좋은 코드로 바꾸는 방법 소개
• 다양한 경험적 교훈과 체계와 절차와 기법도 열거
• 예제

꾸준히 연습할 것

---

글쓴이의 생각

내가 지금까지 바쁘게 코드를 짰지만 그 코드를 깨끗하게 짜지 못했던 것 같다.

미래의 내가 봐도 이 코드를 이해하고 확장할 수 있을까 의문이 들 정도....

그렇기에 코드를 깨끗하게 짜야지 나중에 고생 안 한다는 말에 동의하며 이 책을 통해 클린하게 코드를 짜야겠다고 다짐하였다.

그리고 좋은 코드는 한 번에 짤 수 없다.

코드를 작성하고 다듬고 작성하고 다듬고를 반복하여 다른 사람들이 봤을 때 이해하기 쉬운 코드가 되도록 연습해야겠다.