패턴을 활용한 리팩터링(Refactoring to patterns)

책 한권 읽는게... 이렇게 힘들다니.. ㅜㅜ

단순히 읽는것도 힘들었지만, 실제 패턴 코드들을 보면 '아 그렇구나..' 라는 생각은 드는데 막상 내가 이걸 어디에 활용할 수 있을까? 라는 의문도 생기고, 나중에 이걸 기억했다가 쓰기도 힘들것 같다.

게다가 모든 패턴들이 다 납득? 이해? 가 되지도 않는걸 보면 아직은 내 실력이 많이 부족하구나.. 라는 생각이 든다.

열심히 노력해야지 ㅜㅜ

Chap 1. 이 책을 쓴 이유

- 과도한 설계

  코드를 필요 이상으로 융통성 있게 또는 정교하게 만들 때, 이를 과도한 설계라고 한다. 어떤 프로그래머들은 시스템에 대한 미래의 요구사항을 알고 있다고 믿기 때문에 과도하게 설계한다. 오늘 설계를 좀 더 융통성 있고 정교하게 해두어, 내일의 요구사항을 수용할 수 있게 하는 것이 최선이라 생각하는 것이다. 그럴싸하게 들린다. 여러분이 무당이라도 된다면 말이다.

  그러나 예상이 틀렸다면 귀중한 시간과 비용을 낭비한 꼴이 된다.

  게다가 필요할 것이라 예상하고 만들었지만 전혀 쓰이지 않는 코드는 절대 없어지지 않는다. 그 코드를 제거하는 것이 귀찮거나 또는 언젠가 필요해질지도 모른다고 생각하기 때문이다.

  과도하게 설계된 코드는 생산성에도 영향을 미친다. 그 코드를 받은 프로그래머가 그것을 마음대로 확장하거나 제대로 유지보수 하려면, 설계의 의미를 파악하기 위해 많은 시간을 투자해야 하기 때문이다.

  -> 작고 단순하고 이해하기 쉬운 코드를 작성하는 데 주의를 기울여야 한다. (이게 말이 쉽지... 얼마나 어려운데 ㅜㅜ)

- 테스트 주도 개발(TDD)과 지속적인 리팩터링

  1. 질문 : 테스트를 작성함으로써 시스템에 질문한다.

  2. 대답 : 테스트를 통과하는 코드를 작성해 질문에 대답한다.

  3. 정제 : 아이디어를 통합하고, 불필요한 것은 제거하고, 모호한 것은 명확히 해서 대답을 정제한다.

  4. 반복 : 다음 질문을 물어 대화를 계혹한다.

Chap2. 리펙터링

- 리펙터링이란?

  "겉으로 보이는 동작을 바꾸지 않고, 이해하거나 수정하기 쉽게 소프트웨어의 내부 구조를 바꾸는 것" (Martin Fowler)

- 리펙터링을 하는 이유

  1. 새로운 코드를 더 쉽게 추가할 수 있도록 하기 위해.

  2. 기존 코드의 설계를 개선하기 위해

  3. 기존 코드를 더 잘 이해하기 위해.

  4. 덜 짜증나는 코드로 만들기 위해.

"컴퓨터가 이해하는 코드는 어느 바보나 다 짤 수 있다. 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 짠다."

(Martin Fowler)

- "설계부채"는 다음 세 가지를 꾸준히 수행하지 않을 때 발생한다.

  1. 중복 제거

  2. 코드 단순화

  3. 코드의 의도 명료화

  : 설계부채로부터 완전히 자유로운 시스템은 거의 없다. 인간이 처음부터 완벽한 코드를 작성할 수 없기 때문에, 우리는 설계 부채와 떨어질래야 떨어질 수 없다. 자연스럽게 부채가 쌓여간다. 따라서 문제는 '빚을 언제 갚을 것인가?'로 바뀐다.

Chap3. 패턴

  - 패턴의 진정한 성과는 패턴을 현명하게 사용할 때 나타난다. 리팩터링은 중복을 제거하고, 코드를 단순화하고, 코드가 그 의도를 잘 드러내도록 하는 데에 우리의 주의를 집중하도록 함으로써, 패턴을 현명하게 사용하도록 도와준다. 리팩터링을 통해 점진적으로 패턴을 도입하면, 패턴으로 인한 과도한 설계가 발생할 기회도 줄어든다. 그리고 리팩터링을 더 잘 이해할수록 패턴이 주는 즐거움을 이해할 확률도 높아진다.

Chap4. 코드속의 냄새

- 가장 흔한 설계 문제는 다음과 같은 원인들로 인해 생긴다.

  1. 중복된 코드가 있다.

  2. 코드의 의미가 명확하지 않다.

  3. 코드가 복잡하다.

- 코드 속의 나쁜 냄새

  : 중복된 코드, 긴 메서드, 복잡한 조건문, 기본 타입에 대한 강박관념, 추잡한 노출, 문어발 솔루션, 인터페이스가 서로 다른 대체 클래스, 게으른 클래스, 거대한 클래스, switch문, 조합의 폭발적 증가, 괴짜 솔루션