[리뷰][BOOK] 읽기 좋은 코드가 좋은 코드다

[읽기 좋은 코드가 좋은 코드다]

개발자는 누구나 자신의 코드가 클린코드이기를 원한다. 하지만 클린코드라는 개념은 뜬 구름 잡는 얘기일 수 밖에 없다. 왜냐? 답이 없기 때문이다. 내가 작성한 코드가 누군가에겐 클린코드, 또 다른 누군가에겐 냄새나는(?) 코드일 수 있다.
그럼에도 개발자들은 이 뜬 구름을 잡으려고 여러 서적도 읽고, 고민하고 적용도 해보며 클린코드를 작성하기 위해 노력을 하고 있다.
나도 같은 고민을 하며 어떤 서적을 읽어볼까 고민하던 도중 해당 책을 알게되어 읽어본 후 후기를 남긴다.

---

1. 책을 선택한 이유

2. 내용 요약

3. 후기

---

1. 책을 선택한 이유

'대체 클린코드가 뭐야? 코드가 짧아야한다고? 변수명을 알아보기 쉽게 쓰는거라고? 그럼 이게 클린코드야?'
개발을 처음 시작했을 때 클린코드에 대해 너무너무 궁금했다. 하지만 시원하게 정의를 내려주는 사람이 없었다.

블로그의 글들을 읽어봐도 도저히 감이 오지 않았다. 대체 클린코드란 무엇이란 말인가!

클린코드와 관련한 유명한 서적이 있다. 바로 'Clean Code'. 하지만 이 책은 개발 초보가 읽기엔 내용이 쉽지 않다는 말도 들었고, 감히 읽을 엄두가 나지 않았다. 그렇게 미루고 미루다.. 내 수준(?)에 적합한 책을 알게 되었다.

취준생일 때 현직자분과 대화를 나눠볼 좋은 기회가 생겼는데, 그 때 그 분께서 "클린코드에 대해 궁금한데 'Clean Code'가 너무 부담스럽다면 '읽기 좋은 코드가 좋은 코드다'라는 책을 추천해요." 라고 말씀하셨고, 책을 찾아본 후 이거다 싶어 바로 책을 구입했다.

 

2. 내용 요약

이 책은 클린코드의 기본!에 대해 설명한다. 즉, 효율적인 코드나 객체지향적인 코드를 클린코드라고 설명하는 것이 아닌 초보자의 입장에서 코드를 읽기 쉽게 작성하는 방법을 알려준다. (정말 내 수준에 딱 맞는 책이다.)

 

해당 책은 네 파트로 나뉜다.

• PART ONE. 표면적 수준에서의 개선
• PART TOW. 루프와 논리를 단순화하기
• PART THREE. 코드 재작성하기
• PART FOUR. 선택된 주제들

 

모든 파트를 소개하기엔 글이 너무 길어질 것 같아 PART ONE만 짧게 소개해보려고 한다.

이제부터 요약할 PART ONE만 봐도 많은 도움이 될 거라고 확신한다!

내 기준 공감이 갔던 내용들 위주로 간단히 내용을 소개해보겠다.

 

[PART ONE. 표면적 수준에서의 개선]

표면적 수준이란 좋은 이름을 짓고, 좋은 설명을 달고, 코드를 보기 좋게 정렬하는 따위를 의미한다.

 

1장. 이름에 정보담기

이 장에서는 변수명을 짓는 방법에 대해 소개한다. 변수는 해당 값에 대한 짧은 설명이기에 변수에 어떤 정보를 담아야 하는지, 얼만큼 구체적이어야 하는지를 알려준다.

 

• 특정한 단어 고르기 : 정확히 무엇을 수행하는지에 따라서 더 의미 있는 이름을 사용할 수 있다.

단어	대안
send	deliver, dispatch, announce, distribute, route
find	search, extract, locate, recover
start	launch, create, begin, open
make	create, setup, build, generate, compose, add, new

• 보편적인 이름 피하기 : tmp, retval, foo 같은 이름은 "내 머리로는 이름을 생각해낼 수 없어요"라고 고백하면서 책임을 회피하는 증거에 불과하다. retval이라는 이름은 "저는 사실 반환되는 값이랍니다"라는 정보 의외에 아무 것도 담고 있지 않다.
• 단위를 포함하는 값들 : 변수가 시간의 양이나 바이트의 수와 같은 측정치를 담고 있다면, 변수명에 단위를 포함시키는 게 도움이 된다.

 

2장. 오해할 수 없는 이름들

변수명을 지었다면, 이 장에서는 상황에 따라(반환하는 값에 따라) 조금 더 나은 변수명을 작성하는 방법을 알려준다.

 

