[클린 코드] Clean Code 1장. 깨끗한 코드

🔥해당 글은 프로젝트 팀원과 함께 프로젝트 퀄리티 및 더 나은 개발자가 되기 위하여 북 스터디를 진행하였습니다.

• 클린 코드를 읽고 나면 다음과 같은 사실을 배우게 될 것입니다.
  • 좋은 코드와 나쁜 코드를 구분하는 능력을 갖춘다.
  • 좋은 코드를 작성하는 방법을 익힌다.
  • 나쁜 코드를 좋은 코드로 바꾸는 실력도 쌓는다.

코드가 존재하리라

실제로도 코드의 종말이 코앞에 닥쳤다고 주장하는 사람이 없지 않습니다.
코드를 자동으로 생성하는 시대가 다가온다고 하네요..?  
그때가 되면 프로그래머는 필요가 없습니다. 영업 직원이 명세에서 프로그램을 자동으로 생성하면 되니까요..

하지만..! 앞으로 코드가 사라질 가망은 전혀 없습니다. 왜냐하면 코드는 요구사항을 상세히 표현하는 수단이기 때문입니다.

어느 수준에 이르면 코드의 도움 없이 요구사항을 상세히 표현하기란 불가능합니다. 또한, 추상화도 불가능합니다.

고도로 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세 역시 코드이므로 결코 코드는 사라지지 않는다.

궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심해야 합니다.

나쁜 코드

• 회사가 망한 원인은 바로 나쁜 코드 탓
  • 80년대 후반 킬러 앱 하나를 구현한 회사는 나쁜 코드로 인한 버그로 인해 망했다.
  • 버그는 다음 버전에도 그대로 남아있고, 프로그램 시동 시간이 길어지고 죽는 횟수도 늘었다.
  • 원인은 출시에 바빠 코드를 마구 짜서, 기능을 추가할수록 코드가 엉망이 되었기 때문이다.
• 르블랑의 법칙 - 나중은 결코 오지 않는다.
  • 우리 모두는 자신이 짠 쓰레기 코드를 보며 나중에 손보겠다고 생각한 경험이 있다. 하지만 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

• 나쁜 코드는 개발 속도를 크게 떨어트린다.
  
  • 나쁜 코드는 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다.
  • 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 마침내 0에 접근한다.
  • 생산성을 증가시키기 위해 투입한 신규 인력은 시스템 설계 의도를 분명하게 알지 못해 결국 더 많은 나쁜 코드를 양산한다.

클린코드

원대한 재설계의 꿈

• 더 이상 혐오스러운 코드로는 더 이상 일하지 못하겠다고 팀이 반기를 든다.
  • 관리층에게 재설계를 요구 / 관리층은 재설계에 자원을 쏟아붓기 싫지만, 생산성이 바닥이라는 사실은 인지하고 있다.
  • 새로운 팀이 구성! 다들 새로운 팀에 합류하고 싶어 한다.

다들 처음부터 시작하기 때문에 진정으로 아름다운 코드가 구현될 거라고 생각합니다..

"새로운 팀에는 유능하고 똑똑한 사람들만 차출되고, 나머지는 계속 현재 시스템에 유지보수하게 됩니다.. ㅠ ㅠ"

• 새로운 팀 VS 기존 팀
  • 새로운 팀은 기존 시스템 기능을 모두 제공하는 새 시스템을 구현, 기존 시스템에 가해지는 변경도 모두 리팩터링해야 합니다.
  • 새 시스템이 기존 시스템 기능을 100% 제공하지 않는 한 관리층은 기존 시스템을 대체하지 않습니다..

이 대결 구도는 오랫동안 이어질 것입니다..

새 시스템이 기존 시스템을 거의 구현할 때 즈음이면 초창기의 새로운 팀의 팀원들은 모두 팀을 떠나고..

새로운 팀원들이 현재 시스템이 너무 엉망이기 때문에.. 또 새 시스템을 설계하자고 나설 겁니다..

위 내용에 대해 일부라도 겪었다면.. 시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하고,
전문가로서 살아남는 길이라는 사실을 인정해야 합니다..!

태도

일정에 쫓기더라도 대다수 관리자는 좋은 코드를 원합니다.
그들이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문입니다.
좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임입니다..!
프로그래머도 마찬가지로, 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따르는 행동은 전문가답지 못합니다.

원초적 난제

