[게임 프로그래밍 패턴][1]도입

좋은 구조를 만든다는것

해당 책에서는 좋은 소프트웨어의 구조를 만든다는 것은 이해하기 쉽고 변경하기 쉬운 구조를 만드는 것이라고 한다. 장기적으로 사용하는 코드는 결국 확장과 수정을 거쳐야 하는데 그럴때마다 변경과 관련된 부분을 다시 읽고 이해해야하며 이에 대한 소비 시간을 줄이는 것은 생산성의 증가로 이어진다. 변경자체를 하기 쉬운 구조는 말할 필요도 없을 것이다.

 

커플링

소프트웨어 구조에서 커플링은 두개의 개발 단위(클래스, 함수 등)이 서로 얾켜있는 경우를 이야기한다. 조금 모호한 개념인데 책의 저자는 이를 한쪽만 보고 코드를 이해할 수 없다면 커플링되어 있다고 보고있다. 디커플링은 이러한 둘 사이의 의존성을 줄여 독립적으로 만드는 것을 말한다. 이를 통해 한쪽을 수정할 때 반대쪽까지 이해할 필요가 줄어들며 각각에 대한 모듈성도 늘릴 수 있다.

 

비용

확장성과 수정용의성이 높은 코드는 분명 강력한 장점을 가지지만 비용도 존재한다. 일단 추상계층의 추가로 성능에 오버헤드가 발생한다. 또한 로직상으로 최적화를 할때는 해당 코드의 사용범위를 정확하게 가정하고 제한하는 경우가 많은데 이는 확장성 또는 수정용의성과 상충된다. 

확장성과 수정용의성을 지키며 만든 구조는 그렇지 않은 구조보다 단기적으로는 시간과 가독성이 오히려 떨어질 수 있다. 처음 구조를 설계할때도 시간이 들며 이후 기능이 추가될때마다 구조를 지켜야하기에 시간이 소모된다. 이후 실제로 코드에 확장과 수정이 발생하면서 이러한 시간들을 보상받을 수 있지만 그렇지 않다면 구조를 신경쓰지 않은 경우보다 시간적으로 손해를 보게 된다. 가독성 측면에서도 추가적인 추상계층의 코드로 인해 코드양이 늘어나 이해하는데 시간이 오래걸릴 수 있다. 따라서 앞으로 재사용하지 않다는게 확실하면서 규모가 그렇게 크지않은 작업을 빠르게 해야할때는 대충만든 구조가 용의할 수도 있다. 실무에서는 간단한 느낌 확인용 프로토타입을 만들때가 그 예시이다. 하지만 이러한 코드들을 나중에 재사용하여 확장하고 수정할 가능성이 있다면 구조를 잘짜두는게 좋을 것이다. 당연히 평범하게 런칭목적으로 만드는 게임 코드라면 앞으로 무수히 확장되고 수정될 것이 당연하므로 구조를 잘 신경써야한다. 하지만 실무에서는 짧은 시간으로의 성과를 요구하는 경우가 많아 그러한 구조 설계가 잘 이루어지지 않는 경우도 있는 듯하다.

코딩에서의 목표는 다음 세가지라고 볼 수 있다.

1. 확장 및 수정하기 좋은 구조로 만들기

2. 성능 최적화

3. 빠르게 만들기

위 세가지는 상충되는 경우가 많기에 상황에 맞게 잘 판단해야한다.

 

 

 

 

참고서적

게임 프로그래밍 패턴