• 본인이 지은 이름을 "다른 사람이 다른 의미로 해석할 수 있을까?"라는 질문을 던져보며 철저하게 확인해야 한다.
• 어떤 값의 상한과 하한을 정할 때 max와 min을, 경계를 포함한다면 first와 last를, 경계의 시작만 포함하고 마지막은 배제하는 범위라면 begin과 end가 가장 널리 사용되는 이름이다.
• 불리언 변수에 이름 붙이기 : 불리언 변수 혹은 불리언 값을 반환하는 함수에 이름을 붙일 때는 true와 false가 각각 무엇을 의미하는지 명확해야한다.

boolean read_password = true;

위 코드는 읽는 방법에 따라서 두 가지 상반된 해석이 가능하다.

• 우리는 패스워드를 읽을 필요가 있다.
• 패스워드가 이미 읽혔다.

이 경우에는 'read'라는 단어를 사용하지 않는 것이 최선이다. 대신 need_password 혹은 user_is_authenticated를 사용한다.

일반적으로 is, has, can, should와 같은 단어를 더하면 불리언값의 의미가 더 명확해진다.

 

3장. 미학

이 장에서는 빈칸, 정렬, 코드의 순서를 이용하여 읽기 편한 소스코드를 작성하는 방법을 알려준다. 즉, 깔끔한 코드를 작성하는 방법을 알려준다. 해당 장은 눈으로 직접 봐야하는 미학에 관련되었기 때문에 긴 소스코드로 설명하는 예시가 많다. 모두 소개하고 싶지만 예제는 이미지로 대체하고, 짧게만 소개하겠다. (간단하게 적지만 실제로 나는 정말 도움이 많이 된 부분이다.)

 

• 여러 블록에 담긴 코드가 모두 비슷한 일을 수행한다면, 줄바꿈과 줄맞춤을 적절히 이용하여 실루엣이 동일해보이게 만들어라.
• 코드의 한 곳에서 A, B, C가 이 순서대로 언급되고 있으면, 다른 곳에서 B, C, A와 같은 식으로 언급하지 말라. 의미 있는 순서를 정하여 모든 곳에서 그 순서를 지켜라
• 빈 줄을 이용하여 커다란 블록을 논리적인 '문단'으로 나누어라.
• 일관성 있는 스타일은 '올바른' 스타일보다 더 중요하다.

ex1) 왼쪽보단 오른쪽이 한눈에 들어온다.

ex2) 왼쪽보단 오른쪽이 한눈에 들어온다. 또한 세번째 줄에 오타가 났다는 사실도 한눈에 알 수 있다.

 

4장. 주석에 담아야하는 대상

이 장은 주석에 담아야 하는 내용이 무엇인지를 알려준다. 책에서는 주석의 목적을 "코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해하게 돕는 데 있다."고 말한다. 주석에 어떤 내용들을 담아야 하는지 알아보자.

• 주석을 읽는 것은 실제 코드를 읽는 시간을 갉아먹고 주석은 화면의 일정한 부분을 차지한다. 즉 주석을 단다면 반드시 달아야 하는 이유도 있어야 한다.
• 나쁜 이름에 주석을 달지 마라 - 대신 이름을 고쳐라
  
  • 사람들은 코드가 가진 나쁜 가독성을 메우려고 노력하는 '애쓰는 주석'을 원하지 않는다.
  • 프로그래머들은 이러한 규칙을 대개 좋은 코드 > 나쁜 코드 + 좋은 주석 이라는 공식으로 설명한다.
• 좋은 주석은 단순히 '자신의 생각을 기록하는 것'만으로도 탄생할 수 있다. 아래 예시를 보자. (코드는 없고 주석만 확인해보자.)

//이 데이터에서 이진트리는 해시테이블보다 40% 정도 빠르다. 해시를 계산하는 비용이 좌/우 비교를 능가한다.

👉  이 주석은 코드를 읽는 사람에게 코드를 최적화 하느라 시간을 허비하지 않게 도와준다.

//이 주먹구구식 논리는 몇 가지 단어를 생략할 수 있다. 상관없다. 100% 해결은 쉽지 않다.

👉 이 주석이 없으면 코드를 읽는 사람은 뭔가 버그가 있다고 생각하고 실패를 위한 테스트 케이스를 짜거나, 버그를 수정하는 데 시간을 허비할지도 모른다.

//이 클래스는 점점 엉망이 되어가고 있다. 어쩌면 ResourceNode 하위 클래스를 만들어서 정리해야 할지도 모르겠다.

👉 주석으로 코드가 왜 훌륭하지 않은지도 설명할 수 있다. 이 주석은 코드가 엉망이라는 사실을 밝히고 다음 사람에게 어떻게 수정해야 하는지 알려준다. 만약 이 주석이 없으면 많은 사람이 이 코드에 겁을 먹어 건드리지 않으려고 할 것이다.

• 코드를 읽는 사람의 입장이 되어라.
  • 여러분이 작성한 코드를 다른 누군가가 읽는다면 "아니, 이게 뭐 하는 코드야?"라는 질문이 나올 수 있다. 여러분이 할 일은 바로 그런 부분에 주석을 다는 것이다.
  • 함수나 클래스를 작성할 때 스스로에게 "내가 작성한 이 코드를 다른 사람이 읽으면 깜짝 놀랄 부분이 있나? 오용될 수 있나?" 등의 좋은 질문을 던질 필요가 있다.
