몇 가지 꿀팁

• 추상화와 디커플링은 프로그램을 더 빠르고 쉽게 진화시켜준다.
  • 하지만 해당 코드가 실제로 그런 유연성을 필요로 한다는 확신이 서지 않는다면, 그런 작업에 시간을 낭비하지 말자.
• 개발 주기 내내 성능을 염두에 두고 설계하자.
  • (예: "게임이 1초에 1프레임만 실행되는 문제"를 해결하려고 출시 2개월 전에 서둘러 최적화하는 건 정말 피하고 싶은 상황)
  • 하지만 코드에 특정 가정을 고정시키는 저수준의 세부적인 최적화 작업은 최대한 미루자
    • 코드 실행 성능을 높이기 위해 코드의 세부적인 부분을 조정하는 작업
    • 예시)
      • 특정 함수 호출을 줄이기 위해 코드를 인라인으로 작성
      • cpu 또는 GPU 효율을 높이기 위해 특정 알고리즘 미세 조정
      • 작은 성능 향상을 위해 데이터 메모리에 특정 방식을 저장
• 어떤 게임 플레이나 매커니즘이 재미있는지 알아보기 위해 빠르게 움직이자. 하지만 너무 서두르다 엉망진창인 코드를 남기진 말자. 그 코드랑 함께 작업해야 하는 것은 미래의 자신이다.
• 만약 나중에 확실히 삭제하거나 폐기할 코드라면 굳이 깔끔하게 작성하지 말자. ROCK STAR들이 호텔 방을 엉망으로 만드는 이유는 다음날 체크 아웃 할 것을 알고 있기 때문.
• 무엇보다, 재미있는 무언가를 만들고 싶다면, 만드는 과정 자체를 즐기자.

추상화에 관한 이야기

• 유연성과 성능 사이의 균형이 중요하다. (과도한 추상화(유연성)는 코드 베이스가 지나치게 복잡해질 수 있음)
• 처음부터 완벽한 성능을 추구하기보다는, 빠르게 아이디어를 실험하고 반복하여 재미있는 게임을 만든 뒤에 성능 최적화를 진행하는 것이 더 낫다.
• 하지만 과도한 추상화로 코드가 복잡해지는 "YAGNI(You Aren’t Gonna Need It)"를 경계해야 한다.

프로토타이핑에 관한 이야기

• 초기에는 대충 코드를 작성하는 프로토타이핑이 효율적일 수 있다.
• 하지만, 대충 만든 코드를 절대 실제 코드로 사용해서는 안 된다.
• 프로토타입 코드가 실제 코드로 자리 잡지 않도록, 명확한 의사소통과 방어적인 조치를 취해야 한다.

결론 : 균형을 잘 맞춰라

• 개발에서의 세 가지 목표:
  • 장기적인 코드 품질(좋은 아키텍처): 유지보수가 쉬운 코드 작성.
  • 빠른 실행 성능: 최적화된 코드.
  • 단기적인 작업 속도: 오늘의 기능을 빨리 구현.
• 이 세 목표는 서로 충돌한다:
  • 좋은 아키텍처는 시간이 더 걸리고,
  • 최적화는 유연성을 희생시키며,
  • 기능을 빨리 추가하면 코드베이스가 엉망이 되어 장기적으로 문제가 된다.