: 깨끗한 코드
- 이 책은 코드를 최대한 다양한 각도에서 살펴보고자 한다.
- 이 책을 읽고나면
- 좋은 코드와 나쁜 코드를 구분하는 능력이 생긴다.
- 좋은 코드를 작성하는 방법도 익힌다.
- 나쁜 코드를 좋은 코드로 바꾸는 실력도 쌓인다.
- 코드를 자동으로 생성하는 시대가 다가오면 프로그래머가 필요가 없을까?
- 그럴 일은 전혀 없다. 코드는 요구사항을 상세히 표현하는 수단이기 때문이다.
- 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍이다.
- 이렇게 명시한 결과가 코드 이다.
- 요구사항을 모호하게 줘도 우리 의도를 정확히 꿰뚫어 프로그램을 완벽하게 실행하는 기계는 절대로 불가능하다.
- 창의력과 직관을 보유한 우리 인간 조차도 고객의 막연한 감정만 갖고는 성공적인 시스템을 구현하지 못한다.
- 제대로 명시한 요구사항은 코드만큼 정형적이며 테스트 케이스로 사용하도 좋다.
- 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다.
- 요구사항에 더욱 가까운언어를 만들 수도 있고, 요구사항에 정형 구조를 뽑아내는 도구를 만들 수도 있다.
- 하지만 어느 순간에는 정밀한 표현이 필요하다. 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재할 것이다.
- 우리는 오랫동안 나쁜 코드에 시달려왔기에 좋은 코드가 중요하다는 사실을 안다.
80년대 후반 킬러앱을 구현한 회사
- 제품이 큰 인기를 끈 프로그램이 있었는데
- 출시 시기가 점차 늘어지고, 이전 버그가 다음 버전에도 그대로 남아있었다.
- 프로그램 시동 시간이 길어지고, 프로그램이 죽는 횟수도 늘어났다.
- 그 회사는 얼마 못가 망했다.
왜 망했을까
- 출시에 바빠 코드를 마구 짰던 것이다.
- 기능을 추가할수록 코드는 엉망이 되어갔고, 결구 감당이 불가능한 수준에 이루렀다.
회사가 망한 원인은 바로 나쁜 코드 탓이었다.
프로그래머라면 누구나 당연히 나쁜 코드로 고생한 경험이 있다.
- 그렇다면 왜 나쁜 코드를 짰는가?
- 우리는 모두 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다.
- 그때 그 당시 우리는
르블랑의 법칙을 몰랐다.
* 르블랑의 법칙:
나중을 결코 오지 않는다. (롤 르블랑 아님)
개발 속도와 팀 생산성이 떨어진다.
- 프로젝트 초반에는 번개처럼 나가다가 1-2년 만에 굼뱅이처럼 기어가는 팀도 많다.
- 매번 얽히고 설킨 코드를 해독해서 얽히고 설킨 코드를 더한다.
시간이 지나면 쓰레기 더미는 점점 높고 깊어지고 커지고, 불가항력이 된다.
팀 생산성이 떨어진다.
- 나쁜 코드가 쌓일수록 팀 생산성을 떨어지고 0에 근접한다.
- 관리층은 이를 복구하기 위해 인력을 추가로 투입한다.
- 하지만 새 인력은 시스템 설계에 대한 조예가 깊지 않아, 설계 의도에 맞는 변경과 반하는 변경을 구분하지 못한다.
결국 나쁜 코드를 더 많이 양성하고, 생산성을 더더욱 떨어져 0에 수렴한다.
원대한 재설계의 꿈
- 마침내 팀에서는 혐오스러운 코드로는 일을 하지 못하겠다며 관리층에게 재설계를 요구하게 된다.
- 관리층은 자원을 쏟기 싫지만 생산성이 바닥이라는 것을 인정하기에 재설계를 허락한다.
- 처음부터 시작해 진정으로 아룸다운 작품을 창조할 새로운 팀과 현재 시스템을 유지보수할 팀이 나뉘게 된다.
- 새로운 팀은 기존 기능을 따라잡아야 하고, 기존 시스템에 변경사항이 생기면 그것 또한 반영해야 한다.
새 시스템이 기존 시스템을 따라잡을 즘이면
기존 팀원들은 모두 나갔고 새로운 팀원들이 새 시스템을 설계하고자 나선다.
왜? 현재 시스템이 너무 엉망이어서
태도
- 코드가 너무 엉망이라 몇 시간을 예상한 업무가 몇 주로 늘어난 경험이 있는가?
- 한 줄만 고치면 되리라 예상했다가 모듈 수백 개를 건들인 경험이 있는가?
코드가 왜 그렇게 되었을까?
- 일정에 쫒기더라도 대다수 관리자는 좋은 코드를 원한다.
- 그들이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다.
- 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.
나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가 답지 못하다.
원초적 난제
-
근본적인 가치에서 난제에 봉착한다.
- 첫째, 나쁜 코드가 업무 속도를 늦춘다.
- 둘째, 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다.
-
진짜 전문가는 둘째 부분이 틀렸다는 사실을 잘 안다.
- 나쁜 코드를 양산하면 기한을 맞추지 못한다.
- 오히려 엉망진창인 상태로 인해 속도가 늦어지고 결국 기한을 놓친다.
기한을 맞추는 유일한 방법, 빨리가는 유일한 방법은 언젠 코드를 "최대한 깨끗하게 유지하는 습관"이다.
깨끗한 코드라는 예술
: "깨끗한 코드를 어떻게 작성할까?"
-
깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.
청결이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다.
-
열쇠는
코드 감각이다.- 코드 감각이 있어야 좋은 코드와 나쁜 코드를 구분하고,
- 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.
-
코드 감각이 없는 프로그래머는 때로는 나쁜 모듈을 알아보지만, 거기서 끝이다. -
코드 감각이 있는 프로그래머는 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 떠올리고, 최고 방안을 선택한 후 그 방안까지 이동하는 경로를 계획한다.
코드를 읽는 시간 : 코드를 짜는 시간=10 : 1을 훌쩍 넘는다.
- 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.
- 따라서 읽기 쉬운 코드가 중요하다.
- 읽기 시운 코드를 짜면, 기존 코드를 읽는 시간이 줄어들고, 그러면 새 코드를 짜기도 쉬워진다.
: 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
- 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.
- 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.
- 변수 이름 하나를 개선, 조금 긴 함수 하나를 분할, 약간의 중복을 제거, 복잡한 if문 하나를 정리하면 충분하다.
- 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.
- 코드 감각을 확실히 얻는다는 보장도 없다.
단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술/기교/도구를 소개할 뿐이다.
- 좋은 코드도 소개하고, 나쁜 코드도 소개한다.
- 나쁜 코드를 좋은 코드로 바꾸는 방법도 소개한다.
- 다양한 경험적 교훈, 체계, 절차, 기법도 열거한다.
- 무수한 예제도 보여준다.
나머지는 여러분에게 달렸다.