Introduction

Code를 통한 커뮤니케이션의 단계

• 생각을 하며 프로그래밍하기
  • 본능에 의해 코딩하는 것을 멈추고 내가 어떤 생각을 하고 있는지 살펴보는 여유를 가지는 것이다.
    • 어떤 기능이 왜 특정 객체에 있어야 하는지?
    • 특정 메소드의 이름을 어떻게 지었는지?
• 다른 사람들의 중요성을 인정
  • 커뮤니케이션이 가능한 코드를 작성
• 다른 사람을 위한 프로그램을 작성

Patterns

프로그래머가 일상적이고 반복적인 작업을 짧은 시간에 마치고, 진정 독창적인 문제에 더 많은 시간을 투입할 수 있다면 좀더 효율적인 프로그래밍이 가능할 것이다.

프로그램 작성시 적용되는 일반적인 법칙

1. 프로그램을 새로 짜는 경우보다는 기존 프로그램을 읽는 경우가 많음
2. 프로그램에 있어 완성 은 없음. 초기 개발보다는 수정하는데 들어가는 노력이 더 큼
3. 프로그램 구조는 몇 가지 상태와 제어 흐름 개념으로 결정
4. 프로그램을 읽는 사람은 개념과 더불어 세부 사항까지 이해해야 함
   • 세부 사항을 이해해야 전체 개념에 대한 그림을 그릴 수 있고, 전체 개념을 이해해야 세부적인 구현 내용을 이해할 수 있다.

패턴은 이러한 프로그램 사이의 공통점을 기반으로 한다.

패턴의 적용

• 모든 프로그래머는 루프를 어떻게 작성해야할지 결정해야 한다.
  • 이 질문에 대한 답은 어느 정도 윤곽이 잡힌 상태로, 순수하게 기술적인 문제만 남음
  • 루프는 읽기 쉽고, 작성하기 쉬어야 하며, 효율적이어야 할 것이다.

이러한 일련의 사항들을 고려하는 것이 패턴의 시작이다. 패턴은 반복적으로 접하게 되는 문제에 대한 해결책을 제시해준다.

• 패턴은 프로그래머로 하여금 좀 더 재미있고, 독창적인 일에 집중할 수 있도록 도와준다.
  • 패턴을 적용함으로써, 문제에 대한 해결을 빠르고 쉽게 할 수 있으며 이를 통해 시간과 에너지를 줄일 수 있기 때문이다.
  • 패턴은 반복적으로 일어나는 문제에 대한 합리적인 해결책을 제공해준다.
    • 각 패턴은 프로그래밍에서 발생하는 공통적인 문제와, 문제에 영향을 미치는 요소, 만족스런 해결책을 얻을 수 있게 하는 조언을 묶어놓은 것이다.

패턴은 절대적인 진리가 아니므로, 사람의 의사 결정을 돕는 도구 정도로 생각하는 것이 좋다.

프로그래밍 이론

• 아무리 많은 패턴을 알고 있더라도, 프로그래밍을 하면서 생기는 모든 상황을 커버할 수는 없다.
  • 이를 위해 프로그래밍 이론을 통하여 새로운 문제가 발생하더라도 해결책을 모색할 수 있다.
• 각 패턴의 배경에는 어느 정도 이론이 깔려 있고, 실제 프로그래밍할 때는 이 이론 외에 결정 사항에 영향을 미치는 많은 요소가 있다.
  • 여기서는 원칙과 가치로 나눌 수 있다.

가치

• 모든 프로그래밍에 적용되는 주제
• 프로그램일 잘 짜는 사람은 타인과의 커뮤니케이션 을 중요시하고, 코드의 과도한 복잡성을 피함으로써 단순성 을 추구하며 유연성 있는 코드를 작성한다.

커뮤니케이션

• 개발자가 코드를 쉽게 이해하고, 수정하고, 사용할 수 있다면, 그 코드는 개발자와 커뮤니케이션을 하고 있다고 이야기 할 수 있다.
• 타인을 고려해서 프로그램 작성
  • 코드가 좀 더 이해하기 쉽고 깔끔해지며, 더 효율적이 되고 생각은 명확해진다.
  • 새로운 관점에서 코드를 바라보게 되고, 스트레스가 줄어들며, 다른 사람도 볼 만한 코드가 만들어진다.

도널드 크누쓰는 프로그램을 책처럼 읽을 수 있어야 한다고 주장한다.

• 경제적인 효과
  • 소프트웨어 비용의 대부분은 소프트웨어가 개발된 후에 발생
  • 이해하기 쉬운, 커뮤니케이션을 하고 있는 코드를 작성한다면 개발 비용을 줄일 수 있다.

단순성

• 프로그램의 복잡도를 낮추면 프로그램을 읽고 사용하고 수정하는 사람들이 프로그램을 빠르게 이해할 수 있다.
• 프로그램을 최대한 단순화하고 의미 없는 코드는 제거하라.
• 설계시에도 과도한 요소는 모두 빼고, 요구 사항을 분석해서 꼭 필요한 사항만을 뽑아내라.

유연성

