나쁜 코드
개발자라면 모두 나쁜 코드를 짠 적이 있고, 나쁜 코드로 인해 고생한 경험이 있을 것이다.
- 제대로 짤 시간이 없다고 생각해서
- 다른 업무가 밀려 빨리 해치우려고
그리고 나중에 다시 수정하자고 다짐해도, 나중은 결코 오지 않는다.
나쁜 코드로 치르는 대가
나쁜 코드는 개발 속도를 크게 떨어뜨린다. 얽히고 설킨 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생기고, 이걸 해결하다 다시 얽히고 설킨 코드를 더하게 된다.
이렇게 나쁜 코드가 쌓이면 팀 생산성은 떨어지다가 마침내 0에 근접한다.
생산성을 증가시키기 위해 인력을 추가로 투입해도, 새 인력은 시스템 설계에 대한 조예가 깊지 않다. 설계 의도에 맺는 변경과 설계 의도에 반하는 변경을 구분하지 못한다.
이 상태에서 생산성을 높여야 한다는 극심한 압력에 시달리면 결국 더 나쁜 코드를 더 많이 양산하게 되는 것이다.
원대한 재설계의 꿈
결국 이렇게 생산성이 떨어지면 새로운 팀을 꾸려 재설계를 하게 된다.
그러면 아래와 같이 두 개의 팀으로 나뉜다.
- 기존 프로젝트를 유지보수하는 팀
- 재설계하는 팀
이때, 재설계하는 팀은 기존 시스템의 기능을 모두 제공해야 해며 기존 시스템에 가해지는 변경도 모두 따라잡아야 한다.
때때로 이 과정은 아주 오랫동안 이어져서 10년 넘게 걸리는 경우도 있다.
태도
우리는 관리자와 마케팅이 정보를 구하지 않더라도 적극적으로 정보를 제공해야 한다.
- 사용자는 요구사항을 내놓으며 우리에게 현실성을 자문한다.
- 프로젝트 관리자는 일정을 잡으며 우리에게 도움을 요청한다.
우리는 프로젝트를 계획하는 과정에 깊숙이 관여한다. 그러므로 프로젝트 실패는 우리에게도 커다란 책임이 있고, 특히 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다.
좋은 코드를 사수하는 일은 우리 프로그래머들의 책임이다. 관리자가 나쁜 코드의 위험을 이해하지 못한다면, 그의 말을 그대로 따르는 행동은 전문가 답지 못하다.
원초적 난제
나쁜 코드는 업무 속도를 늦춘다. 프로그래머는 그럼에도 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다.
진쩌 전문가는 이가 틀렸다는 사실을 잘 안다. 나쁜 코드를 양산하면 기한을 맞추지 못한다.
기한을 맞추는 오일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
깨끗한 코드
깨끗한 코드라는 예술
깨끗한 코드를 어떻게 작성할까? 깨끗한 코드가 무엇인지 모르면 깨끗한 코드를 만들려고 애써봤자 소용이 없다.
깨끗한 코드를 작성하려면 ‘청결’이라는 힙겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 기술이 필요하다.
열쇠는 ‘코드 감각'이다. 이게 있으면 좋은 코드와 나쁜 코드를 구분하고, 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.
즉, 우리는 ‘코드 감각’으로 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 떠올릴 수 있어야 한다.
깨끗한 코드란?
이는 프로그래머 수만큼이나 정의가 다양하다.
비야네 스트롭스트룹
- 우아하고 효율적인 코드
- 논리가 간단하여 버그가 숨어들지 못한다.
- 의존성을 최대한 줄여야 유지보수가 쉬워진다.
- 오류는 명백한 전략에 의거해 철저히 처리한다.
- 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.
- 깨끗한 코드는 한 가지를 제대로 한다.
즉, 깨끗한 코드는 ‘보기에 즐거운’ 코드다. 잘 만든 오르골이나 잘 디자인된 차를 접할 때처럼 깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다는 뜻이다.
그리고 ‘효율’은 단순히 속도만을 뜻하지 않는다. 나쁜 코드는 나쁜 코드를 ‘유혹’한다. 즉, 나쁜 코드를 고치면서 더 나쁜 코드를 만든다는 뜻이다.
프로그래머들이 대충 넘어가는 부분 중 하나가 오류 처리다. 메모리 누수, 경쟁 상태(race condition), 일관성 없는 멸명법이 또 다른 예다. 깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하는 코드다.
마지막으로 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한 가지에 집중해야 한다.
그래디 부치
- 깨끗한 코드는 단순하고 직접적이다.
- 깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
- 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
- 코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다.
Big 데이브 토마스
- 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
- 단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
- 특정 목적을 달성하는 방법은 하나만 제공한다.
- 의존성은 최소이며 각 의존성을 명확히 정의한다.
- API는 명확하며 최소로 줄였다.
- 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기 때문에 코드는 문학적으로 표현해야 마땅하다.
- 요점은 인간이 읽기 좋은 코드를 작성하라는 말이다.
가독성을 강조하지만, 다른 사람이 고치기 쉽다고 단언한다. 읽기 쉬운 코드와 고치기 쉬운 코드는 다르다.
테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. TDD와 연결되는 개념.
큰 코드보다는 작은 코드에 가치를 둔다.
마이클 페더스
- 깨끗한 코드는 언제나 누군가 주의깊게 짰다는 느낌을 준다.
- 고차려고 살펴봐도 딱히 손 댈 곳이 없다.
한 마디로 요약하면 ‘주의'다. 이것이 이 책의 주제(코드를 주의 깊게 짜는 방법)이다.
론 데프리스
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
같은 작업을 여러번 반복(중복)한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다.
표현력은 의미 있는 이름을 포함한다. 그리고 여러 기능을 수행하는 객체와 메서드를 리팩터링 기법을 적용해 , 기능을 명확히 기술하는 메서드 하나와 실제로 수행하는 메서드 여러 개로 나누는 것도 말한다.
모든 프로그램은 아주 유사한 요소로 이뤄진다. 예를 들어 집합에서 항목 찾기가 있다. 어떤 집합에서 특정 항목을 찾아낼 필요가 있을 때, 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싼다.
그러면 여러 장점이 생긴다.
- 실제 구현은 언제든지 바꿔도 괜찮다.
- 온갖 집합 기능을 구현하느라 시간과 노력을 낭비할 필요가 없다.
- 진짜 문제에 신경 쓸 여유가 생긴다.
워드 커닝햄
- 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다.
- 코드가 그 문제를 풀기 위한 언어처럼 보인다.
우리들 생각
바로 이 책이 저자가 생각하는 깨끗한 코드를 정의한다. 그러나 이 책에서 주장하는 바가 절대적으로 옳다라는 단정은 금물이다.
이 책에서 주장하는 기법 다수는 논쟁의 여지가 있다. 그러므로 동의하든 하지 않든 다양한 시각을 이해하고 존중하려 애써야 한다.
우리는 저자다
코드를 읽은 시간 대 코드를 짜는 시간의 비율은 10대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.
그러므로 읽기 쉬운 코드가 매우 중요하다.
보이스카우트 규칙
시간이 지나도 언제나 깨끗하게 유지해야 한다. 시간이 지나면서 엉망으로 전락하는 코드가 한둘이 아니다. 그러므로 우리는 적극적으로 코드의 퇴보를 막아야 한다.
미국 보이스카우트가 따르는 규칙이 우리 전문가들에게도 유용하다.
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
Reference
참고 서적
