나쁜 코드

  • Killer App으로 대박난 회사가 머지 않아 실패했다. 원인은 나쁜 코드였다.
  • 일정을 맞추기 위해 나쁜 코드들을 방치하고 '나중에 고쳐야지’라는 생각이었다. 물론, 다들 이런 생각을 할 것이고 그런 경험이 있을 것이다. 하지만, 나중은 절대 오지 않는다. - 르블랑의 법칙

난장판을 품는 데에 드는 비용

  • 초기에는 빠른 속도로 진행되던 프로젝트가 1~2년 만에 달팽이처럼 느린 페이스로 진행되는 것을 볼 수 있다.
    • 나쁜 코드로 짠 프로그램에 가해지는 변경사항은 어느것 하나 사소하지 않다.
  • 나쁜 코드가 쌓일수록 그 팀의 생산성을 떨어지고 이윽고 0에 수렴한다.
    • 관리팀은 인력을 추가한다.
    • 하지만, 새 팀원들은 구조를 이해하지 못한다.
    • 팀은 '새 인력을 투입했으므로 생산성이 늘겠지’라는 압박을 받는다.
    • 결과, 나쁜 코드는 더 쌓인다.

장대한 재디자인

  • 팀은 봉기하고 재디자인을 요구한다.
  • 달갑지 않지만 관리팀 또한 개발팀의 생산성이 바닥임을 알고 있으므로 허가한다.
  • 새로운 타이거 팀이 만들어지고, 기존 프로덕트의 스펙 + 새로운 기능을 맡게 된다. 기존의 팀원들은 기존 코드를 유지보수하게 된다.
  • 두 팀은 오랫 동안 경쟁하게 된다.
  • 타이거 팀인 기존의 프로젝트를 거의 따라잡을 즈음, 타이거 팀의 초기 멤버들은 대부분 새 멤버들로 교체되어 있다.
  • 그리고 그들은 다시 재디자인을 요구한다…

깨끗한 코드는 효율적인 뿐 아니라 생존과 직결되는 문제다.

마음가짐

  • 1시간이면 될 변경을 1주일이 넘도록 보고 있다던지, 한줄만 바꾸면 될 문제를 가지고 수백개의 모듈을 건드린다던지 하는 증상은 흔하다.
    • 왜 좋은 코드는 그렇게도 빠르게 나쁜 코드로 바뀌는 것일까?
  • 초기와 다른 스펙, 스케줄, 멍청한 매니저, 참을성 없는 고객, 쓸데없는 마케팅 인간들을 비난할 지도 모른다. 하지만 그건 우리 잘못이다.
    • 대부분 매니저들은 우리 생각보다 더 진실을 원하고 있다.
    • 그들 또한 좋은 코드를 원한다. 그와 동시에 스케줄 또한 지키고 싶어 한다.
    • 그와 마찬가지로, 좋은 코드를 지키는 것 또한 우리의 몫이다.

태고의 난제

  • 더러운 코드는 생산성을 저하시킨다. 그와 동시에 개발자들은 기한을 맞추기 위해 더러운 코드를 짠다. 하지만, 더러운 코드를 만들어서는 절대 기한을 맞추지 못한다.
  • 빨리 가기 위한 단 하나의 방법은 "최대한 깨끗한 코드를 항상 유지하는 것"이다.

클린 코드의 미학이란?

  • 클린코드란 예술작품과 같다. 어떤 코드가 클린코드인지 아닌지를 구분하는 것과 클린코드를 쓸 수 있는지는 다른 문제이다.
  • 클린코드를 작성하려면 피를 토해가며 얻은 클린코드에 대한 감각을 사용해 무수하게 많은 작은 기술들을 적용해야 한다.

깨끗한 코드란?

비야네 스트롭스트룹

  • 깨끗한 코드는 보기에 즐거운 코드다.
  • 효율적인 코드여야 한다. 성능적인 측면 뿐 아니라 나쁜 코드는 나쁜 코드를 더 크게 만든다.
  • 깨진 창문 이론 : 창문이 깨진 건물은 누구도 신경 쓰지 않는다. 사람들은 관심을 끊고, 창문이 더 깨져도 상관하지 않는다. 마침내 자발적으로 창문을 깨고, 방치하며, 쇠퇴하는 과정이 시작된다.
  • 메모리 누수, 경쟁 상태, 일관성 없는 네이밍 등의 세세한 사항을 신경 써야 한다.
  • 깨끗한 코드는 한 가지에 집중한다. 각 함수와 클래스, 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다.

그래디 부치

  • 깨끗한 코드는 단순하고 직접적이다. 잘 쓴 문장처럼 읽힌다.
  • 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내고 긴장을 쌓으며 클라이맥스에 이르렀다가 명백한 해법을 제시하며 긴장과 문제를 풀어야 한다.
  • 명쾌한 추상화 : 코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다. 이를 통해 프로그래머가 단호하다는 느낌을 받게 해야 한다.

Big 데이브 토마스

  • 가독성이 중요하며, 다른 사람이 고치기 쉬워야 한다.
  • 테스트 케이스가 없으면 깨끗한 코드가 아니다. 테스트 케이스가 있어야 한다.
  • 코드는 작을 수록(간결할수록) 좋다.(Smaller is better)
  • 코드는 문학적이어야 한다. 즉, 인간이 읽기 좋은 코드여야 한다.

마이클 페더스

  • 주의 깊게 코드를 작성하라.

론 제프리스

  • 중복을 없애야 한다.
  • 클래스나 메소드는 한 가지 일만 수행해야 한다.
  • 초반부터 간단한 추상화를 고려하여 개발을 빠르게 진행하라.
  • 메소드나 변수의 이름 등으로 코드가 하는 일을 명시하라.

워드 커닝햄

  • 읽고 고개를 끄덕이고 다음 주제로 넘어갈 수 있는 코드를 작성하라.
  • 코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다.
  • 언어를 탓하지 말자. 코드(언어)를 단순하게 보이도록 만드는 것은 프로그래머의 역할이다.

우리는 작가들이다
기존 프로젝트에 새로운 코드를 작성할 때, 코드를 읽는 시간 : 코드를 짜는 시간 비율은 10 : 1을 훌쩍 넘는다. 새 코드를 짜면서 끊임없이 기존 코드를 읽는다.

비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 기존 코드를 일겅야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다. 쉽게 짜려면 읽기 쉽게 만들어라.

보이스카우트 규칙

  • 잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.
  • 적극적으로 코드의 퇴보를 막아야 한다.
  • "캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라."
  • 우리가 본 코드를 그 순간보다 조금만 개선한다면 코드는 더러워질 수가 없다. 변수 이름을 하나 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.

Reference