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

책 정보

저자: 더스틴 보즈웰, 트레버 파우커

출판사: O'REILLY

발행일: 2012-04-10

페이지: 252

---

리뷰

개발자가 코드를 읽고 이해하는데 시간을 최소화 해야한다.

이 책은 제목에 써있는 것처럼 코드를 작성하면서 가독성이 얼마나 중요한지에 대해 초점을 둔 책이다.

글이 되게 장황하게 써있지도 않고 핵심만 작성되어 있어서 되게 편하고 금방 읽을 수 있었다. 

이론을 서포트해주기 위해 작성된 코드들의 언어들은 다양하지만, 그리 어려운 코드들이 아니라 이해하는데 어려움은 없을거다.

---

내용

책은 크게 4 파트로 나뉜다.

1. 표면적 수준에서의 개선
2. 루프와 논리를 단순화하기
3. 코드 재작성하기
4. 선택된 주제들

1. 표면적 수준에서의 개선

계속 반복하지만 다른 개발자가 내 코드를 봤을때 쉽게 이해가 되어야 한다는 내용이다.

 

그러면 짧은 코드가 좋은거냐?

라고 묻는거면 아니다. 오히려 짧은게 더 복잡해서 내용을 이해하기 어렵게 만들수도 있다.

 

변수나 함수명을 정할때도 최대한 애매모호하거나 불필요한 표현을 쓰지 말라고한다. 이건 공감이간다. 실제로 6개월 전에내가 짠 코드를 보거나 다른 사람의 코드를 읽다보면 이게 뭘까 싶은 이름들이 종종 보인다. 

예를들어 convertToString() 에서 convert라는게 필요할까? toString() 만으로 충분하다

그러다보면 주석으로 그 뜻을 녹이려는 사람들이 있는데 그것또한 잘못된 접근방식이라고 생각된다. → 오히려 코드를 이해하는데 방해가 될 수 있다. 좀더 표현에 신경을 쓰면 주석또한 안 달아도 된다.

 

그러면 축약어는?

피해라. 처음 접할때는 뭐 나쁘지않네 싶다가도 점점 새로운 사람과 협업을 하다보면 금방 나쁜 습관인걸 경험했다. 

무작정 축약어가 나쁘다는 아니다. 모두가 이해할법한 축약어 예를 들어 String -> str을 줄이는건 괜찮다.

 

내가 작성한 이름이 다른사람에게 같은 의도임을 전달하기 위해 다음과 같은 규칙도 소개해준다.

• 경계를 포함하는 경우 - first, last를 사용
• 경계를 포함/배제하는 경우 - begin, end를 사용
• Boolean 타입인 경우 - is, has, could를 앞에 사용
• 최소, 최대를 표현하는 경우 - Limit 보다는 min, max로 표현

2. 루프와 논리를 단순화 하기

코드를 읽다 다시 되돌아가서 코드를 읽지 않아도 되게끔 만들어라

첫 줄부터 할말이 없다. 내 기억이 맞다면 내 옛날 코드들은 많이 되돌아보게 된걸로 안다..ㅎ...

여기서는 루프와 논리제어 문에서 가독성을 어떻게 하면 좋은지에 대해서 다룬다.

 

조건문에서의 인수 순서, 이건 대부분의 개발자가 무의식적으로 따랐을법한 규칙이다. 좌측에는 유동적인 녀석, 우측에는 거의 고정값을

이건 별로 생각을 안해보긴 했는데, 조건문에서 최대한 긍정을 다루는 것이 부정보다는 더 흥미로울거다라고 표현하고 있다. 

이건 타입스크립트를 사용했을때 느낀건데, 삼항연산자는 늪이다. 정말 간단할때가 아니라면, 거의 do/while 급으로 가독성이 안좋은 표현으로 생각된다.

 

종종 코드를 하다보면 흐름제어를 위한 변수를 사용하는 경우도 많은데, 이건 코드만 잘 짜면 충분히 없앨수 있는 내용이다.

val done: Boolean = false

while (조건 && !done) {
    ...
    if (...) {
    	done = true
        continue
    }
}

와 같은 식의 코드를 작성해본 경험이 있을거라 생각된다. 일단 나부터 ㅋㅋ

이러한 코드는 물론 정상적으로 돌아갈거다. 근데 좀만 설계를 잘하면 충분히 고칠 수 있는 코드다

while(조건) {
    ....
    if (...) {
    	break
    }
}

 

마지막으로 변수가 사용되는 범위를 줄이고 단 한번만 할당하도록 해라. 그러지 않으면 변수의 값을 추측하는데 어려워진다.

3. 코드 재작성하기

여기서는 크게 SRP에 대한 내용이다. 하나의 함수 혹은 클래스가 가지는 역할은 많아서는 안된다는 내용이다.

역할을 분담해서 더 작은 함수를 쪼개서 하나의 함수를 만드는게 가독성에 더 많은 도움을 준다.

+ 추가효과로 테스트를 하는데 훨씬 편해진다!

 

이러한 행동을 하기 위해서는 다음과 같은 작업을 연습하면 쉬워진다.

1. 하나의 코드에서 수행하는 작업을 나열
2. 작업을 분리해서 서로 다른 함수 혹은 논리적으로 분리

이것 또한 되게 공감되는 말이였다.

그 기능을 구현하려고 애쓰지마라. 어차피 완벽하게 다룰수 없을거다. 

 

마지막으로 코드베이스는 작게 유지하도록 노력하라고 하는데, 이것 또한 공감이간다. 인텔리제이로 개발을 하다보면 회색으로 된 변수들이 종종 보이는데 이 친구들을 뭐 때문에 안지우고 있을까 싶을때가 있다 ㅋㅋ.

4. 선택된 주제들

마지막 답게 테스트에 대한 내용인데, 이번엔 테스트 코드에서의 가독성을 강조하고 있다.

간단하게 요약하면 다음과 같다.

• 테스트코드를 100프로 채우려고 하지마라. 
• 테스트코드를 위해 실제 코드를 더럽히지 마라.
• 테스트코드의 input은 단순해도 괜찮다.
• 버그의 비용을 계산하고 테스트를 작성해라. 예를 들어 프로토타입을 개발하는데 굳이 엄청난 테스트코드가 있을필욘 없다.
• 테스트코드 때문에 개발일정이 밀려서도 안된다.

---

정리

책을 읽다보면 과거 자신이 짠 코드들이 생각날듯 하면서 건드릴 용기가 없는 자신을 찾게 될거다

개인적으로 이 책은 이제 막 개발을 시작한 사람 혹은 주니어가 클린코드를 읽기전에 한번쯤 읽어봐도 괜찮은 책인거 같다.

개인적인 평점 : 3.5/5