꽤나 많은 상황에서 우리는 기존 코드를 분석해야 한다.
빌드업이라 불리는 프로젝트에 필요한 기능들을 만져나가는 과정에서도 우리는 라이브러리나, 오픈소스 코드등을 통해서 기존 코드를 분석해나가야 한다.
물론 이 과정은 섬세하게 만져나갈 여지가 있고, 그간의 결합도를 조절해나갈 여지가 있으므로 상대적으로 코드 분석의 여지가 적다.
심지어 사용하는 라이브러리들이 익숙하거나, generic하게 구현되어있다면 더더욱이 쉽고.
사실 가장 곤욕스러운 과정은 프로젝트 dependency 한 코드를 분석하게 될 때이다.
이 과정에서, 코드간의 결합도를 낮출려고 노력해온 흔적이 있는 경우는 그래도 상대적으로 쉬운 편에 속한다. 예를 들어 패킷으로만 다른 티어와 통신을하고, 패킷 핸들링 코드가 명확하다면 기존 코드가 난해하다해도 그 결합도를 풀어가는데에 상대적으로 수월하다.
하지만 진입점의 종류가 한 곳이고, 각 기능별로 핸들링 코드가 분리되어있음에도 객체간의 관계가 명확하지 않고, 쓸데 없이 복잡하게 보이는 일은 비일비재하다.
이럴때 당신은 어떻게 분석하는가? 또, 인수인계를 위해 어떻게 준비해야 하는가?
많은 코드 분석과정을 해본결과, 또 지켜본 결과 많은 사람들이 두가지 방법정도로 코드를 분석하더라.
상향식 코드분석과, 하향식 코드 분석이다.
큰 그림. 즉, 전체적인 구조 설계의 전제 파악, entry point 분석, 스레드 디자인 분석과 같은 프로젝트의 룰을 파악하는데에 주력하는 것을 하향식 코드 분석이라 부른다.
반대로 컨텐츠별로 하나씩 기능들을 분석하며, 실제 컨텐츠별 사용중인 클래스들을 분석해나가는 것을 상향식 코코드 분석으로 부른다.
이 두가지 모두 적절히 이루어지면 좋겠지만, 사실 대부분의 경우 입사나 부서이동 직후 업무를 바로 진행해야되는 경우가 수두룩 하다.
이럴 경우 어떤 방법을 먼저 채택할 것인가?
나의 경우는 항상 하향식 코드 분석을 선호해왔다.
프로젝트의 룰, 전제를 모르고선 다른 코드들의 디테일을 봤을 때, 이 코드가 과연 잘 작성된 코드인지, 혹은 자연스레 녹아든 코드인지 판단도 안된다고 여겨서이다.
그렇다고 상향식 코드 분석이 나쁘다고 볼 순 없다.
일관된 규칙으로 코드가 잘 관리되어왔고, 간결하면 간결할 수록, 상향식 코드 분석이 빛을 발하기 때문이다.
하지만 그런 상황은 그다지 자주 벌어지지 않는다. 어찌보면 작성되어있는 코드 양이 많으면 많을수록 이상론적인 이야기이고, 꽤나 많은 경우에는 하향식 코드 분석을 선행하고, 이후 상향식 코드 분석으로 전환하는 과정이 옳다고 본다.
여기에 문서화에 대한 이야기를 빼놓을 수 없다.
그렇다면 인수인계 및 자신의 작업 기록을 위한 문서화는 어떻게 해야 하는가?
나는 작업 규칙과, 설계 기준을 명세하면 충분하다고 생각한다. 각 작업의 디테일은 고생한 과정을 기반으로 기록해 둘 수록 좋다. 만약 두사람 이상이 같은 작업 과정에서 고생했다면, 그 작업 자체가 집중을 요하는 작업이거나, 혹은 실수의 여지가 많은 빈틈있는 기반 작업이 되었다는 것을 (혹은 그러한 툴이나 라이브러리, 코드 등을 이용하거나) 의미하기 때문이다.
겪었던 문제들에 대한 기록만 잘 취합되어 있더라도 상대적으로 많은 시간을 아낄 수 있다고 생각한다. 그래서 나는 버그 노트를 작성하기 시작했는데, 이에 대한 이야기는 다음 글에서 이어서 하려 한다.