1. 코드가 존재하리라
코드는 요구사항을 표현하는 언어라는 사실을 알아야하고 요구사항에 더욱 가까운 언어를 만들수도 있고, 요구사항에서 정형 구조를 뽑아내는 도구를 만들 수도 있다. 하지만 어느순간에는 정밀한 표현이 필요하다.
2. 나쁜 코드
좋은 코드의 중요성은 오랫동안 나쁜 코드에 시달려왔다. 출시에 바빠 코드를 마구짜지 말아야 한다. 회사가 망하는 지름길은 나쁜코드이다.
여러가지 바쁘다는 핑계, 상사에 치여서 나쁜코드를 작성하는 경우가 많다. 나중에 돌아와 이것을 다시 손보겠다는 망상을 하는데 나중은 결코 오지 않는다.
3. 나쁜 코드가 치르는 대가
나쁜코드는 개발 속도를 크게 떨어뜨린다. 나쁜 코드가 쌓일수록 팀 생산성을 떨어진다. 그러다가 마침내 0에 근접한다.
3.1. 원대한 재설계의 꿈
팀이 반기를 들고 관리층에게 설계를 요구하는데 생산성이 바닥이라는 사실을 부인하지 않는다. 기존 시스템을 따라잡을 즈음이면 새로운 팀원들이 새 시스템을 설계하자고하며 현재 시스템을 다시 갈아엎기를 요구한다. 깨끗한 코드는 비용을 절감하는 것 뿐만 아니라 전문가로 살아남는 길이라는 사실을 인정하리라.
3.2. 태도
코드가 정말 엉망이라 업무가 배로 들어날 수 있는 상황이 있다. 일정이 촉박해 제대로 할 시간이 없다면서 한탄을 시작하며 전문가 답지 못한 모습을 보일때가 있다.
일정이 촉박하다는것은 전문가 답지못한 행동이다. 프로젝트의 실패는 우리에게도 커다란 책임이 있고 특히 나쁜 코드가 초래하는 실패에는 더더욱 책임감이 크다.
나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가 답지 못하다.
3.3. 원초적 난제
누구나 나쁜코드가 업무속도를 늦춘다는 사실을 익히 안다. 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산하면 기한을 맞추지못한다. 기한을 맞추는 유일한 방법은 언제나 코드를 깨끗하게 유지하는 습관이다
3.4. 깨끗한 코드라는 예술?
나쁜 코드가 심각한 장애물이라는 사실을 납득했다고 가정하면 깨끗한 코드를 어떻게 작성할까?
깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷하다. 깨끗한 코드와 나쁜코드를 구분 할 줄 안다고 깨끗한 코드를 작성할줄 아는 뜻은 아니다.
열쇠는 '코드 감각’이다. '코드감각’이 있으면 좋은 코드와 나쁜 코드를 구분한다. 그뿐만 아니라, 절제와 규울을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.
깨끗한 코드를 작성하는 프로그래머는 빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 같다.
3.5. 깨끗한 코드란?
비야네 스트롭스트롭 Bjame stroustrup(c++ 창시자)
우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 깨끗한 코드는 한 가지를 제대로 한다.
비야네는 ‘우아한’ 이라는 단어를 사용한다. 깨끗한 코드는 보는 사람들에게 즐거움을 선사해야 한다는 뜻이다.
CPU자원을 낭비하는 코드도 우아하지 못하며 보기에도 즐겁지 못하다고 말한다. 나쁜 코드는 나쁜 코드를 유혹한다. 흔히 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다는 뜻이다.
비야네는 철저한 오류 처리도 언급한다. 세세한 사항까지 꼼꼼하게 신경 쓰라는 말이다. 프로그래머들이 대충 넘어가는 부분 중 하나가 오류 처리이다.
메모리 누수, 경쟁 상태, 일관성 없는 명명법이 또 다른 예다. 한마디로 요약하면 깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하는 코드다.
비야네는 마지막으로 깨끗한 코드란 한 가지를 잘 한다고 단언한다. 수많은 소프트웨어 설계 원칙이 이 간단한 교훈 하나로 귀결된다는 사실은 우연이 아니다.
나쁜 코드는 너무 많은 일을 하려 애쓰다가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한 가지에 '집중’한다.
각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다.
그레디 부치 Grady Booch
깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않습니다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
큰 데이브 토마스 Dave Thomas
깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미있는 이름이 붙는다. 특정 목적을 달성하는 방법은 여러가지가 아니라 하나만 제공한다.
의존성은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드는 문학적으로 표현해야 마땅하다.
실제로 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다.
마이클 페더스 Michael Feathers
깨끗한 코드의 특징은 많지만 그중에서도 모두를 아우르는 특징이 하나 있다. 깨끗한 코드는 언제나 누군가 주의 깊게 짯다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈곳이 없다. 작성자가 이미 모든 사항을 고려했으므로 고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다.
론 제프리스 Ron Jeffries
론은 스트레티직 에어 커맨드 사에서 포트란으로 프로그래밍을 시작한 이래 거의 모든 플랫폼에서 거의 모든 언어로 코드를 구현해왔다. 그러므로 그의 의견은 신중하게 고려할 가치가 있다.
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
중복에 집중한다. 같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다.
나는 문제의 아이디어를 찾아내 좀 더 명확하게 표현하려 애쓴다.
중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기, 내게는 이 세가지가 깨긋한 코드를 만드는 비결이다.
중복을 피하라, 한가지 기능만 수행하라, 제대로 표현하라, 작게 추상화하라
워드 커닝햄(Ward Cunningham)
위키 창시자, 피트 창시자, 익스트림 프로그래밍 공동 창시자, 디자인 패턴을 뒤에서 움직이는 전문가, 스몰토크와 객체지향의 정신적 지도자, 코드를 사랑하는 프로그래머들의 대부분 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.
깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다고 위드는 말한다. 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드이다.
코드가 그 문제를 풀기위한 언어처럼 보인다면 아름다운 코드라 말한다. 언어를 단순하게 보이도록 만드는 책임이 우리에게 있다는 뜻과 같다.
언어를 단순하게 보이도록 만드는 열쇠는 프로그래머이다.
4. 우리들의 생각
코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.
비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 비록 읽기 쉬운 코드를 짜기 쉽지는 않더라도 말이다. 하지만 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다.
주변 코드를 읽지 않으면 새 코드를 짜지 못한다. 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다. 주변 코드가 어려우면 새 코드를 짜기도 어렵다. 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면 읽기 쉽게 만들면 된다.
5. 보이스카우트 규칙
잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다. 시간이 지나면서 엉망으로 전락하는 코드가 한둘이 아니다. 그러므로 우리는 적극적으로 코드의 퇴보를 막아야한다.
체크아웃할때 보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수를 분할하고 약간의 중복을 제거하고 복잡한 if문 하나를 정리하면 충분하다.
시간이 지날수록 코드가 좋아지는 프로젝트에서 작업을 한다고 상상해보면 지속적인 개선이야 말로 전문가 정신의 본질이다.
6. 프리퀄과 원칙
2002에 출판한 PPP의 프리퀄의 책은 객체 지향 설계의 원칙을 설명하고 전문 개발자들이 사용하는 실무 기법을 소개한다. PPP를 읽지 않았다면 PPP에서 표명한 의견을 여기서 코드로 재 발견하리라.
7. 결론
예술에 대한 책을 읽는다고 예술가가 된다는 보장이 없다. 책은 단지 다른 예술가가 사용하는 도구와 기법, 그리고 생각하는 방식을 소개할 뿐이다. 예술에 대한 책과 마찬가지로 이 책 역시 세세한 정보로 가득하다. 코드도 많다. 좋은 코드도 소개하고 나쁜 코드도 소개한다.
나쁜 코드를 좋은 코드로 바꾸는 방법도 소개한다. 다양한 경험적 교훈과 체계와 절차와 기법도 열거한다.
연습해 연습!