클린 코드 리뷰
개발자라면 누구나 더 나은 코드, 더 아름다운 코드를 짜고 싶어하기 마련이다. 이 책은 나의 그런 열망을 채워줄 것으로 기대했던 첫번째 서적이다.
언어 자체에 대한 특징이나 디자인 패턴 정도를 고려했지 코드 자체의 단순함을 고려했던 적은 없었다. 하지만 꽤 방대해진 크기의 개인 프로젝트를 직접 시도하다 보면 금방 답이 없는 수준의 코드를 맞닥뜨리고 만다.
이름 짓기의 원칙
의도를 분명히
이름 대충 지을거면 차라리 안 짓는 게 낫다. 그게 나중에 혼란을 줄 수 있기 때문이다. 예를 들어, customerInfo, accountData는 서로 customer, account와 다를 바가 없다라고 주장하는 내용이 있다.
하지만 Info, Data 같은 접미사가 들어갈 일이 생길 수 있는데, 예를 들면 account 관련한 변수가 해당 scope 이내에 여러 개 있을 경우이다. 이런 상황에서는 저자가 뭐라고 설명할지 궁금하기는 하다.
발음하기 쉬운 이름 사용
이름을 이상한 발음으로 만드는 짓은 피해야 한다. 협업 시 우스꽝스러운 이름때문에 대화길이가 더 길어지게 되고 혼란이 가중된다. 뭔 말인지는 모르겠더라도 발음 정도는 할 수 있게 만들어야 한다는 것.
또 두 명 이상씩 모여서 리뷰할 경우, 특정 변수를 두고 얘기할 때가 있을텐데 이런 상황에서도 변수 이름때문에 의사소통이 힘든 상황이 발생할 수 있다는 내용이다.
여러 군데서 사용하는 이름은 길면 좋음
검색할 때 도움이 되기 때문이다. 반면 한군데서 사용하는 이름은 쓸데없이 길 필요가 없다. 오히려 매우 간결하게 써야만 한다. 각각의 함수 혹은 스코프 안에선 최대한 이해하기 쉽게 읽히는 것이 좋으니까.
한 개념에 한 단어만 사용하라
가져올때는 get, 삭제할때는 delete처럼 모든 곳에서 통용되는 일관적인 개념을 맞추어라.
특히나 2음절 이상의 이름을 만들 경우에는 이후에 붙일 단어에 대한 근거를 댈 수 있어야 한다. 누가 봐도 그 근거를 알아차릴 수 있도록.
ImageController와 photoManager는 어떻게 다른가, manager는 어떤 일을 주로 해주는가. image와 photo의 차이는 무엇인가 등등..
이와 관련해서는 팀들마다 개념을 정립해놓은 경우도 있으니 해당 팀의 규칙을 따르면 된다.
의미론과 가독성의 중요도를 나타내는 내용인 것 같다.
말장난하지 마라
위의 규칙, 한 개념에는 한 단어를 따르려고 하다보니 add라는 접두사를 무분별하게 사용해버렸다. 그 함수들의 매개변수나 리턴값 등이 의미적으로 같다면 문제없지만 대부분은 아니다.
같은 맥락이 아닌데도 일관성을 맞추기 위해 비슷해보이는 것에는 죄다 add를 덧붙인다.
지금까지의 add 메서드는 기존 값에 새로운 값을 추가하는 기능이었다고 가정하고, 새로 만들 메서드의 기능이 배열에 요소를 하나 추가하는 것이라면 add를 추가하는게 옳은 일인가?
새로운 값을 추가하는 것은 맞지만 기존 값을 바꾸지는 않는다. 기존값 안에 값을 추가하는 것 뿐이다. insert가 적당하지 않을까?
맥락에 의미를 부여하자
각 하나씩의 이름도 중요하지만 대다수는 명확하게 이름을 짓기가 힘들기 때문에 묶여있는 해당 구역의 맥락도 매우 중요하다.
firstName, lastName, street, city, zipcode 등의 변수가 있으면 주소라는 사실을 알아챌 수 있지만 고작 state라는 변수만 달랑 있게되면 이해할 수 없을 것이다.
좋은 이름을 지으려면 설명하는 능력이 뛰어나야 함은 물론이고, 문화적 배경도 같아야 한다. 좋은 이름을 짓는 것은 높은 교육 수준이 요구되기 때문에 어려운 것이다.
이 부분에서 놀랐던 것이, 변수 이름을 짓는 것은 재능과도 연관되어 있다는 듯한 설명이 인상깊었다.
함수
함수는 짧은 단위인 것이 좋다. 아니, 이는 권장되어야 한다. 함수 이름은 15자 이내가 올바르다는 의미이다. 그러기 위해 필요한 요소 몇가지가 존재한다.
블록과 들여쓰기
조건/반복문에 들어가는 블록은 한 줄이어야 하며, 이를 넘길 경우 함수를 호출해야 한다. 이렇게 되면 조건제어문 안에 있는 함수의 이름을 잘 지었을 경우 코드 가독성에 도움이 되고 내용도 분리되며 해당 반복문을 가진 함수가 작아져 이해하기가 더욱 수월해진다.
하나만 해라
함수는 한가지만 해야 하며, 그 한가지를 충실히 잘 해야 한다. 여기서 하나라는 것은 추상화 수준을 의미한다.
우리가 함수를 만드는 이유는 큰 개념(상위 계층의 함수 이름)을 여러 단계로 나눠 수행하기 위함이기 때문이다.
이 단락에서 이견의 여지가 존재한다면, 함수 이름을 15자 이내로 적으라는 주장일 것이다.
함수 이름이 너무 길면 안 되는가? 에 대해 확실히 맞는 답이 무엇인지는 사실 어렵다.
하지만 특히 유명한 사례로 facebook을 보면 자사 서비스의 component 이름들이 평균으로 봤을 때 27자, 최대 66자로 형성되어 있다는 것이다. component는 함수가 아니지만 오히려 함수보다 더 고차원적인 개념이란 것을 이해했을 때, 꽤나 기묘해보이는 내용이다.
이는 책에서 이야기하는 짧은 이름의 중요성을 정반대의 입장에서 대변하는 것과 같다.
이들의 주장은 요소 이름이 길어져봐야 어차피 쓰는 것보다 읽는 것에 시간을 더 많이 투자하는 것이 우리 개발자들이고, 이름이 길어지는 것에 쓸 데 없이 걱정하기보다 올바른 이름을 만드는 것이 더 낫다 라는 의견에 무게를 싣는 것이다.
이를 판단하는 것은 개개인과 각 팀들이겠지만, 내 개인적인 주장으로는 모듈화와 namespace를 활용하여 긴 이름이 되는 것을 폴더처럼 끊어서 분류하는 것이 최선이라 생각한다.
물론 frontend에서는 모듈화라는 개념 자체가 angular를 제외하면 codebase 자체에서 이루어지지는 않기 때문에 예시가 올바르지는 않다는 것을 염두해야 한다.
끝맺음
이후에는 주석을 전혀 달지 말라고도 하지만 주석이 무조건 불가피한 회사가 있을 수도 있고 저자가 직접 좋은 코드를 짜려면 교육 수준이 높아야 한다고 언급한 것 처럼 주석없이 팀원들을 이해시킨다는 것 자체가 쉽지 않은 일이기 때문에, 주석을 아예 배제시키는 것은 올바르지 않다고 본다. 이처럼 모든 상황에 통용되는 책인 것 같진 않은, 다소 이견의 여지가 많은 서적이다. 다만 best practice를 위해 존재한다고 이해하고 읽는다면 정말 좋은 책이다.