Clean Code Series 1 - 깨끗한 코드

본 글은 로버트 C.마틴의 클린 코드 책을 읽고 작성한 글입니다. 간단한 요약글과 작성자의 생각을 담았습니다.

1. 코드가 존재하리라

   • 자동으로 코드를 생성하는 시대가 다가오는 시대에 코드의 종말이 코앞에 닥쳤다고 주장하는 사람들이 있지만 이는 틀린 말이다.

     • 코드는 요구사항을 상세히 표한하는 수단이다.
     • 추상화 또한 불가하며, 정확히 명시하는 수밖에 없다.

   • 요구사항을 모호하게 줘도 우리 의도를 정확히 꿰뚫어 프로그램을 완벽하게 실행하는 기계가 나오리라 기대하지만 이는 불가능하다.

     • 사람 조차도 고객의 막연한 감정만 갖고는 성공적인 시스템을 구현하지 못한다.
     • 요구사항에서 정형 구조를 뽑아내는 도구를 만들더라도 어느 순간에는 정밀한 표현이 필요하다. 이 필요성을 없앨 방법은 없으므로 코드는 항상 존재하리라.

2. 나쁜 코드

   • 코드가 나빠지는 이유에는 여러가지 이유가 있을텐데 대부분이 아마 시간상 급해서 일 것이다. 코드가 나빠져도 나중에 시간이 될 때 정리하리라 다짐할 수 있다. 하지만 나중은 결코 오지 않는다.

3. 나쁜 코드로 치르는 대가

   • 나쁜 코드는 개발 속도를 크게 떨어뜨린다.
   • 나쁜 코드가 쌓일수록 팀 생산성은 떨어지다 마침내 0에 근접한다.

- 생산성이 낮아져 새로운 인력을 투입해 재설계를 하더라도 기존의 설계를 따라잡아야 하기에 시간이 오래 소요되며, 이런 환경에서 만들어진 프로그램은 기존의 프로그램은 대체할 수 없을것이다.
- 일정과 요구사항들 속에서 좋은 코드를 사수하는 일은 프로그래머의 책임이다.
- **기한을 맞추는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.**

4. 깨끗한 코드

   • 깨끗한 코드를 작성하려면 ‘청결’이라는 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다.

   • 깨끗한 코드의 정의는 불분명하므로 유명하고 노련한 프로그래머들의 의견을 물었다.

     1. 비야네 스트롭스트룹

        • 보기에 즐거운 코드다.
        • 나쁜 코드는 나쁜 코드를 유혹한다.
        • 한 가지에 ‘집중’한다.

     2. 그래디 부치

        • 잘 쓴 문장처럼 읽혀야 한다. → 가독성
        • 코드는 추측이 아니라 사실에 기반해야 한다.

     3. 데이브 토마스

        • 다른 사람이 고치기 쉬워야 한다.
        • 테스트가 가능한 코드여야 한다. (TDD)
        • 문학적이어야 한다. (가독성)

     4. 마이클 페더스

        • 주의 깊게 시간을 들여 깔끔하고 단정하게 정리한 코드여야 한다.

     5. 론 제프리스

        • 중복을 피하라.
        • 한 기능만 수행한다.
        • 제대로 표현하라.
        • 작게 추상화 하라.

     6. 워드 커닝햄

        • 읽으면서 놀랄 일이 없이 자명해야 한다.
   • 우리는 저자다
   • Javadoc에서 @Author 필드는 저자를 소개한다. 저자에겐 독자가 있고 독자와 잘 소통할 책임도 있다. 코드를 짤 때에는 자신이 저자라는 사실을 기억해야 한다.