Clean Code - 클린 코드, 애자일 소프트웨어 장인 정신

전공분야(?) 관련 책들을 읽어본지 너무 오래 된것 같아서, 주변에서 흔하게 추천(?) 해주는 책을 읽어보았다.

읽어보면 참~ 맞는 말인데, 이렇게 하지 않아서.. 내가 이 모양이구나...ㅜㅜ.. 라는 자기반성을 하게 된 것 같다.

(반성은 하지만... 행동도 바뀌게 될지는 모르겠다 ㅋㅋㅋ)

책을 다시 읽을 것 같지는 않지만, 적어두면 나중에 볼 확률이 조금 더 높지 않을까.. 해서

책의 내용 중, 기억에 남았던 부분을 적어보았다.

1. 깨끗한 코드

   개발시 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다.

   새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다.

   비록 읽기 쉬운 코드를 짜기가 쉽지는 않더라도 말이다.

   하지만 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다.

   이 논리에서 빠져나갈 방법은 없다. 주변 코드를 읽지 않으면 새 코드를 짜지 못한다.

   주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다. 주변 코드를 읽기가 어려우면 새 코드를 짜기도 어렵다.

   그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다.

5. 형식맞추기

  - 신문 기사처럼 작성하라

  아주 좋은 신문 기사를 떠올려보라. 독자는 위에서 아래로 기사를 읽는다.

  최상단에 기사를 몇 마디로 요약하는 표제를 보고서 기사를 읽을지 말지 결정한다. 첫 문단은 전체 기사 내용을 요약한다.

  세세한 사실은 숨기고 커다란 그림을 보여준다. 쭉 읽으며 내려가면 세세한 사실이 조금식 드러난다.

  날짜, 이름, 발언, 주장, 기타 세부사항이 나온다.

  소스 파일도 신문 기사와 비슷하게 작성한다. 이름은 간단하면서도 설명이 가능하게 짓는다.

  이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경 써서 짓는다.

  소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다.

  마지막에는 가장 저차원 함수와 세부 내역이 나온다.

  신문은 다양한 기사로 이뤄진다. 대다수 기사가 아주 짧다. 어떤 기사는 조금길다. 한 면을 채우는 기사는 거의 없다.

  신문이 읽을 만한 이유는 여기에 있다. 신문이 사실, 날짜, 이름 등을 무작위로 뒤섞은 긴 기사 하나만 싣는다면 아무도 읽지 않으리라.

6. 객체와 자료구조

  - (자료 구조를 사용하는) 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.

    반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.

  - 절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다.

    객체 지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.

  다시 말해, 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며,

                절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다!

  복잡한 시스템을 짜다 보면 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우가 생긴다.

     -> 이때는 클래스와 객체 지향 기법이 가장 적합하다.

  반면, 새로운 자료 타입이 아니라 새로운 함수가 필요한 경우도 생긴다.

     -> 이때는 절차적인 코드와 자료 구조가 좀 더 적합하다.

    

  분별 있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다. 

  때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다.

8. 경계

  외부 코드를 익히기는 어렵다. 외부 코드를 통합하기도 어렵다. 두 가지를 동시에 하기는 두 배나 어렵다.

  다르게 접근하면 어떨까?

  곧바로 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히면 어떨가?

  이를 학습 테스트라 부른다.

9. 단위 테스트

  첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

  둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

  셋째 법칙 : 현재 실패한느 테스트를 통과할 정도로만 실제 코드를 작성한다.

  테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 이류 시민이 아니다.

  테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.

  깨끗한 테스트 코드를 만들려면? 세 가지가 필요하다.

  가독성, 가독성, 가독성. 어쩌면 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다.

  가독성을 높이려면? 여느 코드와 마찬가지다. 명료성, 단순성, 풍부한 표현력이 필요하다.

  테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.

10. 클래스

  - 클래스 체계

  클래스를 정의하는 표준 자바 관례에 따르면,

  가장 먼저 변수 목록이 나온다.

  정적(static) 공개(public) 상수가 있다면 맨 처음에 나온다.

  다음으로 정적 비공개(private) 변수가 나오며, 이어서 비공개 인스턴스 변수가 나온다. 공개 변수가 필요한 경우는 거의 없다.

  변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다.

  즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다.

  - 단일 책임 원칙 (Single Responsibility Principle)

  단일 책임원칙은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.

  SRP는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다.

  소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다.

  우리들 대다수는 두뇌 용량에 한계가 있어  '깨끗하고 체계적인 소프트웨어'보다 '돌아가는 소프트웨어'에 초점을 맞춘다.

  전적으로 올바른 태도다. 관심사를 분리하는 작업은 프로그램만이 아니라 프로그래밍 활동에서도 마찬가지로 중요하다.

  문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다.

  '깨끗하고 체계적인 소프트웨어'라는 다음 관심사로 전환하지 않는다.

11. 시스템

  '처음부터 올바르게' 시스템을 만들수 있다는 믿음은 미신이다.

  대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다.

  내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다.

  TDD, 리팩토링, 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장히기 쉽게 만든다.

  하지만 시스템 수준에서는 어떨까? 시스템 아키텍처는 사전 계획이 필요하지 않을까?

  단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수 없다는 현실은 정확하다. 맞는 말 아닌가?

  - 소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.

12. 창발성

  4가지 설계 규칙 (켄트백)

  - 모든 테스트를 실행한다.

  - 중복을 없앤다.

  - 프로그래머 의도를 표현한다.

  - 클래스와 메서드 수를 최소로 줄인다.

  소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다. 그러므로 코드는 개발자의 의도를 분명히 표현해야 한다.

  - 좋은 이름을 선택한다. 이름과 기능이 완전히 딴판인 클래스나 함수로 유지보수 담당자를 놀라게 해서는 안된다.

  - 함수와 클래스 크기를 가능한 줄인다. 작은 클래스와 작은 함수는 이름 짓기도 쉽고, 구현하기도 쉽고, 이해하기도 쉽다.

  - 표준 명칭을 사용한다. 에를 들어, 디자인 패턴은 의사소통과 표현력 강화가 주요 목적이다.

    클래스가 command나 visitor와 같은 표준 패턴을 사용해 구현된다면 클래스 이름에 패턴 이름을 넣어준다.

    그러면 다른 개발자가 클래스 설계 의도를 이해하기 쉬워진다.

  - 단위 테스트 케이스를 꼼꼼히 작성한다. 테스트 케이스는 소위 '예제로 보여주는 문서'다.

    다시 말해, 잘 만든 테스트 케이스를 읽어보면 클래스 기능이 한눈에 들어온다.