• 글 쓰는 두려움을 떨쳐내라
  • 많은 프로그래머가 주석 달기를 달가워하지 않는다. 좋은 주석을 창작하기 위해서 시간을 들이는 것을 아깝게 생각하기 때문이다. 해결책은 그냥 쓰기 시작하는 것 뿐이다.
  • 예를 들어 어느 함수를 작성하는데 "이런 제길, 이 리스트 안에 중복된 항목이 있으면 이건 복잡해지잖아."라고 생각을 했다면 그냥 그 말을 주석으로 작성하라.
  • //이런 제길, 이 리스트 안에 중복된 항목이 있으면 이건 복잡해지잖아.
  • 이게 어려운가? 더구나 이것은 그리 나쁜 주석도 아니다. 아무 것도 없는 것보다 당연히 더 낫다. 하지만 사용된 단어는 좀 모호하다. 이런 부분을 고치려면 설명을 하나씩 살펴보면서 더 구체적인 표현으로 바꾸면 된다. (생략)
  • //주의 : 이 코드는 리스트 안에 있는 중복된 항목을 다루지 않는다. 그렇게 하는 것이 어렵기 때문이다.
  • 그러면 이렇게 새 주석으로 다시 태어난다.

 

5장. 명확하고 간결한 주석 달기

앞 장에서는 주석이 무엇을 설명해야 하는지 살펴보았다. 이번 장에서는 주석을 어떻게 명확하고 간결하게 다는지 살펴볼 것이다.

• 주석을 간결하게 하라
• 모호한 대명사는 피하라 : 'it'이나 'this' 같은 대명사가 여러 가지를 가리킬 수 있다면 사용하지 않는 것이 좋다.
• 엉터리 문장을 다듬어라
• 함수의 동작을 명확하게 설명하라
• 코너케이스를 설명해주는 입/출력 예를 사용하라
• 코드의 의도를 명시하라 : 코드의 묘사만 전달하지 말고 수행 동작을 개락적인 높은 수준에서 설명하라
• 이름을 가진 함수 파라미터 주석 : 같은 줄 주석(/* */)을 사용하여 의미가 불분명한 함수의 파라미터를 설명하라
• 정보 축약형 단어를 사용하라 : 많은 의미를 함축하는 단어로 주석을 간단하게 만들어라

 

3. 후기

클린코드가 무엇인지 궁금한 초보 개발자들(나 포함..ㅎ)을 위해 PART ONE의 내용만 아주 간단하게 적어봤다. 실제로 PART ONE만 해도 100p 가까이 되는 책이니 위 내용이 다라는 오해는 없으시길 바란다...! (뒤 세 파트는 합해서 150p... part one이 제일 길긴 함..)

 

나는 이 책을 읽고 정말정말정말 도움을 많이 받았다. 회사나 토이프로젝트에서도 실제로 많이 활용하고 있고, 비슷한 연차의 동료 개발자분들께도 변수명이라던지, 코드 스타일을 더 명확하고 간결하게 작성하도록 권하고(?) 있다.

특히 나는 주석을 작성하는 방법이 너무 궁금었다. 주석을 작성한다는 것은 어찌됐던 코드를 읽어 나갈 때 굳이 더 읽어야 하는 부분 생기는거 아닌가? 라고 생각을 했었는데, 아주 말끔히 그 생각을 뒤집어주었다. 실무에 적용해보니 정말 주석의 소중함과 잘 작성된 주석이 주는 효율까지도 한 번에 깨달을 수 있었다.

변수명이나 메서드명 또한 도움을 많이 받았는데, 믿기 힘들겠지만 실제 회사 코드에 String a, String ab 등등 이런 변수명들이 너무나 많았다.. 시간날 때 마다 표면적 수준에서 리팩토링을 진행했는데, 확실히 시간이 지나고 코드를 읽을 때 훨씬 잘 읽히는 것을 느꼈고, 그 코드 옆에 내 이름이 뜰 때(코드 작성자) 괜히 뿌뜻한 기분을 많이 느꼈다ㅎㅎ

 

뭐든지 보고 듣는 것 보다는 직접 경험을 해보는 것이 제일 기억에 남고 실력도 많이 느는 것 같다.

개발은 '백문이불여일타'라는 말이 나올 정도로 코드를 많이 작성해보는 것이 중요한 것 같다.

이 책을 읽고 클린코드에 대해 조금이나마 이해할 수 있었고, 직접 경험을 해보면서 아 이게 클린코드구나 라고 느낄 수 있었다.

그러니 나와 비슷한 처지(?)에 놓인 개발자분들이 책만 읽는 것이 아닌 실제로 적용해보고 이해해봤으면 좋겠다!

 

이제 막 개발을 시작한 개발자분들이나, 클린 코드에 대해 감이 잘 안오는 개발자분들에게 적극 추천하는 책이다!