[개발서적] Clean Code 1. 깨끗한 코드

[나쁜코드]

80년대 후반 킬러 앱 하나를 구현한 회사가 있었다.제품은 커다란 인기를 끌었지만,이전 버전에 있었던 버그가 다음 버전에도 그대로 남아있었다. 그 결과 회사는 얼마 못가 망했다.

 

회사가 망한 원인은 바로 나쁜 코드 탓이다.

 

우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다.(크게 공감…) 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.

 

르블랑의 법칙 "나중은 결코 오지 않는다"는 의미로, 개발자가 나중에 수정하겠다고 미룬 나쁜 코드나 버그는 결국 고쳐지지 않고 남아 프로젝트의 개발 속도와 생산성을 저하시킨다는 원칙입니다.

 

[나쁜 코드로 치르는 대가]

나쁜 코드는 개발 속도를 크게 떨어뜨린다. 또한 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 근접한다.

 

https://clearpal7.blogspot.com/2017/02/cleancode.html

 

그럼 코드가 왜 그렇게 되었을까? 좋은 코드가 어째서 순식간에 나쁜 코드로 전략할까? 우리는 온갖 이유를 들이댄다.

• 원래 설계를 뒤집는 방향으로 요구사항이 변했다.
• 일정이 촉박해 제대로 할 시간이 없었다.
• 멍청한 관리자와 조급한 고객과 쓸모없는 마케팅 부서 탓이다.

그러나 잘못은 우리 프로그래머에게 있다. 우리가 전문가답지 못했기 때문이다.

어째서 우리의 잘못일까?

 

• 관리자와 마케팅은 약속과 공약을 내걸며 우리에게 정보를 구한다.
• 사용자는 요구사항을 내놓으며 우리에게 현실성을 자문한다.
• 프로젝트 관리자는 일정을 잡으며 우리에게 도움을 청한다.

 

우리는 프로젝트를 계획하는 과정에 깊숙히 관여한다. 그러므로 프로젝트의 실패는 우리에게도 커다란 책임이 있다. 특히 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다.

 

그럼 우리는 이렇게 반문할 수도 있다. “상사가 시키는 대로 하지 않으면 짤린다구요!” 글쎄, 겉으로 아닌 듯 행동해도 대다수 관리자는 진실을 원한다. 그들이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.

 

비유를 하나 들겠다. 내가 의사이고, 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까. 확실히 환자가 상사지만, 의사는 단호하게 거부한다. 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 또한 환자 말을 그대로 따르는 행동은 전문가답지 못하니까.

 

프로그래머는 나쁜 코드를 양산하면 기한을 맞추지 못한다. 기한을 맞추는 유일한 방법은, 그러니까 빨리가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

 

[깨끗한 코드란?]

지금부터 우리 분야에서 아주 유명하고 노련한 프로그래머들에게 의견을 물었다.

 

비야네 스트롭스트룹 - c++ 창시자

나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬어진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화 코드를 망치려는 유혹에 빠지지 않는다. 깨끗한 코드는 한 가지를 제대로 한다.

 

비야네에 따르면 깨끗한 코드는 ‘보기에 즐거운’ 코드다. 깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다는 뜻이다.

나쁜 코드는 나쁜 코드를 유혹한다. 나쁜 코드를 고치면서 오히려 다 나쁜 코드를 만든다. 이를 깨진 창문이라는 비유로 설명할 수 있다.

 

창문이 깨진 건물은 누구도 상관하지 않는다. 창문이 더 깨져도 상관하지 않는다. 마침내 자발적으로 창문을 깬다. 외벽에 그려진 낙서를 방치하고, 차고에 쓰레기가 쌓여도 치우지 않는다. 일단 창문이 깨지고 나면 쇠퇴하는 과정이 시작된다.

 

 

그래디 부치 - Object Oriented Analysis and Design with Application 저자

깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.

 

그래디는 가독성을 강조한다. 특히, 깨끗한 코드가 잘 쓴 문장처럼 읽혀야 한다는 시각이 좋다. 코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다.

 

 

데이브 토마스 - OTI 창립자이자 이클립스 전략의 대부

깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미있는 이름이 붙는다. 특정 목적을 달성하는 방법은 (여러가지가 아니라) 하나만 제공한다. 의존성은 최소이며, 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표한할 수 없기에 코드는 문학적으로 표현해야 마땅하다.

 

데이브는 ‘가독성’과 더불어 깨끗한 코드란 다른 사람이 고치기 쉽다고 단언한다. 실제로 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다!

 

데이브는 깨끗한 코드를 테스트 케이스와 연관짓는다. 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 아무리 코드가 우아해도, 아무리 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 않다.

 

요점은 인간이 읽기 좋은 코드를 작성하라는 말이다.

 

 

론 제프리스 - Extreme Programming Installed 저자

최근 들어 나는 켄트 벡이 제안한 단순한 코드 규칙으로 구현을 시작한다. 중요한 순으로 나열하자면 간단한 코드는

• 모든 테스트를 통과한다.
• 중복이 없다.
• 시스템 내 모든 설계 아이디어를 표현한다.
• 클래스, 메서드, 함수 등을 최대한 줄인다.

요약하면 다음과 같다. 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라.

 

 

워드 커닝햄 - 위키 창시자

코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.

 

깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다고 워드는 말한다. 명백하고 단순해 마음이 끌리는 코드가 깨끗한 코드다. 모듈을 읽으면 다음에 벌어질 상황이 보인다.

 

또한 워드는 언어를 단순하게 보이도록 만드는 책임이 우리에게 있다고 한다! 즉, 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다.

 

[필자의 생각]

이 책은 우리 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다. 우리가 가르치는 기법을 따른다면 깨끗하고 수준 높은 코드를 작성하리라 감히 장담한다.

 

[우리는 저자다]

우리는 저자다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다. 누군가의 코드를 읽다보면(깨끗하지 못한), 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘긴다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.

 

[보이스카우트 규칙]

잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.

미국 보이스카우트가 따르는 간단한 규칙이 우리 전문가들에게도 유용하다.

 

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

 

 

한꺼번에 많은 시간과 노력을 투자해 코드를 정히라 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을제거하고, 복잡한 if문 하나를 정리하는 것으로 충분하다.