[개발서적] 클린 코드(Clean Code) : 좋은 코드란 무엇인가?

클린 코드(Clean Code) - 로버트 O. 마틴(Robert O. Martin)

Clean Code 클린 코드 국내도서 저자 : 로버트 C. 마틴(Robert C. Martin) / 박재호,이해영역 출판 : 인사이트 2013.12.24 상세보기

 

정규직 전환 이후에 약간의 심적인 여유가 생겼다.

그래서 읽으려고 찜해둔 책들을 개인적으로 몇 권 주문했다.

 

그중 제일 궁금했던 책이 이 '클린 코드'이다.

회사에서 코드리뷰를 하고 받을수록 '좋은 코드란 어떤 걸까?'라는 생각을 점점 더 많이 하게 되는 것 같다.

한 줄을 수정하더라도 '이렇게 수정하면 가독성이 좋아지는 게 맞나?', '변수명은 괜찮은가?' 같은 고민들을 하다 보니 이 책이 가장 눈에 들어왔다.

 

찾아 보니 2013년 도서인데도 아직까지 개발자들에게 널리 읽히는 책인 듯했다.

아직 졸업 전인 학부생 친구들 중에도 이미 이 책을 읽었다는 친구들이 있었다.

아무래도 개발자 필독서가 아닐까 싶어서 클린 코드를 나의 첫 개발도서로 선택했다.

좋은 코드란 무엇인가?

이 책을 선택한 이유인 만큼 계속 '좋은 코드란 무엇인가?'를 생각하며 읽었다.

결론적으로 좋은 코드란, 극강의 가독성과 유지보수성을 가진 코드라고 할 수 있을 것 같다.

내가 개인적으로 느낀 구체적인 요건들로는 이런 것들이 있었다.

 

- 코드를 처음 보는 사람도 쉽게 따라가며 읽을 수 있을 것

- 내 의식의 흐름을 기억하지 않아도 언제든 원하는 기능을 다시 찾아갈 수 있을 것

- 5년 뒤에 내가 다시 보더라도 금세 이해할 수 있을 것

- 새로운 기능을 추가하더라도 크게 구조변경이 없을 것

 

이런 코드를 만들기 위해서는 작은 변수명 하나를 정할 때에도 가독성을 생각하면서,

장인 정신을 가지고 코드를 짜야 하야 하는 것 같다.

좋은 코드를 짜기 위한 규칙들 - 기억에 남는 것들

책에서는 좋은 코드를 짜기 위한 여러가지 방법론을 다룬다.

솔직히 말하자면 모든 내용에 100% 공감하지는 못했다.

이를테면 디미터 법칙을 항상 지켜야 한다고 되어 있는데, 그러면 메소드 체이닝은? 같은 의문도 있었다.

 

하지만 책에 서술된 대부분의 방법론들에는 감이 많이 되었다.

열거된 여러가지 방법들 중, 나에게 특별히 인상깊었던 것 몇 가지를 정리한다.

변수명과 함수명을 짓는 방법

내가 변수명과 함수명을 지으면서 가장 많이 했던 고민은 '이게 이렇게 길어져도 되나?'였다.

가령 리소스 id로 content description을 가져오기 위해 getContentDescriptionByResId()라는 함수명이 쓰고 싶은 거다.

함수의 기능에 대한 모든 정보를 담으려면 저 네이밍이 가장 마음에 드는데, 너무 길어서 늘 고민이었다.

더 간결하게 표현할 수 있는데 내가 너무 서술적으로 가져가려고만 하는 것인가 하고 고민을 했었다.

 

그런데 이 책에서는 서술적인 네이밍을 사용하는 것이 이상적이라고 이야기한다.

간결하지만 의도를 다 표현하지 못하는 이름보다는, 충분히 의도를 표현하는 긴 이름이 훨씬 좋다고 말한다.

저자가 이야기하는 네이밍의 기준 중 대표적으로 3가지가 기억난다.

 

- 발음하기 쉬운: 약어라는 이유로 htsp와 같은 읽기 힘든 변수명을 쓰지 않을 것

- 검색하기 쉬운: 코드를 찾는 사람이 ide에서 기능에 따라 검색하기 쉬울 것

- 의도가 드러나는: 변수명/함수명을 보고 어떤 기능을 하는지 & 어떤 목적을 갖는지 알 수 있을 것

보이스카우트 규칙

'캠프장은 처음 왔을 때보다 더 깨끗하게 해 놓고 떠나라.'

책에서 반복적으로 언급되는 보이스카우트 규칙이다.

코드를 수정할 때 기존에 있던 코드를 조금이라도 더 깔끔하게 만들어 놓자는 의미를 갖는다.

 

정리되지 않은 코드에도 새로운 기능을 추가할 수는 있다.

하지만 이런 패턴이 반복되면 정리되지 않은 코드는 점점 더 난잡해진다.

그리고 정말 코드를 정리해야 하는 상황이 왔을 때는 이미 너무 늦어버려서 코드 전체를 갈아엎어야 할 수 있다.

따라서, 단순한 기능을 추가하더라도 기존에 있던 코드를 조금씩이라도 개선하는 습관이 필요하다.

