[클린코드] 1장 Clean Code

코드를 작성하는 것보다
요구사항을 반영하는 설계를 잘하는 것이 더 중요하다는 말을 듣곤 하는데,

요구사항의 디테일을 반영하는 것이 바로 코드이다.

코드가 중요하지 않다는 것은 사실이 아니다.

(요구사항에 따라 서비스를 만들어주는 프로그램 역시 코드로 되어있다)

 

코드가 요구사항을 표현하는 궁극적 방식이라는 것을 기억하자

 

나쁜 코드를 작성하는 이유는 무엇일까?

이런저런 핑계로 빠르게 코드를 작성하는 데만 집중해서다.

엉망진창으로 만든 코드를 보면서도 내일 해야지 하며 넘겼을 것이다.

‘어쨌든 돌아가니까’라는 핑계로 손대기를 꺼려했을 것이다.

어떤 개발자든 ‘나중에 해야지’라는 말을 한다.

르블랑이 말했듯 나중은 결코 오지 않는다

 

나쁜 코드가 탄생한 데에 대해

잦은 요구사항의 변경, 말도 안 되는 일정 등 많은 핑계를 찾을 수 있지만

결국은 코드를 짜는 개발자의 잘못이다.

프로그램과 관련한 정확한 정보를 관계자에게 전달하는 것 역시 개발자가 해야 할 일이다.

매니저가 시키는 것을 하지 않으면 해고될까? 대개 그렇지 않다.

매니저가 원하는 것은 할 수 있다고 말하는 것이 아니라 진실이다.

매니저가 일정과 요구사항을 들이미는 것은 그들의 업무가 그것이기 때문이다.

개발자의 업무는 좋은 코드를 고집하는 것이다.

 

스케쥴에 맞추기에 급급해 만들어내는 나쁜 코드는

결국 미래에 우리가 코드를 짜는 것을 방해해 스케쥴을 맞추기 힘들게 한다.

일정에 맞출 수 있는 방법은 단 하나, 언제나 깨끗한 코드를 작성하려고 노력하는 것이다.

 

어떻게 작성한 것이 깨끗한 코드일까?

어떤 코드를 보고 나쁜 코드인지 아닌지 구별할 수 있다고 해서

내가 깨끗한 코드를 작성할 수 있는 것은 아니다.

코드 센스가 중요하다.

코드 센스를 어떻게 가질 수 있는지는 안 알려줌. 책을 읽으면서 자연스럽게 습득..?

 

전문가들이 정의하는 깨끗한 코드

• 비야네 스트롭스트룹(C++ 창시자)
  • 효율성: 단순히 속도 얘기가 아니다. 나쁜 코드는 나쁜 코드를 불러온다.
  • 에러 처리: 디테일에 집중하자
  • 하나의 코드는 한 가지 일을 한다

 

• 그래디 부치(UML 개발자)
  • 가독성: 산문처럼 읽혀야 한다.
  • 꼭 필요한 것만 있어야 한다.

 

• 데이브 토마스(OTI의 설립자)
  • 다른 개발자가 읽고 수정할 수 있다.
  • TDD
  • smaller is better

 

• 마이클 페더스(레거시 코드 활용 전략의 저자)
  • CARE: 누군가 정성을 들인 코드. 간결하고 정돈되어 있는 코드를 만들도록 디테일까지 신경쓴 코드

 

• 론 제프리스
  • 테스트
  • 중복이 없다: 코드가 중복해서 쓰인다는 것은 머리 속의 아이디어가 코드로 표현이 되고 있지 않다는 뜻.
  • 설계 의도를 보여준다: 변수명이나 하나의 코드는 하나의 일만 하는 것
  • 추상화: 개체의 수를 최소화한다. 응용이 가능하게 만든다.

 

• 워드 커닝햄(위키, Fit의 창시자)
  • 의도한 대로 동작한다.
  • 코드가 마치 이 문제를 위해 만들어진 언어같이 느껴진다.
  • 프로그램이 간결하게 보이게 하는 것은 언어가 아니다. 프로그래머가 언어를 간결해 보이게 한다.

 

Javadoc에 @author 필드가 있다.

작가가 되려면 독자가 있어야 한다.

작가는 독자와 의사소통을 잘 풀어나갈 책임이 있다.

코드 한 줄을 쓸 때, 본인이 작가라는 자각을 해야 한다.

 

새로운 코드를 쓰기 위해서 기존의 코드를 읽는 데 상당한 시간을 투자하게 된다.

그래서 읽기 쉽게 쓰는 것이 중요하다.

 

코드를 깨끗하게 짜는 것과 함께 노력해야 하는 것이 있다.

시간이 지나도 코드가 깨끗하게 유지될 수 있도록 하는 것이다.

처음에는 좋은 코드였지만 시간의 흐름과 함께 엉망이 되는 경우를 봤을 것이다.

좀 더 나은 변수명을 적용하고, 함수를 쪼개는 등 간단한 일부터 시작하자.

시간이 지날수록 더 나은 코드를 만들 수 있다.

 

이 책에서 주로 말하는 설계 원칙

PPP(Agile Software Development: Principles, Patterns, and Practices)

