라이브 프로세스 분석을 통한 효율적인 로직 개발

​

라이브 프로세스 분석을 통한 효율적인 로직 개발

<게임 프로그래밍 패턴> DP

라이브 프로세스

- 기획서 이해 -> 기존 코드 분석 -> 구조 설계 -> 코드 작성 -> QA & 버그수정 -> 완성

<게임 프로그래밍 패턴> 책에서 기능추가, 버그수정 그 외 무슨 이유든 코드를 고치려면 먼저 기존 코드를 이해해야한다. 대부분 이 과정을 별것 아닌 것으로 여기지만 사실 프로그래밍에서 가장 오래 걸리는 부분이다.

코드 설계 시간 부족 -> Bad Code -> 분석 시간 증가 ->코드 설계 시간 부족.... 악순환

주제 : 분석에 소요되는 시간을 줄여서 코드 설계 & 작성하는 시간을 늘리자.

라이브에서 좋은 코드 : 새로운 코드를 작성 하기 전, 머리 속에 입력해야 할 정보가 적은 코드 ( 가독성 )

'코드'적인 측면과 '방법론'적인 측면

코드 : 작명 중요(변수, 함수, 클래스의 작명)

 1. 공통적인 내용이 앞에 있어 알아보기 쉽다. ex) GetName,GetNameRes,GetUserID

ex) CheckState() (O) CS() (X)

-> 작업자들간의 공유할 수 있는 네이밍 규칙이 필요합니다.

 2. 사용하지 않게 된"#if~endif"은 빠르게 삭제.

-> 대부분의 서비스중인 온라인 게임에서 #define의 개수는 적게는 몇백개에서 많게는 몇천 몇만개에 달한다.

가독성과 유지보수에 있어 굉장히 중요하고 민감한 부분임을 항상 명시하자.

 3. 미사용 코드는 꼭 제거하자

-> 완전히 같은 기능을 하는 중복 함수들

 4. 적재적소의 주석, 미사용 주석은 빠르게 제거.

-> 직관적으로 이해 가능할때는 주석 (O) 작성자만 알 수있는 코드는 주석 사용.

공통점 . 작은 불씨가 큰 불로.. / 업무 하다가 남은 시간에 정리하자. -> "남는 시간은 없다."

-> 반드시 "업무"로 할당하여 해결하자.

방법론

1. 짧은 개발 기간 동안 무리한 양의 개발은 피해야한다.

2. 개발 완료 이후 출시 전 사이 여러 번의 내용 변경 시도는 피해야한다.

-> 어쩔 수 없이 하게 되면 업데이트 이후 스케줄은 반드시 무리한 개발에 따른 비효율적인 코드(날림코드) or 리소스의 정리(리펙토링)가 되어야 한다.

무리한 개발을 진행하였으면 반드시 그에 따른 결과를 기록해야 하고 이른 향후 비슷한 이슈가 발생했을 때 참고자료로 사용해야 한다.

3. 퇴사 예정자에게는 새로운 업무 부여는 주어서는 안된다.

-> 퇴사 예정자가 진짜 해야 할 업무는 "신규 개발"이 아닌 "인수 인계"다.

4. 직 간접적인 "코드 리뷰"

-> 나는 10줄의 코드로 구현 가능하다고 생각한 기능을 다른 프로그래머는 단 2줄의 코드로 구현 가능한 방법을 알고 있을 수도 있다.

=> 직접적인 코드 리뷰 (결과물에 대해 모두가 토론) 30%

=> 간접적인 코드 리뷰 (리드 프로그래머의 검수) 70%(라이브는 이것이 대부분)

간접적인 코드 리뷰를 하면 팀원들의 리드 프로그래머에 대한 신뢰도 증가.

-> 프로젝트의 코드 퀄리티가 뛰어나다 응답.

작업자와 1:1 대화를 통한 코드 리뷰 or 관련 컨텐츠의 샘플 코드 제시 -> 방향을 제시

=> 리더가 직접 코드를 작성하며 게임 코드의 변화를 자세히 파악하고 있어야 한다.