[책] Clean Code(클린 코드) 리뷰

 

Review

스터디원의 부트캠프 컨설턴트님께서 추천해주셨던 책이라고 한다. (나는 몰랐는데 굉장히 유명한 책이었다👀💦) 이 책을 읽으면 나도 클린 코드를 짤 수 있을까!? 라는 생각으로 읽었는데 그런 면에서 초반은 꽤 도움이 되었던 것 같다.

 

책 자체는 굉장히 이상적인 내용들로 가득했다. '길거리에서 애국가가 들리면 그 자리에 멈춰서서 국가가 끝날때까지 경례하세요.' 라고 적혀있는 도덕책같은 느낌이라고 해야 하나? 어쨌든 이상과 현실은 다르다. 이 책에 적힌 방법들이 틀렸다고 생각하진 않지만, 현실에서 적용하기엔 어려운 내용들이 많았던 것 같다. (스터디원들도 비슷한 평을 남겨주었다.)

특히 디미터 법칙은 JPA를 쓰면 객체 그래프 탐색때문에 지키기 어려운 거 아닌가? 라는 생각이 들어서 의문을 떨치지 못했다. JPA로 얻는 이득이 디미터 법칙을 위반해서 생기는 손해보다 크기 때문에 사용하듯이, 클라이언트가 의존하는 클래스에 너무 큰 영향을 받지 않게 만들라는 정도로만 받아들였다.

그렇지만 그 사이에서도 건질 것들이 있었고, 와닿는 말들도 많았다. 특히 ‘코드를 항상 깨끗하게 유지하기 위해 노력해야 한다’는 책 전반에 걸쳐 강조하는 마인드는 새겨두어야 한다고 생각한다.

 

아쉽게도 아직 경험이 부족한 내가 읽기에는 너무 난이도 높은 책이었다. 특히 후반부로 갈수록 멀게 느껴지는 말들이 많았다. 그만큼 재미없는 책이었지만, 그렇기에 몇년 뒤 경험을 쌓은 뒤에 다시 읽어보고 싶다.

 

---

Highlights

우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리는 모두 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 나중은 결코 오지 않는다.

모두가 공감했을 구절이라 생각한다. 나 역시 기한에 쫓겨 일단 돌아가게만 만들어 놓았던 코드가 있다. 2년이 지나가는 지금까지도 코드는 정리되지 못했다. 기한 내에 만든 70점짜리 코드가 기한을 넘겨 만든 90점짜리 코드보다 낫다는 이유로 70점짜리 코드만 짜다간, 평생 70점만 받게 되지 않을까?

 

데이브는 깨끗한 코드란 다른 사람이 고치기 쉽다고 단언한다. 실제로 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다!

코드는 언젠가 내 손을 반드시 떠나게 된다는 점에서 크게 공감했다. 대부분은 코드를 짠 사람이 유지보수하는 기간보다 다른 팀원이 넘겨받아 유지보수하는 기간이 훨씬 기니까.

 

새로운 타이거 팀이 구성된다. 가장 유능하고 똑똑한 사람들만 타이거 팀으로 차출된다. 나머지는 현재 시스템을 계속 유지보수한다. (중략) 새 시스템이 기존 시스템을 따라잡을 즈음이면 초창기 타이거 팀원들은 모두 떠났고 새로운 팀원들이 새 시스템을 설계하자고 나선다. 왜? 현재 시스템이 너무 엉망이라서.

새로 리뉴얼되었다던 수많은 서비스들이 머릿속을 스쳐지나간다. 기존 사용자들은 대체로 불편하게 왜 바꾸냐는 불만을 쏟아낸다. 그런 서비스 치고 새로 적응하는 불편을 감수할 만큼 크게 개선된 경험을 제공하는 서비스는 별로 없었다.

 

깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.

우리가 클린 코드를 작성하는 방법을 배워야 하는 이유라고 생각한다. 투시나 구도가 이상한 그림은 누구나 쉽게 알아채지만, 그걸 어떻게 고쳐야 할지 아는 사람은 많지 않다.

 

함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

말은 쉬운데 지키기는 참 어려운 규칙이라고 생각한다. 특히 ‘한 가지’라는 말이 정말 모호하다. 추상화 정도에 따라 저 ‘한 가지’의 크기가 천차만별이기 때문이다. 햄버거를 만드는 단계를 설명하라면 누군가는 야채 손질부터 설명하고, 누군가는 번 깔기부터 설명할 테니까. 개인적으로는 함수 호출 뎁스가 너무 깊어지지 않는 정도로 추상화하는걸 선호한다.

 

주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다.

내가 적었던 주석은 내 코드를 다른 팀원이 알아보지 못할까봐 걱정되어 적은 것들 뿐이었다. 반대로 말하면 나 스스로 다른 팀원이 내 코드를 알아보기 어렵다는 걸 알고 있었다는 말이기도 하다. 주석 적을 시간에 코드를 개선하라는 말에 크게 공감한다.

 

객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.

객체지향의 사실과 오해에서도 비슷한 말이 나왔다. 객체는 상태를 숨기고 행동만을 외부에 노출한다고. 이 부분을 읽으면서 getter도 캡슐화와 상충되는 존재라는 생각이 들었다. 필드명을 변경하거나 없애면 getter를 사용하는 클라이언트도 영향을 받게 되니까. setter에 비해 getter는 큰 고민 없이 추가하는 경우가 많았는데 주의해야겠다는 생각이 들었다.

 

어플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.

오류를 처리하는 방법에는 관심이 많았는데, 오류를 어떻게 분류할지는 크게 신경쓰지 않았던 것 같다. 그래서 가장 와닿는 구절이었다.

 

경계에 위치하는 코드는 깔끔히 분리한다. 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.

외부 패키지를 직접 호출하기보단 별도 클래스로 한 번 감싸서 호출하는 게 좋다는 의미로 이해했다. 그러면 외부 패키지가 변경되더라도 경계에 위치한 클래스만 수정해주면 되니까.

 

단위 테스트는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다.

예전에 단위 테스트를 작성했던 경험이 떠올랐다. 테스트 코드를 나중에 구현하면 실제 코드에 맞춘 테스트 코드를 작성하게 된다. 하지만 실제 구조에 대해 아무것도 모르는 상태에서 테스트 코드를 먼저 작성하는건 너무 어렵다. 작은 모듈부터 구현해나가면 조금은 쉬워질까?

 

클래스를 만들 때 첫 번째 규칙은 크기다. 클래스는 작아야 한다. 두 번째 규칙도 크기다. 클래스는 더 작아야 한다.

만능 클래스는 빠르게 구현할 수 있다. 하지만 다른 사람이 유지보수하기 어렵다. 반면 작은 클래스는 만드는 데 시간이 오래 걸릴지언정, 수정해야 할 부분이 명확하다. SRP를 잘 지켰다면 클래스나 모듈을 변경할 이유는 단 하나뿐이기 때문이다.

여기서는 SRP를 지키라고 하고 있지만, 현실에서는 마감 기한이라는 게 존재한다. 개발 속도와 유지보수성 사이에서 적당한 균형을 잡는게 중요할 것 같다. 빠르게 개발한 코드는 결국 부채를 상환할 때가 오긴 하지만, 가끔은 대출을 땡겨써야 할 때가 있으니까.

 

‘처음부터 올바르게’ 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.

너무 많은 투자는 방향을 바꾸는 걸 두렵게 만들기도 한다. 좋은 코드, 좋은 설계도 중요하지만 너무 좋게 만드려기보단 지금 있는 상황에 충분할 정도로만 좋게 만들라는 의미로 받아들였다.