깨끗한 코드

나쁜 코드 

80년대 후반 킬러 앱 하나를 구현한 회사가 있었다. 제품은 커다란 인기를 얻으며 수많은 전문가가 구매해 사용했다. 그런데 제품 출시 주기가 점점 늘어지다고 프로그램의 시동 시간도 길어지고 프로그램이 죽는 횟수도 늘어나다 사용자가 줄어들어 결국 회사가 망했다. 20여년 지난 후 그 회사 초창기 직원을 우연히 만나 물어보니 원인은 출시가 바빠 코드를 마구 짰고, 기능을 추가할 수록 코드는 엉망이 되었고 결국 감당이 불가능한 수준에 이르러 회사가 망하게 된 것이다.  프로그래머라면 누구나 나쁜 코드로 고생하거나 나쁜코드 를 생성해본 적이 있을 것이다. 우리는 나쁜 코드를 생성하고 나중에 꼭 손보겠다고 생각한다. 또한 돌아간다는 사실에 안도감을 느끼며 안돌아 가는 프로그램보다 돌아가는 쓰레기 좋다고 스스로를 위로 한 경험도 있을 것이다. 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다. 

 

나쁜 코드로 치르는 대가 

 나쁜 코드는 개발 속도를 크게 떨어뜨린다.  나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 마침내 0에 근접한다.  생산성이 떨어지면 관리층은 복구를 시도한다. 인력추가로. 하지만 새 인력은 생산성을 높여야 한다는 압박에 나쁜 코드를 더 많이 양산한다. 그래서 더더욱 떨어져 거의 0이 된다. 

 

원대한 재설계의 꿈 

 나쁜 코드가 많은 코드로 더 이상 일하지 못하는 상태가 재설계를 하게 된다. 새로운 타이거 팀이 구성되고 새로운 프로젝트이기 때문에 유능하고 똑똑한 사람의 지원을 넣고 나머지는 계속해서 시스템을 유지보수 한다.   타이거 팀은 운영에서 변경되는 부분을 합쳐 새 시스템을 만들어야 되기 때문에 최고 10년 걸리는 경우도 보았다고 한다. 결국 새로운 팀이 새로운 재설계를 들어가도 기존 시스템 기능 + 신규 기능까지 하려면 계속적으로 시간이 소모된다. 결국 코드를 작성할 때마다 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법. 

 

태도 

 간단한 업무라고 예상한 업무가 몇 주동안 늘어진 경험이 있는가? 한줄만 고치면 될 거라 예상했지만 나쁜 코드로 인하여 결국 많은 코드를 수정하는 경험들을 보통 한다. 나쁜 코드는 왜 생길까? 여러가지 이유가 있지만 결국 나쁜 코드를 만드는 것도 코드를 작성하는 본인이 되는 경우가 많다. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까 확실히 환자는 상사다 하지만 의사는 단호하게 거부한다. 이유는 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 환자 말을 그대로 따르는 행동은 전문가 답지 못하다.  좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 

 

원초적 난제 

 나쁜 코드는 업무속도를 낮춘다. 그런데 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다.  나쁜 코드를 양산하면 기한을 맞추지 못한다. 기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. 

 

깨끗한 코드라는 예술? 

 꺠끗한 코드를 어떻게 작성할까? 그림을 그리는 행위와 비슷, 청결이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요. 

 

깨끗한 코드란? 

 비야네 스트롭스트룹 ( C++ 창시자이자 The C++ Programming Language 저자)  

 비야네는 우아하고 효율적인 코드를 좋아한다.  깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다.  나쁜 코드는 나쁜 코드를 유혹한다.  세세한 사항까지 꼼꼼하게 신경 쓰라.  깨끗한 코드는 한가지에 집중한다. 주변 상황에 현혹되거나 오염되지 않는 채 한길만 걷는다. 

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

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

 ‘큰(Big)’ 데이브 토마스 (OTI 창립자이자 이클립스 전략의 대부) 

 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.  깨끗한 코드에는 의미 있는 이름이 붙는다.  특정 목적을 달성하는 방법은 하나만 제공한다.  의존성은 최소이며 각 의존성을 명확히 정의한다.  테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 

마이클 페더스 (Working Effectively with Legacy Code 저자) 

 깨끗한 코드의 특징은 모두를 아우르는 특징이 하나 있다.  고치려고 살펴봐도 딱히 손 댈 곳이 없다.  깨끗한 코드는 주의 깊게 작성한 코드. 

론 제프리스 (Extreme Programming Intalled 와 Extreme Programming Adventure in C# 저자) 

 중복을 피하라.  한 기능만 수행하라.  제대로 표현하라.  작게 추상화하라. 

워드 커닝햄 (위키 창시자, 피트 창시자, 익스트림 프로그래밍 공동 창시자) 

 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.  깨끗한 코드는 읽으면서 놀 날 일이 없어야 한다. 

우리는 저자다 

 Javadoc 에서 @author 필드는 저자를 소개한다. 코드를 작성할 때는 자신이 저자라는 사실을 기억해야한다.  

보이스카우트 규칙 

 시간이 지나도 언제나 깨끗하게 유지해야 한다. 시간이 지날수록 코드가 좋아지는 프로젝트에서 작업한다고 상상해봐라. 

프리퀄과 원칙 

 SRP (The Single Reponsibility Principle) : 단일 책임의 원칙 클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다. OCP (The Open Closed Principle) : 개방 폐쇄의 원칙 클래스는 확장에 열려있어야하며, 변경에 닫혀있어야 한다. LSP (The Liskov Substitution Principle) : 리스코프의 치환 법칙 상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다. DIP (The Dependency Inversion Principle) : 의존 역전의 법칙 추상화에 의존해야하며, 구체화에 의존하면 안된다. ISP (The Interface Segregation Principle) : 인터페이스 분리 원칙 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.