설계원칙 참고 링크

07장 SRP: 단일 책임 원칙

• SRP(the Single Responsibility Principle)
  • 단일 책임 원칙
  • 메서드와 클래스 수준
  • 객체는 하나의 책임만을 가진다
  • 기능 변경이 이뤄졌을 때 파급효과와 밀접한 관련이 있다
  • 한 클래스가 여러 책임을 가지면 클래스 내부의 코드의 결합도가 높아지면서 시스템이 복잡해진다.
  • 기능 변경이 이뤄지면 이 클래스의 코드 전체를 테스트해봐야만 한다
  • 즉, 모듈이 변경되는 이유는 한 가지여야 한다.

 

• OCP(the Open Closed Principle)
  • 개방 폐쇄 원칙
  • 1988년 버트란트 마이어,
    소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
  •  
  • 시스템을 컴포넌트 단위로 분리하고,
    저수준 컴포넌트에서 발생한 변경으로 부터 고수준 컴포넌트를 보호할 수 있는 형태의
    의존성 계층구조가 만들어 지도록 해야 한다.
  •  
  • 아키텍처 수준에서 OCP가 동작하는 방식
    1. 처리 과정을 클래스 단위로 분할하고, 클래스는 컴포넌트 단위로 분할한다.
    2. Controller, Presenter, Viewer, Interactor, Database
    3. 컴포넌트 관계는 단방향으로만 이루어 진다.
    4. 보호의 계층구조가 '수준level' 이라는 개념을 바탕으로 어떻게 생성되는지 주목하다.
    5. Interactor는 가장 높은 수준의 개념이며 최고의 보호를 받는다.
    6. View는 가장 낮은 수준의 개념이며, 거의 보호를 받지 못한다.

 

• DIP(the Dependency Inversion Principle)
  • 의존성 역전 원칙
  • 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다.
    저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.
    이것을 아주 쉽게 말하면, "자신보다 변하기 쉬운 것에 의존하지 마라."
  •  
  • 런타임에서의 의존이 아니라 소스코드 단계에서의 의존을 말한다.
    (런타임에서는 저수준에 의존하게 되기도 한다.)
    겨울에 자동차(고수준 모듈)를 만들면서
    봄이 되어 일반 타이어를 끼게 될 때, 자동차의 코드에도 연쇄적인 효과가 가게 된다.
    그래서 자동차가 타이어(스노우 타이어, 일반 타이어 등을 포함)를 껴야 된다고 설계한다.
    타이어는 저수준 모듈보다는 고수준 모듈인 자동차 입장에서 만들어지는데
    이것은 고수준 모듈이 저수준 모듈에 의존했던 상황이 역전되어
    저수준 모듈이 고수준 모듈에 의존하게 된다는 것을 의미한다.
    ⇒ 의존성 역전의 원칙
  •  
  • 유연성이 극대화된 시스템은 구체가 아닌 추상에 의존한 소스코드를 가진다.
    구체적인 요소는 변동성이 크기 때문에 지양해야 한다.
  •  
  • 안정된 소프트웨어 아키텍트란 변동성이 큰 구현체에 의존하는 일은 지양하고,
    안정된 추상 인터페이스를 선호하는 아키텍처라는 뜻이다.
    
    1. 변동성이 큰 구체 클래스를 참조하지 말라 : 대신 추상 인터페이스를 참조하라.
    2. 변동성이 큰 구체 클래스로부터 파생하지 말라 : 상속은 신중하게 사용되어야 한다.
    3. 구체 함수를 오버라이드 하지 말라 : 구체 함수는 소스코드 의존성을 필요로 하므로, 의존성을 상속하게 된다.
       차라리 추상함수로 선언하고, 구현체들에서 각자의 용도에 맞게 구현하라.
    4. 구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라.
  •  
  • 추상 팩토리를 사용하면 제어흐름은 소스코드 의존성과
    정반대 방향으로 역전되기 때문에 의존성 역전 원칙이라고 부른다.
  •  
  • DIP를 위배하는 코드를 모두 없앨 수는 없다.
    구체 컴포넌트는 최소한 하나 포함되는데
    main 함수를 포함하기 때문에 메인이라고 불린다.

---

나쁜 코드를 작성하게 되는 이유 부분을 읽으면서

나중에 수정하겠다고 생각한 뒤 다시 열어보지도 않은 프로젝트들이 떠올랐다.

해야 할 일은 계속 쌓여만 가니까 이미 돌아가는 코드를 굳이 수정하면서 시간을 써야할까 싶었던 것도 사실이다.

말로는 코드를 잘 짜고 싶다고 하면서 막상 개선하기 위해서 한 노력은 없는 것 같다.

이 책을 읽으면서 해결책을 찾아가고 싶다.

 

‘일정과 요구사항을 고집하는 건 매니저의 업무이고,

좋은 코드를 짜는 건 개발자의 업무’라는 말 역시 많은 생각을 하게 됐다.

일정에 맞춰서 요구사항의 최소조건을 만족시키기 위해 급급한 모습이

프로답지 못하다는 얘기를 보니

좀 더 내가 하는 일에 애정을 가져야 할 것 같다.