작명이 코드가 된다

사내 스터디의 일환으로 작년 10월부터 <클린 코드>를 읽고 정리하고 느낀 점을 써 왔었다.

그리고 어제 드디어 13장 동시성을 정리했다.

이예에

14장부터는 코드를 직접 살펴보기 때문에, 직접 정리할 수 있는 부분은 여기까지일 것 같다.

오늘은 한바탕 책을 읽은 기념으로 <클린 코드>에 관한 내용을 조금 언급하려고 한다.

<클린 코드>에서 가장 재밌는 부분 중 하나는 책의 순서다.

이 책은 가장 중요한 내용을 처음에 언급하는 경향이 있기 때문이다.

1장의 제목은 '깨끗한 코드' 그 자체다. 나쁜 코드가 발생시키는 비용을 언급하고,

코드를 대하는 전문 개발자의 자세는 어떠해야 하는지 짚고 넘어가는 장이다.

그러면 2장의 제목은 뭘까?

작명이 코드가 된다

바로 '의미 있는 이름'이다. '클래스'도 '시스템'도 '단위 테스트'도 아니다. (이것들은 9장에 이르러서야 나온다)

깨끗한 코드를 언급하는 책에서 가장 먼저 이름 짓기를 짚고 넘어간다는 것은 큰 의미를 가진다.

사실 프로그래머만큼 짧은 시간 안에 많은 양의 이름을 짓는 직업은 많지 않은 것 같다.

프로그래밍은 방금 따끈따끈하게 내어놓은 자신의 코드 덩어리에도 마땅한 이름을 지어주어야 하는 작업 특성이 있다.

따라서 작명이 코드의 기본이 되고, 코드는 나 혹은 동료 혹은 누군가가 지어놓은 이름으로 뒤덮이게 된다.

특히 적절한 범위의 코드를 묶어 함수로 만들면, 함수명을 언급하는 것만으로도 원하는 작업이 무엇인지 사람의 언어에 가깝게 표현할 수 있다.

이를 밥 아저씨는 아래와 같은 문장으로 표현했는데, 개인적으로 마음에 들어서 기억해 두려고 하고 있다. 😅

프로그래밍의 기술은 언어를 설계하는 기술이다.

정리되지 않은 코드는 작명하기 어렵다

따라서 코드의 퀄리티와 작명의 속도 사이에는 연관관계가 생긴다.

함수명이든 클래스명이든 작명이 어려울 때는 코드가 깨끗하지 않다고 느낄 때가 많은 것 같다.

(클래스명이 좋다고 꼭 코드가 좋은 건 아니지만...)

가령 코드 리뷰를 하면서 서비스단의 메서드 하나를 살펴볼 일이 있었는데,

해당 메서드가 의존하는 클래스 6개 중 4개가 Request나 RequestInfo라는 단어로 끝나는 걸 본 적이 있다.

그래서 각각의 클래스가 이름만으로는 변별이 가지 않았고, 로직 자체도 이해하기가 쉽지 않았다.

어떤 느낌이냐면 특정 메서드에 ARequest를 넘기고 BRequestInfo를 반환받은 뒤,

다시 CRequest로 변환해서 DRequest의 필드에 삽입해 전달하는...

문장 몇 개로는 설명하기가 어려운 로직이었다.

그래서 4개의 클래스를 찬찬히 뜯어보았는데,

그중 2개가 필드 구성이 동일하고 각각 final로 선언되었느냐 안 되었느냐의 차이만 있는 중복 코드였다.

같은 내용을 두고 이름을 두 번 지어야 했으니 당연히 이름 짓기가 어려웠을 것이다.

그래서 이 코드를 보고 나서는, 작명이 잘 안 되면 코드에 문제가 없는지 되돌아보려고 하고 있다.

글이 코드와 비슷하다면

어쩌면 글을 쓸 때도, 제목을 정하기 어렵다면 글의 내용을 돌아봐야 하는 것 아닐까 싶다는 생각을 한다.

제목은 주제 의식을 반영하니, 제목이 잘 나오지 않는 상황은 주제 의식이 뚜렷하지 않은 상황,

코드로 치면 하나의 클래스에 관심사가 여러 개 들어 있는 상황과 닮은 것은 아닐까?

매일매일 글을 써야 한다고 생각하다 보니 코드와 글의 유사성에 자꾸 생각이 이르는 것 같다. 😂

그러고보니 "Git Branching의 가치"는 아예 제목을 달아놓고 글을 쓰기 시작했고, 글을 다 쓰고 나서도 고치치 않았었다.

반면 어제 오늘은 제목을 정하는 게 살짝 힘이 들었다.

그래도 아주 고민하지는 않을 예정이다. 웬만하면 평일에 쓰는 글은 부담갖지 않고 적어보려고 하기 때문이다.

하루하루 느끼는 바를 꾸준하게 쓴다면, 블로그에 글을 남기는 것도 자기 전에 1시간씩 하는 일상적인 일이 될 거라고... 생각한다.

그랬으면 좋겠다. (일찍 자는 걸 원해요... 소근)

그렇겠죠 선생님? 그렇다고 해주세요