코드 퀄리티 관리
코드 퀄리티는 관리하기 어렵다. 특히 지속적으로 변경되는 코드는 청소와 같이 매일매일 지저분한 내용이 생기게 되고 이를
제대로 처리하지 못하면 쉽게 깨진 창문 효과를 일으키게 되며, 대규모의 라이브 게임의 경우 그 규모로 인해 슬럼화가 되어 버릴 수
있다. 코드 퀄리티가 나빠지는 건 결국 어쩔 수 없는 사실이라고 여겨야 한다. 하지만 관리를 위해 노력하는 정도에 따라서
망가지는 정도에는 차이가 크게 된다. 소스 코드를 변화하는 데이터로 생각해서 자동화와 시간에 대한 초점을 맞추어 관리를 해보도록
하자.
변동성
소스코드의 변동성이라는 것을 염두에 두고 각 프로그래밍 요소의 의존관계를 변동성이 낮은 쪽으로 가지고 갈 수 있도록 하게
되면 적절한 코드 퀄리티의 관리를 쉽게 할 수 있다. 많은 곳에서 이러한 변동성에 따른 의존관계 설정의 예를 볼 수 있다.
.cpp => .h
데이터 타입 =>알고리즘 (템플릿)
구현 => 인터페이스
로직 => 엔진
데이터 => 코드
변동성 측정
그렇다면 각 요소의 변동성을 가시화할 수 있다면 쉽게 관리해야할 영역을 선택할 수 있을 것이다. 이미 사용하고 있는 SCM 의 저장소 내용을 분석하여 변동성을 측정해보기로 한다.
가장 쉽게 할 수 있는 것은 단위 시간 별 파일의 변화량을 추출하여 분석할 수 있다. 가장 빈번히 변경되는 파일을 추출할
수 있고, 거의 변경이 없는 파일도 추출할 수 있다. 변경없는 요소는 라이브러리로 만들 수도 있고, 유니티 빌드에서 하나로
묶어서 빌드 시간을 단축시킬 수 있다. 빈번히 변경되는 파일 중에서도 의존 관계를 따져서 파급력이 큰 파일을 선택하게 되면 쉽게
문제가 되는 지점을 파악할 수 있다.
파일 레벨 외에도 함수별 변화량을 살펴볼 수도 있겠다. 각 라인을 diff 알고리즘으로 비교할 수도 있지만, 의미있는 값을 얻지는 못했다. 또 리비전 로그의 종류를 살펴보고 종류별 변화량을 파악할 수도 있다.
지속 가능성
코드 퀄리티의 지속적 관리를 위해서는 단 번에 개선을 시키는 것으로는 어렵다. 점진적으로 정리를 해 나가야 하고,
지속적으로 관리를 할 수 있어야 한다. 그러기 위해서는 공정에서의 개선이 필요하다. 공정 개선을 위한 팁으로는 다음과 같은 것이
있다.
Assert : Assert 를 다양하게 구성하여 문제가 될만한 것들을 쉽게 파악할 수 있도록 한다.
Validation : 서브버전 커밋 훅을 사용하여 문제의 여지가 있는 것을 미리 걸러낼 수 있다.
결론
재미있고 신선한 세션이었다. 이렇게 저렇게 이야기 되고 있던 내용이 변화량이라는 것으로 실체화되는 것도 재미있었고, 실제
게임의 각 저장소 내용을 분석한 결과도 재미있었다. 그냥 안 좋아보이는 곳을 바꾸는 것이 아닌 변화량과 파급력을 보고 가장
효과적인 부분을 수정하는 것이 좋다는 것과 다양한 기법을 이용해서 지속 가능하게 만드는 것에 대해서 적극적으로 적용해볼만할 것
같다.
