[게임 프로그래밍 패턴] Chapter1 구조, 성능, 게임

좋은 소프트웨어 구조

수정 사항이 있을 때 적당한 함수 몇 개 호출하는 것으로 끝낼 수 있어야 한다.

⇒ 얼마나 쉽게 변경할 수 있는지!

코드를 고치는 방법

1. 기존 코드 파악
2. 문제 해결 코드 작성
3. 코드 정리

단순히 원하는 대로 돌아간다고 끝내지 말고 내가 수정한 코드를 나머지 코드와 맞춰주자!

디커플링

기존 코드를 파악하는 데 걸리는 시간을 줄이기 위해서,
즉 이해해야 하는 코드 양을 최대한 줄이기 위해서 디커플링은 필수!

커플링이 적은 코드의 장점

1. A 코드와 B 코드를 각각을 따로 이해할 수 있고, 한쪽 코드만 파악해도 수정이 가능하다.
2. A 코드를 수정했을 때 B 코드를 변경하지 않아도 된다. (=나머지 한쪽 코드에 미치는 영향이 적다.)

참고: Decoupling - Component 패턴

• 컴포넌트 패턴으로 디커플링
  • 각 분야마다 컴포넌트 클래스 만들고 (사용자 입력은 InputComponent, 물리는 PhisicsComponent) 필요하면 해당 클래스 인스턴스 만들어서 사용하기

---

비용

커플링이 적은 코드, 좋은 구조를 만들기 위해서는 많은 노력이 필요하다.

여기서 노력이란?

어디를 디커플링하고 추상화할지 고민하여 확장성 있게 설계하는 것

근데 만약 확장성 있는 코드를 열심히 만들었는데 해당 코드를 수정할 일이 없다면, 괜히 더 복잡하고 유지보수 비용만 들게 된다.

성능

좋은 소프트웨어 구조를 만들기 위해서 사용하는 가상 함수, 인터페이스 등은 성능에 영향을 준다.

⇒ 유연한 코드는 성능 ↓ / 최적화된 코드는 유연성 ↓

---

나쁜 코드의 장점

좋은 소프트웨어 구조를 위해서는 많은 노력이 필요하기에 단순 기획 확인용으로는 적합하지 않다.
나쁜 코드는 개발 속도가 빠르니까 이런 경우에는 나름 장점이 있다.
그치만 재사용하면 안된다!

• 당장 회사에서는 ‘나쁜 코드’를 작성해야 하는 일은 없을 것 같다.
• 게임잼에서 작성한 코드는 ‘나쁜 코드’, 나중에 갈아엎어서 다시 작성한 코드는 비교적 ‘좋은 코드’?
  
  

---

단순하게 가보는 건 어떨까…

깔끔한 구조, 최적화, 개발 속도 3가지 trade-off 목표들 간의 균형을 잡는 건 쉽지 않다.
이럴 땐 수많은 케이스들을 커버할 수 있는 단순한 코드를 작성해보자
코드가 단순 → 실행할 코드가 적음 → 속도가 빠름 (개발 속도는… 포기?)

• 당장 오늘 특정 케이스만 커버하는 코드를 쓰고 온 것을 반성하게 됨..