ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 게임 프로그래밍 패턴 Part 1 도입 - 구조, 성능, 게임
    보관함 2020. 1. 11. 18:40

    게임 프로그래밍 패턴로버트 나이스트롬 (Robert Nystrom)
    상세보기

    이 시리즈는 [게임 프로그래밍 패턴]에 등장하는 팁을 정리하고 패턴을 직접 구현하거나 구현되어 있는 패턴을 확인하는 것으로 해당 패턴에 대해 이해하는 것을 목표로 한다.

     

    이번 포스팅에서는 책의 도입부 내용에 등장하는 저자의 생각과 내가 생각하는 중요한 내용을 정리한다.

    Part1 도입의 전문은 [게임 프로그래밍 패턴-맛보기 by 한빛미디어]에서 볼 수 있다.


    소프트웨어 구조란?)

    작업에 들어가기 전에 알아야 할 지식의 양을 줄이는 것. 이것이 내가 생각하는 소프트웨어 구조의 핵심 목표다.

    저자는 코드의 개선이 필요한 경우 혹은 기능이 추가되어야 할 때 기존 코드를 이해하고 문제 해결에 필요한 코드를 작성하고 테스트한 뒤 코드를 정리하여 추후 다른 동료 프로그래머가 해당 코드를 봤을 때 수정된 것을 알아차리지 못한다면 성공적이라고 말한다.

     

    나는 이 내용이 전체 코드와 필요한 작업을 파악한 뒤 작업하여 다른 코드에 영향이 가지 않는 것을 보장하는 것이 좋은 소프트웨어를 유지하는 데 도움이 된다고 이해했다.

     

    이것은 '디커플링'을 통해 가능해진다.


    커플링     : 저자는 커플링을 양쪽 코드 중 한쪽이 없으면 코드를 이해할 수 없는 것으로 정의했다.

    디커플링 : 커플링을 없애는 것이다.


    비용은?)

    좋은 구조는 생산성을 크게 높여준다. 하지만 세상 일이 다 그렇듯이 그냥 되는 건 아니다. 좋은 구조를 만들고 유지하려면 많은 노력과 원칙이 필요하다.

    개발자는 다른 개발자가 이 코드를 사용할 때 제약이 없고 강력하며 확장하기 쉬운 코드 베이스를 만들고자 하며 예측을 통해 필요한 기능 혹은 확장을 구현하고자 한다. 하지만 이 코드들을 사용할 일이 없다면 작업해야 할 코드만 드러나게 될 것이다.

     

    성능과 속도)

    경험상으로는 재미있는 게임을 최적화하는 것이 최적화된 게임을 재미있게 만드는 것보다 훨씬 쉽다.

    코드를 유연하게 만드는 패턴이 가상 함수, 인터페이스, 포인터, 메시지 등에 의존하는데 어느 정도 런타임 비용을 요구한다. 하지만 어떤 작업에 대해 확신할 수 있다면 그 작업에 맞게 최적화할 필요가 있다.

     

    즉, 다음과 같이 주고받는 관계에 놓이게 된다.


    유연한 코드, 빠른 개발, 성능상 비용 증가 <=> 최적화된 코드, 개발 속도 저하, 성능상 비용 감소


    이에 대해 저자는 처음에는 코드를 유연하게 유지하다 기획이 확실해진 다음에 추상 계층을 제거해 성능을 잡는 방법을 제안한다.

     

    나쁜 코드의 장점)

    기획 확인에 필요한 기능만 간신히 돌아가도록 대강 코드를 작성하는 프로토타이핑 기법은 아주 적법한 프로그래밍 실천법이다. 다만 주의사항이 있다. 버릴 코드는, 나중에 확실히 버릴 수 있게 해야 한다.

    구조화가 잘된 코드는 작성하려면 많이 고민해야 하며 그것을 개발 기간 내내 유지하려면 엄청난 노력을 들여야 한다. 하지만 단순히 기획 확인을 위한 코드를 이와 같이 만든다면 기획이 취소되는 경우 노력을 들인코드가 그대로 버려질 위험이 존재한다.

     

    그러므로 기획 확인이 필요한 경우엔 프로토타이핑 기법을 통해 빠르게 확인한 뒤 코드를 다시 제대로 만드는 편이 나을 것이다.

     

    다만, 프로토타이핑의 문제점인 완성품인 줄 아는 문제가 있으니 이를 기획자 혹은 결정권자에게 분명하게 인식시켜야 할 것이다.

     

    균형 잡기)

    좋은 구조는 장기적으로 생산성을 높여주지만, 구조를 좋게 유지하려면 코드를 변경할 때마다 노력을 더 들여야 한다.

    우리는 목표는 세가지로 볼 수 있다. 첫째 프로젝트 개발 기간 코드를 쉽게 이해할 수 있는 구조를 원한다. 둘째 실행 성능을 최적화하고 싶다. 셋째 기능을 최대한 빠르게 구현하고 싶다는 것이다.

     

    그런데 이 세 가지는 각각 장단점이 존재하며 동시에 이를 취할 수 없다. 즉, 이 세 가지의 밸런스를 잘 잡아 개발을 최적화하는 수밖에 없다.

     

    단순함)

    좋은 해결책은 코드를 덧붙이는 게 아니라 필요 없는 코드를 최대한 빼는 것이다.

    단순한 코드는 읽었을 때 의도를 바로 알 수 있다. 또, 코드가 단순하게 유지되면 전체 코드도 줄일 수 있다.

     

    코드를 단순하게 만드는 것은 유스 케이스를 나열하는 것보다 훨씬 어렵다. 유스 케이스에 숨어있는 규칙을 찾아낸다면 좋은 코드를 얻을 수 있다. 게다가 엄청난 성취감도 따라온다.

     

    마치며)

    뭔가 재미있는 걸 만들고 싶다면 먼저 만드는 데에서 재미를 느껴보라.
    • 추상화야 디커플링을 잘 활용하면 코드를 점차 쉽고 빠르게 만들 수 있다. 단, 유연함이 필요하다는 확신이 없다면 이를 작성하는데 시간을 낭비하지 말아라.
    • 개발 내내 성능을 고민하고, 최적화에 맞게 설계해야 한다. 단, 개발 속도에 영향을 줄 수 있는 저수준 최적화는 최대한 늦게 하는 편이 좋다.
    • 게임 기획의 내용을 확인할 수 있도록 빠르게 구현하되 코드를 엉망으로 만들지는 말아라.
    • 나중에 버릴 코드를 잘 만들겠다고 시간 낭비하지 말자.

    댓글

Designed by Tistory.