• 프로그램이 발전하는 방향으로 유연성을 갖추어야 함.
• 프로그램 수정은 가급적 쉬워야 하므로, 추측에 의거하여 유연성을 부여하는 것보다는 단순성을 유연하게 적용 후 테스트를 철저하기 수행하는 것이 좋다.
• 유연성이 있으면서도 당장 이득을 얻을 수 있는 패턴을 사용할 것

과도하게 유연성을 적용하면 코드의 복잡도를 증가시킨다.

원칙

• 가치처럼 언제나 적용되는 것은 아니나, 많은 패턴에서 사용된다.
• 항상 중요하지만 적용하기 어려운 가치와, 적용법은 명확하지만 조금은 지엽적인 패턴 사이의 가교 역할을 수행한다.

특정 문제에 어떤 패턴도 적용할 수 없는 경우나, 두 개의 패턴은 하나를 선택해야할 경우 원칙을 정함으로써 해결할 수 있다.

원칙을 이해하고 있다면, 각 패턴의 세부 내용 뿐만 아니라 패턴을 사용하는 근본적인 이유에 대해 알 수 있다.

지역적 변화

• 코드를 수정할 때, 함께 바꾸어야 하는 부분을 최소화하라.
  • 프로그램의 어떤 부분을 수정한 것이 다른 부분에서 문제를 일으킨다면 프로그램 수정에 대한 비용이 커진다.
  • 지역적 변화만 일으키는 코드는 커뮤니케이션이 쉽다.

구현 패턴을 사용하는 중요한 이유는 프로그램 수정 이유를 낮추기 위함인데, 이 지역적 변화의 원칙은 여러 패턴의 근간이 된다.

최소 중복

• 중복된 코드가 많으면 많을수록 코드 수정은 어려워진다.
• 프로그램을 여러 작은 부분으로 나누어 코드의 중복을 최대한 피한다.
  • 가급적 짧은 구문, 짧은 메소드 작성
  • 작은 객체, 작은 패키지로 분할
• 동일한 표현, 유사한 부분, 다른 부분을 명확히 표현

중복은 불가피하게 피하기가 어려울 수 있으므로 절대로 피해야 할 요소로 보기보다는, 코드 수정 비용을 높이는 위험요소로 생각하는 것이 좋다.

로직과 데이터의 결합

• 데이터와 그 데이터를 처리하는 로직을 가급적 밀접하게 배치하라.
  • 프로그램 수정시, 데이터와 로직이 함께 있다면 수정하더라도 그 영향이 일정 영역에 머물게 된다.

개방폐쇄원칙

대칭성

• 프로그램에서의 대칭성
• 하나의 아이디어를 프로그램 전체에서 일관된 방식으로 표현하는 통일성
• 대칭성에 따라 일관된 방식으로 표현하면, 코드 중복이 발생할 경우 하나의 구현으로 통합하기 쉬움

선언적 표현

• 수행 순서가 중요하거나 조건부 구문이 없는 일반 구문의 경우, Java Annotation 등을 통한 선언적 표현을 통해 코드를 작성하는 것이 이해하기가 쉽다.
  • 명령형 프로그래밍은 이해하기 위해서 수행 흐름을 따라가야 한다.

변화율

• 로직과 데이터를 함께 관리하고, 변화율이 다른 로직과 데이터는 분리
  • 하나의 객체에 있는 모든 필드는 가급적 함께 변해야 한다.
    • 특정 메소드가 수행될 때만 사용하는 필드는 그 메소드의 지역변수로 사용
    • 다른 필드와는 독립적인 두 개의 서로 의존적인 필드가 있다면 별도의 도우미 객체에 넣는 것이 좋다.

setAmount(int value, String currency) {
  this.value = value;
  this.current = currency
}

위 객체의 value와 currency가 서로 의존적인 필드라면 다음과 같이 묶어주는 것이 좋다.

Money money = new Money(value, currency)

...
setAmount(Money value) {
  this.value = value;
}

동기유발

• 소프트웨어는 전체 비용을 줄이는 방향으로 설계되어야 한다.
  • 전체 비용 = 개발 비용 + 유지 비용
  • 유지 비용 = 이해 비용 + 수정 비용 + 테스트 비용 + 설치 비용
• 초기 개발 비용에 많이 투자하는 것은 보통 전체 비용을 절감하지는 못한다.
  • 미래에 코드가 어떻게 수정될 지 알 수가 없으므로, 아무리 고민을 하더라도 모든 사항에 대응할 수 있는 완벽한 코드를 짜는 것은 불가능하다.
• 미래에 코드를 쉽게 확장할 수 있고, 수정이 쉬운 깔끔한 코드를 추구하면서 당장 얻을 수 있는 이득에 초첨을 맞추도록 하라.
  • 커뮤니케이션하기 쉬운 코드를 작성함으로써, 유지 비용을 줄일 수 있다.

패턴을 사용하는 버릇을 들이면, 읽고 이해하고 수정하기 쉬운 코드를 작성할 수 있을 뿐만 아니라, 더 빠르고 자연스럽게 코드를 짤 수 있다.