목차
서론)
엊그제 내가 작업한 결과물을 정기 배포에 올리기 전에 파트장님께 테스트 받는 시간이 있었다.
분명 다른 분들께 테스트를 다 마치기도 했고, 간단한 검색기능이어서 자신있게 테스트를 받았는데
설정을 다르게 하니까 갑자기 오류가 나와서 식은땀이 났다.
만약에 정기배포 후에 실제 운영 중에 오류가 나서 컴플레인이 들어왔다면? 생각만해도 아찔했다.
내가 작성한 코드는 프론트앤드의 필터 함수 단 한 줄이었는데, 특정 환경에서 빈 데이터값이 들어올 수 있어서
null처리를 안해서 발생했던 오류였다. 당연히 존재할 수 밖에 없는 값이라고 생각했었는데 충격이었다.
(다른 값은 null체크를 해놔서 그래서 더욱 신경도 못쓰고 있었다.)
그 뒤로 모두 확인해보자는 마음으로, 다른 코드를 깃에 올리기 전에 개발기 환경에서
모든 설정을 다 눌러봤더니 예상치 못했던 새로운 오류들을 잡아낼 수 있었다.
앞으로 코드 한 줄 치더라도 모든 상황을 고려해서 작성해야한다는 경각심이 들었던 하루였다..
1. 코드가 존재하리라
궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다.
요구사항에서 코드를 자동으로 생성하는 시대가 온다고 하더라도,
어느 수준에 이르면 코드의 도움없이 요구사항을 상세하게 표현하기란 불가능하다.
그렇기때문에 코드는 항상 존재하리라.
2. 나쁜 코드
Killer app 하나로 대박난 회사가 머지 않아 망한 일이 있었다. 그 원인은 나쁜 코드였다.
그들은 출시에 바빠 코드를 마구 짰다. 기능을 추가할 수록 코드는 엉망이 되어갔고,
결국은 감당이 불가능한 수준에 이르렀다.
우리는 모두 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다.
몰론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.
3. 나쁜 코드로 치르는 대가
나쁜 코드는 개발 속도를 크게 떨어뜨린다.
코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다.
매번 얽히고 설킨 코드를 '해독'헤서 얽히고 설킨 코드를 더한다.
시간이 지나면서 쓰레기 더미는 점점 높아지고 깊어지고 커진다. 청소할 방법이 없다.
불가항력이다.
나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 도달한다.
(매커니즘)
➡️ 나쁜 코드가 쌓임
➡️ 생산성 떨어짐
➡️ 관리층은 복구를 위해 새로운 인력을 추가
➡️ 하지만 새인력은 해당 시스템 설계에 대한 조예가 깊지 않아 설계 의도에 맞는 변경을 구분하지 못한다.
게다가 새인력은 생산성을 높여야 한다는 극심한 압박에 시달리게되고, 결국 나쁜 코드를 더 많이 생산하게 됨
➡️ 결국 생산성은 0에 수렴
3-1. 원대한 재설계의 꿈
➡️ 마침내 팀이 반기를 들어 원대한 재설계를 착수한다.
➡️ 처음부터 시작해 아름다운 작품을 창조할 새로운 타이거 팀이 구성된다.
가장 유능하고 똑똑한 사람들만 타이거 팀으로 차출된다.
반대로, 나머지 팀원 들은 계속해서 현재 시스템을 유지보수한다.
➡️ 두 팀은 오래 동안 경쟁한다.
타이거 팀은 기존 시스템의 기능을 모두 제공하면서도 그동안의 변경도 모두 따라잡아야한다.
➡️ 타이거 팀이 기존의 프로젝트를 따라잡을 때 즈음, 타이거 팀의 초기멤버들은 대부분 새멤버로 교체되어있다.
➡️ 그리고 새 멤버들은 다시 새시스템을 설계하자고 나선다. 왜? 현재 시스템이 너무 엉망이라서.😅
방금 한 이야기를 일부라도 겪었다면 시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라
전문가로서 살아남는 길이라는 사실을 인정하리라.
3-2. 태도
프로젝트 실패는 프로그래머에게도 커다란 책임이 있다.
특히 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다.
일정이 쫒기더라도 대다수 관리자는 좋은 코드를 원한다.
좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.비유를 하나 들겠다. 자신이 의사라 가정하다. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까. 확실히 환자는 상사다. 하지만 의사는 단호하게 거부한다. 왜? 질병과 감염의 위험은 환자보다 의사가 더 잘아니까.환자 말을 그대로 따르는 행동은 전문가 답지 못하니까.
프로그래머도 마찬가지다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
3-3. 원초적 난제
나쁜 코드가 업무 속도를 늦춘다 <-> 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다.=> 기한을 맞추는 유일한 방법은 언제나 코드를 깨끗하게 유지하는 습관이다.
3-4. 깨끗한 코드라는 예술
깨끗한 코드를 어떻게 작성할까?
깨끗한 코드를 작성하려면 '청결'이라는 힘겹게 습득한 감각(= 코드 감각)을 활용해 자잘한 기법들을 적용하는
절제와 규율이 필요하다.
이 코드 감각이 있다면 좋은 코드와 나쁜 코드를 구별할 뿐만이 아니라 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.
3-5. 깨끗한 코드란?
아래는 여러 프로그래머의 의견들
1) Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language
- 코드는 즐겁게 읽혀야 한다.
- 효율적인 코드라야 한다. 이는 성능적 측면 뿐만 아니라 나쁜 코드는 난장판을 더 키우기 때문이다.(깨진 유리창 이론) 1
- 에러 핸들링, 메모리 누수, 경쟁상태, 일관되지 않은 네이밍 등 디테일을 신경쓰라.
- 나쁜 코드는 여러가지 일을 하려고 한다. 나쁜 코드는 애매한 의도와 모호한 목적을 포함한다. 클린코드는 한 가지에 집중한다. 클린코드는 한 가지 일을 잘 한다.
- 클린코드는 하나의 잘 쓰여진 문장처럼 읽혀야 한다. 소설의 기승전결처럼 문제를 제시하고 명쾌한 해답을 제시해야 한다.
- 명백한 추상: 코드는 추측 대신 실제를 중시, 필요한 것만 포함하며 독자로 하여금 결단을 내렸다고 생각하게 해야 한다.
- 다른 이가 수정하기 쉬워야 한다.
- 테스트 케이스가 있는 코드여야한다.
- 의존성이 최소여야한다.
- 주의 깊게 짠 코드 = 작성자가 이미 모든 사항을 고려해서 고치려고 해도 딱히 손 댈 곳이 없는 코드
- 중복 줄이기
- 표현력 높이기- 의미있는 이름 짓기, 하나의 객체는 하나의 기능을 하도록 나누기
- 초반부터 간단한 추상화를 고려하기
- 짐작하는 기능을 그대로 수행하는 코드를 작성하기 (=명백하고 단순하게 동작하는 코드)
4. 우리들 생각
필자는 본 책의 내용(의견)을 절대적인 것으로써 전달할 것이다. 우리에겐, 적어도 우리 커리어의 현시점에서는, 그게 절대적이기 때문이다. 이것은 클린코드에 대한 우리의 학파이다.이 책에 나오는 많은 내용들은 논란거리이다. 당신도 모든 내용을 수긍하지도 않을 거니와 어떤 내용은 심하게 부정할 지도 모른다. 그건 괜찮다. 결정은 당신이 해야 한다. 하지만, 이 책에서 추천하는 내용은 우리가 긴 시간 힘들게 고민한 내용이다. 이 내용은 우리가 수십년간의 경험과 시행착오의 반복으로 얻은 것이다. 당신이 동의하던 아니던 당신이 우리의 관점을 이해하고 존중해 주길 바란다.
실제로 읽기와 쓰기에 들이는 시간은 대략 10:1 정도이다. 새 코드를 작성하기 위해서는 옛 코드들을 읽어야 하기 때문이다.
그러므로, 빨리 가고 싶다면, 쉽게 코드를 작성하고 싶다면, "읽기 쉽게 작성하라".
시간이 지날 수록 더러워지는 코드를 본 적이 있을 것이다. 미국 보이스카우트에는 이러한 상황에 사용할 수 있는 단순한 규칙이 하나 있다.
"캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라"
우리가 본 코드를 그 순간보다 조금만 더 개선한다면 코드는 더러워질 수가 없다. 거창하게 생각할 필요는 없다. 변수의 명명, 너무 긴 코드의 분할, 작은 중복의 제거, 복합 if문 하나의 개선 정도만 해 보라.
지속적인 개선이야말로 전문가 정신의 본질이 아니던가?
여러모로 봐서 이 책은 내가 지난 2002년에 쓴 책 Agile Software Development: Principles, Patterns, and Practices (PPP) 의 프리퀄이다. SRP, OCP, DIP등 PPP에서 설명하는 객체지향 디자인의 원칙과 실제에 대한 설명이 종종 나오기 때문에 같이 읽어보면 좋을 것이다.
이 책은 당신을 예술가로 만들어줄 수는 없다. 다만, 다른 아티스트가 사용했던 툴, 기술, 사고방식 등을 전달해줄 수 있을 뿐이다.
예술 교본과 마찬가지로 이 책은 당신에게 많은 (좋은/나쁜)코드를 보여줄 것이다. 나쁜 코드들이 좋은 코드로 바뀌는 것도 볼 것이다. 많은 휴리스틱, 규율, 태크닉을 볼 것이다. 예제, 그리고 더 많은 예제들을 볼 것이다. 그 다음은 당신의 몫이다.
공연에 지각한 콘서트 바이올리니스트에 대한 옛 농담을 기억하는가? 그는 코너에 있던 한 노인을 불러 세우고는 카네기 홀 까지의 길을 물었다. 노인은 그와 그의 바이올린을 쳐다보고는 말했다. "연습해 젊은이. 연습!"
참조