Do it! 클린 프로그래밍 서적 리뷰
내용 구성
이지스에서 신간이 나온 타이밍에 맞춰 리뷰어를 모집하길래 반사적으로 신청하게 되었다.
‘클린 코드’라는 단어 자체는 개발자분들이라면 들어보지 않은 사람들이 드물 만큼 매우 중요한 내용이기도 하고, 또 흥미가 있어 신청해보게 되었다.
전반부의 내용은 클린 코드의 원칙, 코드 스멜과 리팩터링, 클린 코드 관점에서의 테스트 코드라는 부제로 내용이 서술되어 있고,
대개 클린 코드의 원칙이라 하면 빠지지 않는 네이밍, 주석, 조건식을 함수로 변경, 함수의 원칙, 정적 팩토리 메서드와 빌더 패턴을 통한 가독성, 오류 코드보다 예외를 사용하는 등의 내용이 적혀 있다. 이외로 리팩터링 및 매개변수 줄이는 부분에 대해서도 예시가 상당히 깔끔해서 읽어 내려가기 쉬웠다.
기존의 클린 코드 열풍을 일으킨 대가라 할 수 있는 로버트 C.마틴의 저서 [클린 코드] 서적과의 차이점이 있다면 테스트 코드, 디자인 패턴, 소프트웨어 프로세스 모델 등의 내용이 중반부부터 포함되어 있다는 것.
기존 [클린 코드]저서의 경우 코드 품질, 함수/클래스/이름의 작성 원칙에 중심을 두고,
해당 [클린 프로그래밍]은 클린 코드 원칙과 더불어 협업, 패턴, 설계 관련 내용이 중반부터 정리를 한 전개로 이루어진다. 예를 들어 테스트 코드 관련해서는 JUnit부터 CI/CD 활용까지 나름 폭넓게 다루고, 디자인 패턴도 생성 패턴, 구조 패턴, 행동 패턴, MVC 패턴 등에 대한 내용이 소개되어 있다.
전반부는 클린 코드의 원칙에 따른 예시를 주로 나열했다면, 후반부부터는 객체 지향 프로그래밍, 디자인 패턴, 소프트웨어 프로세스 모델(폭포수/반복적/애자일/나선형 모델 등), UML 및 다이어그램에 관한 내용이 단권화로 상당히 잘 압축되어 있다.
클린 코드 논쟁
지금부터 쓰는 내용은 책에는 직접적으로 연관되지는 않아도 간접적으로 연관된 필자가 직접 찾아본 번외의 내용이다.
상당히 흥미로운 내용인 만큼 클린 코드 관련 영상 및 논쟁 컨텐츠들도 찾아봤는데,
클린 코드 사이에는 꽤 다양한 논쟁이 있다.
가령 클린 코드를 찬성하는 쪽은 유지보수와 가독성이 가장 중요하다는 점,
클린 코드를 적용하면 협업이 쉬워지고 버그를 줄일 수 있다는 점을 통해
장기적으로 생산성을 높인다는 논거를 들어 주장을 하고,
반대로 클린 코드에 대한 회의적인 시각에는 다음과 같이 실용주의적 관점에서 초점을 맞춘다.
‘실용주의’를 강조한 만큼 실제 현업에서는 결국에는 ‘작동하는 것’이 중요하기에 실용성에 초점을 맞춰야 한다는 것, 1즉 실행 성능이나 빠른 개발이 더 중요하기에 본말전도가 되면 안된다는 의미다.
또한 클린 코드의 관점 중 하나는 작은 함수나 파일로 나누는 것을 매우 주요하게 여긴다는 것인데,
이렇게 나누다 보면 컨텍스트 파악이 어려워진다는 점을 논거로 든다.
관련 논쟁을 보다가 흥미로운 예시를 발견했는데 변수명을 userID로 할 것인가, userId로 할 것인가에 대해 30분 정도 열띤 회의를 했다는 글을 보고 댓글들의 반응 또한 읽어보았다.
그 정도의 변수명을 규정하기 위해 30분은 짧고 효율적이게 토론했다는 의견, 그 외로 비효율적이라는 의견 등 의견은 분분했다. 그러나 글쓴 분이 본래 피드에 작성했던 의도대로 본말전도된 상황이라는 쪽이 더 우세하기는 했다.
필자(본인)의 사견으로는 상대적으로 클린 프로그래밍을 실현하기 좋은 조직이 있고, 클린 프로그래밍보다는 실용성에 초점을 두어야 하는 조직이 따로 있지 않나 싶다. 예를 들어 조직의 규모가 클수록 팀원이 많고 오랫동안 유지보수를 해야 하는 만큼 한 사람의 코드가 수십 명에게 영향을 미치기 때문에 내부 가이드라인의 필요성이 큰 경우가 많지만 소규모 조직(혹은 수익형 개인 프로젝트 등)은 생존과 실용성이 우선인 것은 당연한지라, 클린 프로그래밍의 핵심 원칙만 적용하는 정도로 작성하는 것이 더 나을 수도 있다. 즉 클린 코드와 조직 규모의 상관관계는 매우 밀접하다.
클린 코드 사이의 논쟁의 이면에는 다양한 변수나 상관관계가 존재하는데, 이는 조직의 규모 및 상황에 따라서 다르게 분류하는 것도 하나의 관점이 될 수 있다.
추가: 코드 리뷰에 관한 생각
175p 코드 리뷰에 관한 내용이 꽤 공감이 갔는데, 사실 개발자들은 코드 리뷰를 부담스러워한다는 것이다. 훌륭한 코드 리뷰를 수행하는 건 많은 이들에게도 어렵지만 개발자들이 반드시 해야 하는 과정으로 잡아가고 있다는 것. 그런 의미에서 코드 리뷰는 단순한 프로세스가 아닌 개발 문화의 측면에서 생각을 해볼 필요가 있다고 서술되어 있다.
개발자는 자신이 열심히 작성한 코드에 큰 애정을 가지기 쉽기 때문에 리뷰를 거쳐 변경 요청이 들어오면 옳은 지적일지라도 기분이 상하고 자신의 코드에 대한 비판은 곧 자신을 비판하는 것처럼 느낄 수 있다는 것이다.(만국 공통 어느 직무나 사람이 느끼는 감정들은 비슷한 것 같다.)
이런 면에서 코드 리뷰에서도 클린하게 요청하는 것의 중요성과 방법에 대해서 서술되어 있다. 우스갯소리지만 마치 ‘일 잘하는 법’에 대한 책을 읽을 때와 비슷한 느낌이 들고, 생각보다 상세해서 해당 부분을 읽으면서 왠지 개발자들이 사회생활을 한 단계 잘 할 수 있게 만들어주는 소통 방법이라는 생각이 들었다. 대부분 코드 리뷰 관련 컨텐츠를 보면 단순 프로세스뿐 아니라 일종의 화법/소통 방식의 영역이기도 하기 때문이다.
학습 안내 란에 저자분의 소개가 되어 있는데, Do it 알고리즘 코딩테스트를 C++/JAVA/파이썬 세 권이나 집필하신 대단하신 분이다.
'하루 코딩'이라는 채널을 운영하시고 인프런 링크까지 따로 있으시니 링크도 첨부해놓는다.
(리뷰어는 책만 받고 글만 쓰면 되지만 그냥 팬심에 홍보차 첨부)
