클린 코드를 싫어하는 사람들
by Understand가독성은 중요한 개발 원칙 중 하나이다.
개발 활동 대부분의 시간은 코드를 읽는 데 사용하기 때문이다.
하지만 클린 코드를 싫어하는 사람들이 있다.
정확히는 로버트 C. 마틴의 ‘클린 코드’ 책을 싫어하는 사람들이 있다.
주니어 개발자들에게 클린 코드 책이 많이 추천되고 있는데, 왜 이 책을 싫어하는 사람들이 많을까?
“주니어 개발자들에게 클린 코드 책이 많이 추천되고 있는데”
문제의 시작은 바로 이 부분이라고 한다.
주니어에게 읽으라고 추천되는 사회적 상황, 로버트 마틴이라는 애자인 선언에 나오는 유명한 사람의 책이라는 것은 권위로서 작용한다.
이러한 권위와 함께 문체에서 나타나는 강한 의견 주장은 때로는 무조건적인 수용으로 이어질 수도 있다.
그리고 이러한 수용은 의도와는 반대로 소프트웨어 개발에 악영향을 미칠수도 있다.
그리고 악영향을 경험해본 사람들은 클린 코드 책에 대해 크게 비판한다.
클린 코드 책에는 유용한 조언들이 많다. 하지만 논쟁거리가 되는 조언들도 많다.
또한 책에 있는 예제 코드도 오히려 안좋은 코드인 경우도 많다.
그런데 충분한 개발 경험이 없을 때는 책에 대해서 이러한 점을 구분하며 비판적으로 읽기 어렵다.
사람들은 여러 부분에 대해서 책을 비판하고 있지만 그중에서 중복 제거와 주석에 대한 3가지 내용을 정리했다.
(로버트 C.마틴의 커리어나 책이 오래된 것, 다양한 언어 패러다임을 다루지 못한 것들에 대한 내용은 제외했다.
결국 내용이 좋으면 이러한 부분이 상관없다고 생각했기 때문이다.)
DRY
DRY는 Don’t repeat yourself의 줄임말로, 코드 반복을 피하라는 원칙이다.
하지만 시간이 흐르면서 때로는 코드를 반복해도 괜찮다는 의견들이 많아지고 있다.
코드 반복도 비용이다.
하지만 코드를 반복해서 지불해야 하는 비용보다 반복을 피할 때 더 큰 비용을 지불해야 할 수도 있다.
예를 들어 두 개의 서로 다른 모듈이 비슷한 코드를 갖는 경우가 있다. DRY 원칙을 엄격히 적용하면 두 모듈을 합치거나 공통 라이브러리를 만들어야 한다. 하지만 이러한 잘못된 추상화는 오히려 모듈간의 독립성을 해칠 수 있다. 이런 경우는 오히려 코드 중복을 허용하면서 모듈간 결합도를 낮추는 것이 더 나은 설계일 수 있다.
함수의 크기는 작아야 한다. 2~4줄 정도로.
함수는 한 가지 기능만을 가져야 한다.
그리고 함수는 되도록 적은 줄 수를 갖는 것이 좋다.
하지만 모든 함수가 2~4줄일 필요는 없다.
하지만 3장 마지막 예제는 모드 함수가 2~4 줄이어야 하나? 라는 질문을 던지게 만든다.
예제에서는 한 줄짜리도 함수로 만든다.
그런데 이게 과연 가독성이 좋을까?
개인적인 경험으로는 함수의 개수가 과도하게 많아지면 여러 함수를 이동해가면서 봐야 해 오히려 가독성이 떨어지는 경우가 있었다.
그래서 나는 함수 크기보다는 가독성이 있는지, 변경 요인이 다른 두 코드가 같은 함수에 있는지 등을 좀 더 고려하는 편이다.
주석
책에서는 주석 작성을 최소화하고 코드 자체로 의도를 명확히 드러낼 수 있도록 해야한다고 말한다.
하지만 이 말의 의미는 주석을 쓰지 말아야 한다는 것은 아니다. 오히려 주석을 적절하게 사용해야 한다는 의미라고 생각한다.
먼저 항상 의도를 드러내도록 코드를 작성할 수는 없다.
때로는 성능을 위해서 가독성을 포기하는 경우도 있다. 또는 복잡한 알고리즘을 구현해야 하는 경우도 존재한다.
이런 코드들은 주석을 통해서 보완해야 한다.
또한 주석 자체는 실제 코드를 이해하는 데 큰 도움이 된다.
오히려 code complete2 같은 책에서는 매개변수나 제약사항 등에 대해서 주석을 작성하라는 조언을 한다.
이런 주석은 코드를 사용할 때 좀 더 맥락을 파악할 수 있게 해준다.
물론 자기 설명적 주석 등은 피하는 것이 좋다고 생각한다.
그 외에도 주석을 통해 문서를 자동으로 만들어주는 도구들이 생기고 있다.
이런 자동화를 위해서는 각 프로젝트나 모듈, 비즈니스 규칙, API 등에 대한 설명을 추가하는 것이 좀 더 나을 수도 있다.
후기
처음 책을 읽을 때는 클린 코드에 있는 내용이 정답이라고 생각했었다.
하지만 실제 업무를 진행하면서, 그리고 다른 사람들이 작성한 비판점들을 읽어보면서 새롭게 생각되는 부분들이 많았다.
로버트 C.마틴, 클린 코드, 그리고 이를 비판하는 사람들 모두 코드의 유지보수가 중요하다는 것에 대한 이견은 없었다. 하지만 코드를 중복해도 되는지, 아니면 이를 없애고 추상화를 하는 것이 더 좋은 것인지에 대한 생각은 조금씩 나뉘는 것 같다.
개인적으로는 이러한 갈등이 생기는 이유가 결국 상황마다 다르기 때문이라고 생각한다.
어떤 경우는 복잡도가 증가해도 코드 반복제거를 하는 것이 더 좋은 경우가 있고, 어떤 경우는 코드를 반복하면서 복잡도를 낮게 유지하는 것이 더 나은 경우도 있는 것 같다.
상황마다 다르다.
이 말이 정말 개발할 때 나를 괴롭힌다.
여러 책을 읽으면서 얻은 얕게 쌓인 지식으로 선택 장애가 생긴 것이다.
이런 상황 속에서 다음 같은 조언이 마음속에 와닿았다.
둘 중 무엇이 더 좋은지 모르겠으면, 일단 적용해 봐. 별로면 고치면 되지.
지금 당장은 잘못된 결정을 하더라도 적용하고 경험을 쌓다 보면 나중에는 나름대로 시야가 생길 거야.
시중에 나와 있는 책들은 같은 상황에서 같은 조언을 하기도, 다른 조언을 하기도 한다.
나의 상황과 정확히 일치하지 않기 때문에 결국 내가 결정 해야 한다.
책을 다양한 선택지가 있다는 정도로 활용하고 실패와 경험을 통해 내 나름대로의 원칙을 세워갈 필요를 느낀다.
Reference
블로그의 정보
BookStoreDiary
Understand