1장. 도입

'게임 프로그래밍 패턴' 교재를 학습하며 핵심 내용을 정리해보았다.

---

CH1. 구조, 성능, 게임

1.1 소프트웨어의 구조

• 소프트웨어 구조의 핵심 목표
  - 작업에 들어가기 전에 알아야 할 지식을 줄이는 것
  - 생산성(코드를 더 유연하고 변경하기 쉽게 만듦)을 높이기 위한 좋은 구조를 갖추는 것
  - 추상화, 모듈화, 디자인 패턴, 소프트웨어 구조를 사용하는 이유 역시 생산성을 높이기 위해서이다.
  
  
• 좋은 구조란 무엇인가?
  - 구조는 변경과 관련이 있기 때문에, 얼마나 쉽게 변경할 수 있느냐가 코드 설계 평가의 척도가 된다.
  - 코드를 거의 건드리지 않고도 적당한 함수 몇 개를 호출하여 원하는 작업을 할 수 있어야 한다.
  
  
• 좋은 구조 만들기
  1. 코드를 변경하는 방법
  - 코드를 고치기 전에 먼저 기존 코드를 이해해야 한다.
  - 문제를 해결하기 위한 코드를 작성한다.
  - 컴파일에 성공했다면 테스트(자동화된 단위 테스트 등)를 작성한다.
  - 코드 리뷰를 요청하기 전에 추가한 코드를 이전 코드들과 깔끔하게 통합되도록 정리한다.
  
  2. 디커플링을 이용한다
  - 커플링이란? 양쪽 코드 중에 한쪽이 없을 때 코드를 이해할 수 없으면 서로 커플링 되어 있다고 본다.
  - 디커플링이란? 어느 한 코드를 변경했을 때 다른 코드를 변경하지 않아도 되는 것
  - 디커플링시 기대할 수 있는 효과는? 한 번에 이해해야 하는 코드의 양을 최대한 줄일 수 있다.
  
  

1.2 비용은?
- 하지만, 무조건 디커플링을 통해 좋은 구조를 만드는 것이 정답은 아니다.
- 좋은 구조를 만들고 유지하는 데에는 많은 노력과 원칙이 필요하다.
- 기능을 추가하거나 변경할 때마다 나머지 코드와 깔끔하게 통합되도록 노력해야만 한다.

• 코드를 통합 하기 위한 노력이란?
  - 프로그램 어디를 디커플링하고 추상화할지 고민
  - 추후 쉽게 변경할 수 있으려면 어디를 확장성 있게 설계할지 미리 정해야함
  
  * 확장성의 딜레마
  - 예측되는 필요에 따라 유연성을 발휘해야 하는데, 이를 위해 코드를 추가하다보면 시간이 더 걸리게 된다.
  - 또한 만들어놓은 모듈이 실제로 써먹지 못하면 지금까지의 작업이 헛수고가 된다.
  - 확장성에만 매몰 되면 코드에 이것저것 살이 붙어 계층이 복잡해지고 구조가 막 나가게 된다.

1.3 성능과 속도

- 빠른 프로토타이핑을 위해 프로그램을 유연하게 만들면 성능상 비용이 발생한다.
- 반면 코드를 최적화하면 유연성이 떨어진다.

- 즉, 유연성(비용)은 최적화(성능)와 반비례한다.
- 코드에 유연함이 필요하다는 확신이 없다면 추상화와 디커플링을 적용하려 애쓰지 말고 추후 기획이 확실해졌을 때 추상 계층을 제거해 성능을 높이는 타협안도 있다.

- 저수준의 핵심 최적화는 가능한 늦게 해야 한다.

1.4~1.6 균형을 잡기 위한 단순함
- 오랫동안 같은 코드로 계속 작업해야 하는 경우 구조화가 잘된 코드를 작성하는 것이 좋다.
- 하지만 기획 확인 수준의 코드라면 구조를 멋지게 만들기보다 빨리 만들되 버릴 코드는 확실히 버릴 수 있게끔 적당히 작업 해야한다.
- 제약을 완화하기 위해 필요없는 코드를 최대한 빼서 간결하고 적은 로직으로도 많은 유스케이스를 정확히 해결하게끔 짜야 한다.
- 즉, 우선적으로 자료구조와 알고리즘을 순서에 맞춰 먼저 잡아놓은 다음 다른 방법을 찾아야 한다.