CS Clean Code - 깨끗한 코드

코드가 존재하라

코드는 요구사항을 상세하게 표현하는 언어이다. 코드의 도움 없이는 요구사항을 상세하게 표현할 수 없고, 추상화 할 수 없습니다. 기계가 실행할 수 있도록 상세하게 요구사항을 명시하는 작업이 프로그래밍이고, 그 결과가 바로 코드입니다.

 

나쁜 코드, 르블랑 법칙

80년대 킬러 앱을 구현한 회사가 있었습니다. 제품은 인기를 끌었지만 점차 버그가 많아지며 화가나서 프로그램을 사용하지 더이상 사용하지 않았고 결국 회사가 망했습니다.

 

프로그래머라면 누구나 나쁜 코드를 경험합니다. 그렇다면 어째서 나쁜 코드를 경험하고 나쁜 코드를 짰을까?

• 급해서? 서두르느라?
• 제대로 짤 시간이 없다고 생각해서
• 코드를 다듬느라 시간을 보냈다가 상사한테 욕 먹을까봐
• 지겨워서 빨리 끝내려고
• 다른 업무가 너무 밀려 후딱 해치우고 밀린 업무로 넘어가려고

모두가 경험할 수 있는 매우 일반적인 상황입니다. 자신이 짠 쓰레기 코드를 보면서 나중에 손봐야지 생각하고, 쓰레기 코드가 실행된다고 안도감을 느끼고, 그래도 안돌아가는 프로그램보다 낫다고 위로하고, 나중에 정리해야지 다짐합니다. 하지만 그 나중은 결코 오지 않습니다.

 

르블랑의 법칙, 나중은 절대 돌아오지 않는다.

 

나쁜 코드로 치르는 대가

나쁜 코드는 생산성을 떨어트리고 결국 0에 수렴한다. 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생기고, 매번 얽히고 설킨 코드를 해독해서 얽히고 설킨 코드를 더하게 만듭니다. 시간이 지나면 쓰레기 더미는 점점 높아지고 깊어지고 커지며 결국 청소할 수 없습니다.

 

나쁜 코드를 개선하는 과정

• 생산성이 떨어지면 관리층은 나름 복구를 시도한다.
• 나쁜 코드를 개선할 수 있다는 희망을 품고 새로운 인력을 추가로 투입합니다.
• 하지만 새로운 인력은 기존 시스템 설계에 대한 조예가 깊지 않습니다.
• 설계 의도에 맞는 변경과 설계에 반하는 변경을 구분하지 못합니다.
• 게다가 생산성을 높여야 한다는 극심한 압박을 느낍니다.
• 결국 나쁜 코드를 더 많이 추가합니다.
• 그렇게 때문에 더더욱 생산성을 떨어트립니다.

 

원대한 재설계의 꿈

마침내 재설계를 결정하고 새로운 타이거 팀을 구성하여 두 팀의 경주는 시작합니다. 타이거 팀은 기존 시스템 기능을 모두 제공해야 하며, 그동안 기존 시스템에 가해지는 변경도 모두 따라잡아야 합니다.

때때로 경주는 아주 오랫동안 이어지고 10년이 넘게 걸릴 수도 있습니다. 새 시스템이 기존 시스템을 따라잡을 즈음이면 초창기 타이거 팀원들은 모두 떠났고 새로운 팀원들은 새 시스템을 설계하자고 나선다. 왜? 현재 시스템이 너무 엉망이라서.

 

깨끗한 코드를 만드는 노력이 비용을 절감하는 방법 뿐만 아니라 전문가로서 살아남는 길이라는 사실을 인정하라.

 

태도

좋은 코드가 어째서 순식간에 나쁜 코드로 전락할까?? 우리는 온갖 이유를 들어댄다.

• 원래 설계를 뒤집는 방향으로 요구사항이 변경
• 일정이 촉박해 제대로 할 시간이 없다고 한탄
• 멍청한 관리자와 조급한 고객과 쓸모없는 마케팅 부서

인정하기 어렵지만 잘못은 전적으로 우리 프로그래머에게 있고, 우리가 전문가답지 못했기 때문입니다.

 

관리자와 마케팅은 약속과 공약을 내걸며 우리에게 정보를 구한다. 사용자는 요구사항을 내놓으며 우리에게 현실성을 자문한다. 프로젝트 관리자는 일정을 잡으며 우리에게 도움을 청한다.

우리는 프로젝트를 계획하는 과정에 깊숙히 관여하기 때문에 책임이 있습니다.

---

"아니 잠깐만요 상사가 시키는 대로 하지 않으면 짤린다구요!" 사실 관리자는 겉으로 아닌 듯 해도 대다수 관리자는 진실을 원하고, 그들이 일정과 요구사항을 강하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 좋은 코드를 사수하는 일이 바로 프로그래머의 책임이다.

