[Clean Code][TIL] 깨끗한 코드
이 포스트는 로버트 C.마틴의 Clean Code 속 추천사부터 1장까지(1p ~ 20p) 내용에 대한 후기입니다.
기억하고 싶은 내용
모드럽의 추천사 중 다음과 같은 내용이 있습니다.
“집 주인이라면 누구나 알겠지만, 지속적인 개선과 보살핌은 결코 끝나지 않는다.” (추천사 xxvi)
이 내용이 프로그램의 유지 보수 작업에 대한 프로그래머의 태도를 잘 설명했다고 생각합니다.
집 주인은 입주민을 위해 집을 유지 보수해야 합니다.
장마철에는 빗물이 넘치지 않도록 하수구도 살펴보고 폭설에는 지붕에 쌓인 눈도 치우며,
사계절이 지남에 따라 갈라지는 페인트와 외벽도 새롭게 고쳐야 합니다.
프로그램도 집처럼 프로그래머가 설계부터 코드 작성까지 직접 만드는 집이라고 볼 수 있습니다.
때문에 프로그램도 고객의 요구사항 에 맞춰 유지, 보수 작업이 필요합니다.
그 예시로 UI의 위치가 변경될 수 있고, 실행 속도를 위해 로직이 변경될 수 있습니다.
유지 보수를 위해 몇 달 전에 작성한 코드를 보면 전혀 모르는 사람이 작성한 코드처럼
스스로에게 이 변수는 어디서 사용하지?, 이 함수는 무슨 역할을 하지? 라는 질문을 하게 됩니다.
이 문제에 대한 노련한 프로그래머들의 해결책을 알 수 있는 부분이 1장. 깨끗한 코드 입니다.
위키(Wiki)의 창시자 워드 커닝햄(ward Conningham)은 이 문제에 대해 다음과 같이 답했습니다.
코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드다. (1장 15p)
이 해결책이 깨끗한 코드라는 난해한 단어를 잘 풀어 설명했다고 생각했습니다.
변수, 함수, 클래스 등 모든 코드를 읽고서 설계된 이유를 짐작할 수 있을 뿐만 아니라
설계 목적을 그대로 수행하는 것이 깨끗한 코드라고 생각했기 때문입니다.
떠오른 생각
우리들의 밥 아저씨(로버트 C.마틴)는 깨끗하고 수준 높은 코드를 지향하면서도 다음과 같이 말했습니다.
물론 절대적으로 옳은 문파는 없다. (1장 16p)
왜 절대적으로 옳은 코드는 없을까?
코드 작성은 대부분 2명 이상의 팀에서 함께 진행합니다.
이때 원활한 개발을 위해 팀에서는 코드 작성 규칙(Coding Conventions) 을 작성하게 됩니다.
이 문서는 프로그래머 각자의 취향에 맞춰 코드를 작성하는 것이 아니라 일관된 코드 작성을 위해
코드를 어떻게 작성할지 미리 규칙을 만드는 것입니다.
(대표적으로 Google Style Guide이 있습니다.)
저는 졸업작품을 제작하면서 팀원과 함께 Google C++ Style Guide을 코딩 컨벤션으로 채택 했었습니다.
코딩 컨벤션은 코드 작성 규칙이 담겨 있기 때문에 프로그래머는 모든 내용을 숙지하고 있어야 합니다.
그러나 직접 작성하지 않은 코딩 컨벤션은 생명 주기가 짧은 지역 변수부터 전역으로 사용되는 헤더파일의 이름까지
한 단어의 코드를 작성할 때 마다 들여다 보게 되었습니다.
“구글이 작성한 코딩 컨벤션은 절대적으로 옳다” 라는 이유만으로 채택된 코딩 컨벤션은
급하게 코드를 작성할 때 규칙이 아니라 습관대로 코드를 작성하게 되었고
이에 대한 부작용으로 나만 이해하는 코드 가 점차 증가해
결국 코드를 병합할 때 마다 팀원에게 직접 코드를 설명해야 하는 상황까지 직면 했었습니다.
Clean Code의 추천사와 1장을 읽고서
만약, 구글 코딩 컨벤션을 기반으로 팀원들의 코딩 스타일과 프로젝트의 특징을 고려한 뒤
새로운 문서를 작성했었다면 코드를 직접 설명하는 최악의 상황을 피하고
깨끗한 코드를 작성할 수 있지 않았을까 라는 생각을 하게 되었습니다.
궁금한 내용
론 제프리스(Ron Jeffries)는 깨끗한 코드 설명 중 다음과 같이 말했습니다.
“시스템 내 모든 설계 아이디어를 표현한다.” (1장 13p)
설계 아이디어를 시스템 안에 표현하는 방법은 무엇이 있고
이러한 표현으로 얻을 수 있는 장점이 무엇이 있는지 궁금하게 되었습니다.