• 프로그래머는 근본적인 가치에서 난제에 봉착한다.
  • 프로그래머라면 누구나 나쁜 코드가 업무 속도를 늦춘다는 사실을 익히 안다.
• 그럼에도 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다.
  
  • 나쁜 코드를 양산하면 기한을 맞추지 못한다.
  • 오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다.
  • 기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드라는 예술?

• 깨끗한 코드를 어떻게 작성할까? [깨끗한 코드가 무엇인지 모르면 깨끗한 코드를 만들려고 애써봤자 소용없다]
  • 깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷 → 그림을 보면 엉망인지 알 수 있다.
  • 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 아는 건 아니다.
• 타고난 코드 감각
  • 코드 감각의 유무로 좋은 코드와 나쁜 코드를 구분
  • 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악할 수 있음

깨끗한 코드를 작성하는 프로그래머는 빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 같다.

깨끗한 코드란?

다음은 개발 분야에서 유명하고 노련한 프로그래머들의 의견이다.

비야네 스트롭스트룹 (C++ 창시자)

• 우아하고 효율적인 코드
  • 논리가 간단해야 버그가 숨어들지 못하고, 의존성을 최대한 줄여야 유지보수가 쉬워진다.
  • 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 
  • '우아한' 단어의 의미와 같이 깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다.
  • '효율'이란 단순히 속도뿐 아니라, CPU 자원을 낭비하는 코드도 좋은 코드가 아니다.
  • 나쁜 코드는 나쁜 코드를 '유혹'한다. 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다는 뜻이다.
• 철저한 오류 처리
  • 오류는 세세한 사항까지 처리해야 한다.
• 집중
  • 나쁜 코드는 너무 많은 일을 하려 해서 의도가 뒤섞이고 목적이 흐려진다. 반면, 깨끗한 코드는 한 가지에 '집중'한다.

그래디 부치

• 깨끗한 코드
  • 단순하고 직접적이며, 잘 쓴 문장처럼 읽힌다.
  • 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
• 명쾌한 추상화
  • 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야 한다.
  • 코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다.

큰 데이브 토마스

• 가독성
  • 깨끗한 코드란 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. (실제로 읽기 쉬운 코드와 고치기 쉬운 코드는 다르다.)
  • 깨끗한 코드에는 의미 있는 이름이 붙는다.
  • 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드를 문학적으로 표현해야 마땅하다.
• 테스트 케이스
  • 아무리 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 않다.

마이클 페더스

• 언제나 누군가 주의 깊게 짰다는 느낌은 준다. 고치려고 해도 손댈 곳이 없다.
• 깨끗한 코드는 주의 깊게 작성한 코드다.
• 세세한 사항까지 꼼꼼하게 신경 쓴 코드다.

론 제프리스

• 모든 테스트를 통과한다.
• 중복이 없다.
  • 같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다.
  • 메서드가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러 개로 나눈다.
• 시스템 내 모든 설계 아이디어를 표현한다.
• 클래스, 메서드, 함수 등을 최대한 줄인다.

워드 커닝햄

• 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드다.
• 코드가 그 문제를 푸기 위한 언어처럼 보인다면 아름다운 코드다.

•  

우리는 저자다

• 코드를 작성하는 사람은 우리고, 우리의 코드를 볼 독자가 있다는 사실을 기억해야 한다.
• 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실을 짜기도 쉬워진다.
• 급할수록 쉽게 구현하려면, 읽기 쉽게 구현하면 된다.

보이스카우트 규칙

• 미국 보이스카우트
  • 체크아웃할 때보다 더 깨끗한 코드를 체크인한다면, 코드는 절대 나빠지지 않는다.
  • 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.
  • 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분
  • 시간이 지날수록 코드가 좋아지는 프로젝트에서 작업!
    • 지속적인 개선이야말로 전문가 정신의 본질!

결론

책은 단지 다른 예술가가 사용하는 도구와 기법, 그리고 생각하는 방식을 소개할 뿐이다..
이 책을 읽는다고 뛰어난 프로그래머가 되는 건 아닙니다 ^^.. '코드 감각'을 확실히 얻는다는 보장도 없다.
좋은 코대도 소개, 나쁜 코드도 소개, 나쁜 코드를 좋은 코드로 바꾸는 방법을 소개합니다.
나머지는 이 책을 읽는 사람들에게 달려있습니다.