[책] 클린 코드

요즘 계속 한빛미디어를 통해 지원받는 책만 읽다가 #내돈내산 책을 리뷰하게 됐다. 2020년 크리스마스와 연말에 어떤 책을 읽을까 고민하던 차에 선택한 책은 클린 코드. 미리 결론을 말하자면 괜히 개발자 필수 서적이 아니라는 것을 느꼈다. (스포하자면 클린 아키텍처를 세트로 구매했고 다음 리뷰 대상이다)

밥 아저씨의 클린 코드

 

---

 

2013년 초판 발행 이후 2020년 7월 31일 7쇄가 발행됐고 그 과정에서 표지에도 변화가 있었다. 무엇 때문에 이 책이 개발자 필수 도서일까? 이 책에서 다루는 내용과 비슷한 책은 많다. 그런데도 이 책이 주목 받는 데는 이유가 있다. 일단 명료하게 내용이 전달된다. 일부에는 저자 개인의 생각을 분명히 밝히고 들어간다. 다만, 아래 내용에 해당하는 사람에게는 이 책을 권하지 않는다. 

- 자바를 다뤄본 적이 없다
- 객체지향 개념이 없다
- 자바를 다뤄본 적이 없다
- 객체지향 개념이 없다
- loop (...)

 

이유는 모든 예제가 자바로 되어 있고 나아가 스프링에 대한 이야기도 (아주) 짧게 등장하기 때문이다. 책의 구성이 나쁜 코드를 먼저 보여주고 차츰 좋은 코드로 수정해 나가는데 자바를 다뤄본 적이 없다면 저자가 이야기하는 클린 코드로 변하는 과정을 이해하기 어렵다. 그런데도 이 책을 읽고 싶다면 말리지 않는다. 부록을 제외한 17장 중에 대부분의 내용이 프로그래밍 언어와 관계없이 술술 읽히기 때문이다. 예를 들면 나쁜 코드 때문에 치르는 대가, 보이스카우트 규칙(캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라), 변수 이름 잘 지어라, 함수 단위는 작게 만들라, 주석 잘 달아라"와 같은 어쩌면 뻔한 내용이 기술되어 있기 때문이다. 이 내용만 봐도 이 책은 아주 재밌다!


# 나쁜 코드 때문에 치르는 대가

우리는 코드를 작성하는 시간보다 이해하는데 더 많은 시간을 쏟아붓고 있다. 그 말은 읽기 좋은 코드가 시간을 절약해준다는 의미고 나쁜 코드는 우리를 함정에 빠뜨린다. 시간이 지날수록 나쁜 코드는 팀 생산성을 떨어뜨리고 결국 서비스를 붕괴시킨다. 코드의 리팩토링이 불가능하니 새로 만들자는 이야기가 나오게 되고 많은 리소스가 투입된다. 그 과정을 거친다고 훌륭한 결과물이 나올까? 아니, 결국 악순환이 반복된다.


# 변수 이름 잘 지어라

i, j 같은 변수도 적절한 타이밍에 잘 사용한다면 괜찮다. 짧은 함수 내에서 간단명료한 표현을 할 때 말이다. 뜻을 정확히 내포하지 못한다면 코드를 읽고 분석하는 데 많은 시간을 할애하게 되고 동료 개발자에게 고통을 준다. 변수는 의미를 분명히 해야 한다. 뒤에 함수도 마찬가지지만 이름과 관계없는 용도로 범용적으로 사용하게 되는 순간 코드가 고약한 냄새를 풍기게 될 거다.


# 함수 단위는 작게 만들라

클래스도 마찬가지지만 함수는 하나의 책임만 져야 한다. 이걸 단일 책임 원칙:SRP(single responsibility principle)이라고 부르는데 프로그래밍 언어와 상관없이 중요한 부분이다. 함수가 여러 개의 역할을 수행하게 되면 훗날 리팩토링도 어려울뿐더러 예외가 발생할 포인트가 덕지덕지 쌓이게 된다. 목적을 분명히 하는 함수는 재사용이 용이하고 리팩토링이 수월해진다. 정확히는 리팩토링의 필요성을 잠재워준다.


# 주석 잘 달아라

잘못된 주석은 프로그래머를 힘들게 한다. 오래된 주석, 관리되지 않는 주석, 코드의 난잡함을 덮기 위해 작성된 주석, 코드의 일관성을 위해 억지로 작성된 주석 등 .. 모두 되짚어봐야 한다. 주석이 필요하다고 느껴진다면 일단 작성된 코드를 의심하라. 코드가 모호하기 때문에 주석을 작성하려고 하지는 않는지. 코드를 명확한 의도를 알 수 있도록 수정할 필요는 없는지 말이다. 이력을 주석으로 남길 생각은 말아라. 요즘같이 형상 관리 툴이 발달한 세상에 이력을 주석으로 남긴다는 건 말도 안 된다.

 

---

 

책의 전반에 걸쳐 강조하는 부분은 처음부터 완벽한 코드를 작성하려고 애쓰지 말라는 거다. 처음부터 클린 코드는 없다. 요구되는 기능을 술술 작성하고 나서 테스트 코드를 통해 기능에 오류가 없는 것을 확인했으면 그때부터 클린 코드를 위한 여정이 시작된다. 코드에 냄새나는 부분(변수 이름, 캡슐화, 중복제거 등)을 고치고 다듬는 과정을 거친다. 코드가 수정될 때마다 테스트 코드를 통해 동작상에 이상이 없는지 체크한다. 이 모든 과정이 개발 기간의 범주에 속한다. 단순히 요구되는 기능을 개발했다고 다음 task 개발로 넘어가는 건 매우 위험한 발상이다.  

책을 덮고 나서 생각해보니 대부분 이미 알고 있는 내용이지만 바쁘다는 핑계로 느슨하게 생각한 부분들이 있었다. 어제 작성한 코드를 반성하게 되는(...). 요즘 대부분의 책은 한 번 읽고 다시 펼쳐보지 않게 되는데 아마도 이 책은 주기적으로 나를 채찍질하고 반성시키기 위해 들춰보게 되지 않을까 생각해본다. :)