[클린코드] 1. 깨끗한 코드

코드는 언제나 존재한다.

여러 개발자들은 코드는 더 이상 문제가 아니라고, 새로운 기술이나 비지니스 모델의 요구사항에 집중해야 한다고 생각하는 사람도 있다.

실제로 코드의 종말이 코앞에 닥쳤다고 주장하는 사람이 없지 않다. 코드를 자동으로 생성하는 시대가 다가온다는 말이다.

그때가 되면 프로그래머는 필요가 없다.

 

하지만 이것은 절대로 불가능한 기대다. 

인간 조차도 고객의 막연한 감정만 갖고는 성공적인 시스템을 구현하지 못한다.

궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다.

요구사항에 더욱 가까운 언어를 만들 수도 있고, 요구사항에 정형 구조를 뽑아내는 도구를 만들 수도 있다.

하지만 어느 순간에는 정밀한 표현이 필요하다. 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재하리라.

나쁜 코드

많은 개발자들은 코드를 짜면서 나쁜 코드를 알면서도 나쁜 코드를 작성하곤 한다.

이런 나쁜 코드들은 초기에는 문제가 없겠지만 점차 우리가 만든 시스템을 파괴시킨다. 결국 그 시스템은 없어질것이다.

나쁜 코드를 짜면서 프로그램이 정상적으로 돌아간다고 안도감을 느끼며, 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로하거나 나중에 정리하겠다고 다짐한다.

모든 프로그래머들은 알겠지만 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

내가 작성한, 남들이 저질러놓은 쓰레기 코드로 고생한 경험이 있을것이다.

이러한 코드의 프로젝트는 여러가지의 대가를 치뤄야 한다.

• 프로젝트 초반에는 빠르게 개발되지만 1~2년만에 엄청나게 느려지는 팀도 많다.
• 코드를 고칠때마다 엉뚱한 곳에서 문제가 생긴다. 간단한 변경은 없다.
• 매번 얽히고설킨 코드를 해독해서 얽히고설킨 코드를 더한다.
• 시간이 지나면 쓰레기 더미는 점점 커지며 청소할 방법이 없다. 불가항력이다.
• 나쁜 코드가 쌓일수록 팀 생산성이 떨어진다. 결국 생산력은 0이 된다.
• 만약 재설계를 한다면 처음 프로젝트를 시작했을때 보다 엄청난 시간과 비용이 든다.
• 프로그래머들의 정신 건강에도 좋지 않을 뿐더러, 팀간에 필요없는 마찰도 생길것이다.

깨끗한 코드란?

아마 프로그래머 수만큼이나 정의도 다양할 것이다.

 

비야네 스트롭스트룹(Bjarne Stroustrup)

C++ 창시자이자 The C++ Programming Language 저자

• 논리가 간단해야 버그가 숨어들지 못한다.
• 의존성을 최대한 줄여야 유지보수가 쉽고 오류는 명백한 전략에 의거해 철저히 처리한다.
• 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. (속도 뿐만 아니라 CPU 자원 낭비도 포함)
• 깨끗한 코드는 한 가지를 제대로 한다.

그래디 부치(Grady Booch)

Object Oriented Analysis and Design with Application 저자

• 깨끗한 코드는 단순하고 직접적이고, 잘 쓴 문장처럼 읽힌다.(가독성)
• 깨끗한 코드는 설계자의 의도를 숨기지 않늗나. 명쾌한 추상화와 단순한 제어문으로 가득하다.

데이브 토마스(Dave Thomas)

OTI 창립자이자 이클립스 전략의 대부

• 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
• 단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
• 모든 이름에 의미있는 이름이 붙는다.
• 특정 목적을 달성하는 방법은 하나만 제공한다.
• 의존성은 최소이며 각 의존성을 명확히 정의한다.
• API는 명확하며 최소로 줄여야 한다.

마이클 페더스(Michael Feathers)

Working Effectively with Legacy Code 저자

• 깨끗한 코드는 언제나 누군가가 주의 깊게 짰다는 느낌을 준다.
• 이미 모든 사항을 고려했으므로 고치려고 살펴봐도 딱히 손 댈 곳이 없다.

론 제프리스(Ron Jeffries)

Extreme Programming Installed와 Extreme Programming Adventrue in C# 저자

• 중복이 없다.
• 시스템 내 모든 설계 아이디어를 표현한다.
• 클래스, 메서드, 함수 등을 최대한 줄인다.
• 한가지 기능만 수행한다.
• 제대로 표현한다.
• 작게 추상화한다.

위드 커닝햄(Ward Cunningham)

위키(Wiki) 창시자, 피트(Fit) 창시자, 익스트림 프로그래밍 공동 창시자

• 코드를 읽으면서 짐작했던 기능을 각 루틴대로 수행한다.
• 코드가 문제를 풀기 위한 언어처럼 보인다. (독해할 이유가 없다.)

시간이 없어서..

깨끗한 코드를 작성할 시간이 없다고 하는 프로그래머들도 많다.

초반에는 정상적으로 돌아만 가는 대충 짜는 코드가 빠를수도 있지만, 진정으로 괜찮은 시스템을 구축하고 싶다면 깨끗한 코드를 작성해야 한다.

 

읽기 쉬운 코드를 작성하는 것은 쉽지 않지만 매우 중요하다.

우리는 새 코드를 짜면서 끊임없이 기존 코드를 읽어야 한다. 결국 코드를 짜는 시간 중 대부분의 시간은 기존 코드를 독해하는 시간이 되곤 한다.

코드가 읽기 쉽다면 기존 코드를 독해하는 시간을 줄일 수 있다.

그러므로 급하다면, 서둘러 끝내야 한다면, 쉽게 짜려면 읽기 쉽게 만들면 된다.

진짜 전문가들은 나쁜 코드가 나중에는 오히려 기한을 늘릴 수 있다는 것을 알고 있다.​

 

시간이 지나도 언제나 깨끗하게 유지해야 한다.

체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.

한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.