위에서 아래로 코드 읽기: 내려가기 규칙

코드의 서술 순서는 그 가독성에 있어서 상당히 중요하다.

어떤 클래스를 이해하기 위해서 맨 위의 변수를 읽고, 맨 아래에 있는 함수를 이해하고, 중간 메소드들을 한참동안 뒤적거려야 한다면, 뭔가 서술 순서가 잘못되었을 확률이 높다.

 

코드는 신문 기사를 읽듯이, 위에서 아래로 읽어 내려가며 이해할 수 있어야 한다.

기능은 위에서부터 아래 순서로 읽어내릴 수 있게 서술되어야 하며,

비슷한 기능은 서로 가까운 행에 배치하면 읽는 사람이 이해하기 쉽다.

한 번에 한 가지 일만

저자는 하나의 메소드는 한 가지 일을 수행해야 한다고 말한다.

여기에서 '한 가지 일'이란, 기능 단위에서의 한 가지 일을 말한다.

 

가령 calculateDistance(x, y)라는 메소드가 이렇게 생겼다면 잘못이다.

fun getCloserPoint(src: Point, dest1: Point, dest2:Point): Point{
    val calculator = DistanceCalculator()
    val distance1 = calculator.getDistance(src, dest1)
    val distance2 = calculator.getDistance(src, dest2)
    return if (distance1 > distance2) dest1 else dest2
}

언뜻 보기에는 한 가지 기능만 하는 것처럼 보이지만, 잘 보면 calculator를 새로 생성하는 작업이 포함되기 때문이다.

이 경우 프로그래머가 getCloserPoint()함수를 여러 번 호출한다면, calculator는 반복적으로 생성된다.

 

이처럼 코드가 이렇게 한 가지 일만 수행하지 않고 부수적인 효과를 발생시킨다면,

메소드 사용자의 의도와는 다른 기능이 자신도 모르는 사이에 함께 실행될 수 있어 좋지 못하다.

주석은 나쁜 코드를 보완하지 못한다.

그 전까지 나는 독자가 이해하기 어려울 것 같은 메소드에는 주석을 달곤 했다.

그리고 이해할 수 있는 코드이더라도, 부연설명을 하고 싶으면 주석을 달기도 했다.

심지어는 메소드가 무슨 일을 하는지 알려주기 위해 일일이 docstring을 달기도 했다.

 

하지만 책에서는 주석을 남용하지 말라고 이야기한다.

아니, 가급적이면 사용하지 말라고 이야기한다.

주석은 꼭 필요한 경우에 꼭 필요한 위치에만 사용해야 한다고,

 

실제로 책에 언급된 코드를 보면 모든 위치에 주석이 있는 것보다, 주석이 아예 없는 편이 더 가독성이 좋다.

주석이 너무 많으면 주석을 읽는 데에 코드를 읽는 것보다 더 긴 시간이 드는 기현상이 일어난다.

또한 주석이 아주 많이 필요하다는 것은, 그만큼 코드가 정리되지 않았다는 의미이기도 하다.

 

따라서. 주석은 어떤 뚜렷한 의도를 표시하기 위해서만 사용해야 한다.

주석으로 부연 설명이 필요한 코드라면, 주석을 달 게 아니라 리팩토링이 필요한 것이다. 

팀 규칙

팀 규칙이란 말 그대로 팀에서 정한 규칙이다.

즉, 팀에서 정한 규칙에 따라 코드를 작성하는 게 좋다는 거다.

 

너무 당연한 이야기이지만 내게는 중요한 이야기이기도 했다.

입사 이후 협업을 하면서 다른 분들의 코드를 처음으로 읽고 수정하게 되었는데,

여러 사람이 다 완전히 다른 스타일로 코딩을 한다면 정말 뒤죽박죽이겠다는 생각을 했다.

 

주석을 다는 방식이든, 변수의 네이밍이든, (직접적인 코드 이야기는 아니지만) git 브랜칭이든,

함께 작업하는 사람들과 정해진 규칙으로 코딩하면 더 효율적인 협업이 되리라.

모든 테스트가 돌아가게 하라 (TDD)

2013년 책인데 TDD(Test-Driven Development)에 대한 이야기가 많았다.

주로 통과할 테스트들을 미리 작성해 둔 후,

코드가 조금 개선될 때마다 항상 이 테스트가 모두 돌아가는 상태를 유지하라는 내용이다.

 

아직 제대로 테스트코드를 작성해본 적조차 없어서 완전히 이해하지는 못했겠지만,

미래에 TDD를 공부하고 적용하게 되면 와닿을 것 같아서 기록해 둔다.

나중에 다시 읽고 싶은 책

클린 코드는 주니어에게도 필독서겠지만, 먼 미래에 코딩에 더 익숙해졌을 때에도 다시 읽어보고 싶은 책이다.

특히 동시성 프로그래밍이나 TDD에 대한 내용은 지금은 읽어도 100% 이해했다는 느낌을 받기 어려웠다.

왜냐하면 아직 동시성 프로그래밍도, TDD도 복잡하게 다뤄본 적이 없으니까.

나중에 이 개념들에 대해서 더 잘 알게 되고 나서 다시 한 번 읽어 볼 생각이다.