비유를 하나 들겠다. 환자가 수술 전에 의사에게 시간이 너무 걸리니까 손을 씻지 말라고 요구한다. 하지만 질병과 감염의 위험은 환자보다 의사가 더 잘 알고, 환자 말을 그대로 따르는 것은 전문가답지 못하기 때문에 거절한다.

 

프로그래머도 마찬가지다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

 

원초적 난제

나쁜 코드가 업무 속도를 늦춘다는 사실은 모두가 알고 있지만, 기한을 맞추기 위해 나쁜 코드를 양산할 수밖에 없다고 느낍니다. 하지만 나쁜 코드로는 기한을 맞출 수 없고 오히려 엉망진창인 상태로 속도를 늦춘다. 기한을 맞추는 유일한 방법은 언제나 코드를 깨끗하게 유지하는 습관이다.

 

깨끗한 코드

- 비야네 스트롭스트룹

나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들은 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 깨끗한 코드는 한 가지를 제대로 한다.

• 우아한, 보기에 즐거운 코드 가독성이 좋은 코드.
• 효율적, 자원을 낭비하지 않는 코드.
• 유혹에 빠트리지 않는 코드 (깨진 창문의 법칙, 나쁜 코드는 나쁜 코드를 작성하게 유혹한다.)
• 깨끗한 코드는 한 가지를 제대로, 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다.

- 그래디 부치

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

코드는 추측이 아니라 사실에 기반해야 한다. 깨끗한 코드는 반드시 필요한 내용을 담고, 코드를 읽는 사람에게 단호하다는 인상을 줘야한다.

 

- 데이브 토마스

깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미 있는 이름이 붙는다. 특정 목적을 달성하는 방법은 하나만 제공하낟. 의존성은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드는 문학적으로 표현해야 마땅하다.

데이브 토마스도 가독성을 강조하지만 한 가지 중요한 반전을 더합니다. 깨끗한 코드는 다른 사람이 쉽게 고칠 수 있다고 설명합니다. 또한 테스트 케이스가 없는 코드는 깨끗한 코드가 아니라고 단언합니다.

 

- 마이클 패더스

깨끗한 코드의 특징은 많지만 그 중에서도 모두를 아우르는 특징이 하나 있다. 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 상항을 고려했으므로. 고칠 궁리를 하다보면 언제나 제자로 돌아온다. 그리고 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다.

깨끗한 코드는 주의깊게 작성한 코드다.

 

- 론 제프리스

최근 들어 나는 켄트 벡이 제안한 단순한 코드 규칙으로 규현을 시작한다. 중요한 순으로 나열하자면 간단한 코드는

- 모든 테스트를 통과한다.

- 중복이 없다.

- 시스템 내 모든 설계 아이디어를 표현한다.

- 클래스, 메서드, 함수 등을 최대한 줄인다.

중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기 이 3가지가 깨끗한 코드를 만드는 비결이다.

• 중복, 같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거이다.
• 추상화, 진짜 문제에 신경 쓸 여유가 생긴다. 간단한 찾기 기능이 필요한데 온갖 집합 기능을 구현하느라 사긴과 노력을 낭비할 필요가 없어진다.

 

우리는 저자다

우리는 저자다. 저자는 독자와 소통할 책임이 있다. 코드를 짤 때는 자신이 저자라는 생각과 누군가는 자신의 코드를 보고 판단할 독자가 있다는 사실을 기억해야 한다. 우리는 새 코드를 짜면서 기존의 코드를 끊임없이 읽는다.

 

보이스카우트 규칙

잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다. 시간이 지날 수록 엉망으로 전락하는 코드가 한둘이 아니고, 우리는 적극적으로 코드의 퇴보를 막아야한다. 엄청난 노력과 시간을 투자할 필요가 없다. 변수 이름을 개선하고, 함수를 분할하고, 중복을 제거하고, 복잡한 if문을 정리하자!

캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

 

결론

예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다. 책은 단지 다른 예술가가 사용하는 도구와 기법, 그리고 생각하는 방식을 소개할 뿐이다. 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. '코드 감각'을 확실히 얻는다는 보장도 없다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다.

 

느낀점

1장에는 많은 정보를 주는 것 같으면서 다르게 생각하면 당연한 내용이고 많은 사람들이 의식하고 있거나, 의식하지 않더라도 열심히 지키려고 노력하는 내용들이 많았던 것 같습니다. 너무나 당연하기 때문에 이유 Why?를 생각하지 않았고 오히려 모르게 되는 내용이 됐습니다. 이러한 내용을 다시 알게되는 챕터였습니다.