복잡한 업무 코드(내가 짠게 아닌) 파악하는 방법

개요

매번 코드분석하다 보면 삼천포로 새버리고 1시간 2시간을 의미없이 버리는 경우가 너무 싫어서 도움되는 방법을 찾아보았다.

 

어떻게 하면 복잡한 업무코드를 빨리 파악할 수 있을까?

가장 좋은 방법은 업무를 잘 아는 사람(업무 전문가)이 하나하나 설명해 주는 것일 테지만 만나기 어려울 뿐만 아니라 만나더라도 매우 바쁠 가능성이 농후하다. 또한 업무 설명을 들어도 막상 개발하기 어려운데 그 이유는 업무와 코드를 연결할 수 있어야 개발이 가능한데 복잡한 업무만큼이나 코드 역시 복잡하고 대부분 코드에 도메인이 잘 드러나 있지 않아 연결하기 쉽지 않다.

필자가 처음 복잡한 업무를 맡았을 때 옆에 업무 전문가가 있었지만 그 역시 매우 바빴다. 즉, 그가 나에게 사용할 시간이 적었다. 시간이라는 제한된 자원에서 복잡한 업무를 빠르게 파악하기 위해서는 효율적으로 질문할 필요가 있었다. 맥락 없는 모호한 질문에는 명확하고 정확하게 답변해 주기 어려운 법이다. 맥락을 먼저 파악한 후에 구체적으로 질문해야 원하는 것을 얻을 수 있다.

필자가 시도한 방법은 전체 코드 빠르게 훑어서 맥락을 파악하고 코드와 연결하여 구체적인 질문으로 복잡한 업무를 파악하는 것이었다. 왜 코드였을까? 업무는 코드로 구현된다. 즉 코드는 업무의 구현체이기 때문이다.

이 글은 필자가 사용한 코드 분석 방법을 기록한 것이다.

SQ3R(Survey, Question, Read, Recite, and Review)

새로운 프로젝트에 참여할 때였다. 프로젝트는 TypeScript/Angular를 사용하고 있었는데 당시에 필자는 둘 다 해본적이 없었다. 그렇다고 사정을 이해해 달라고 할 수는 없다. 당장 개발해야 했다. 빠르게 학습해야 했다.

가장 먼저 서점에서 TypeScript로 쓰인 Angular 책을 샀다. 그리고 책 전체를 대강 최대한 빠르게 읽었다.(예제 코드 역시 타이핑하지 않고 대강 읽었다) 책을 다 읽는 데는 1주일이 체 걸리지 않았고 TypeScript/Angular가 대강 무엇인지, 어떤 것을 할 수 있는지 감이 왔다. 그다음으로 바로 필요한 기능을 개발하기 시작했다. 중간중간 막이는 부분은 책 일부를 찾아서 자세히 보며 해결했다. 그 결과 매우 빠르게 개발에 필요한 지식만을 습득할 수 있었으며 일정에 무리 없이 개발할 수 있었다.

사실 이 방법은 SQ3R이라는 독서법을 응용한 것이다.

 

1. Survey

- 맥락을 파악하는 단계로 구체적인 기능 개발이라는 목적의식을 가지고 책을 대강 빠르게 훑는다.

2. Question

- 구체적인 기능을 실제로 개발을 하면서 막히는 부분을 확인한다.

3. Read, Recite, Review

- 막히는 부분만 기술된 부분을 찾아 자세히 읽으며 해결한다.

 

프로그래밍 언어를 모두 알아야 코딩할 수 있는 것이 아니다. 일부만 사용한다. 그 이유는 바로 쓰임새에 있다. 앞서 언급한 ‘개발해야 하는 구체적인 기능’이 바로 쓰임새다. 세부적으로 모두 잘 알 필요는 없는 것이다. 쓰임새로 의도적으로 학습을 한다면 필요한 것만 빠르게 학습할 수 있다. 업무도 마찬가지이다. 모든 업무를 다 알아야 개발할 수 있는 것은 아니다.

코드 추상화와 하향식 분해

앞서 언급한 SQ3R을 응용하여 업무 코드를 분석해 보자.

복잡한 코드를 분석할 때 핵심은 코드의 세부사항에 빠지지 않고 윤곽(의도)을 파악하는 것이다. 전통적으로 객체 지향 프로그래밍에서는 복잡성을 다룰 때 추상화를 사용해 왔다.

추상화란 어떤 양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해서 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다. - 오브젝트 268 쪽

예전에 안영회 님으로부터 파워포인트를 사용한 코드 추상화 방법을 배운 적이 있다. 방법은 아래와 같다.

1. 유의미한 코드 블록을 캡처한다.
2. 새로운 슬라이드를 만들고 붙인다.
3. 슬라이드 위에 제목으로 순서와 코드 의도를 적는다. 의문점이 있다면 같이 적는다.
4. 1-3 번을 반복한다.

세세한 코드에 빠지지 않고 슬라이드 1장 단위로 계속 추상화해 나간다. 이 작업이 끝나면 슬라이드 제목만을 따서 마인드 맵으로 연결하면 전체적인 지도를 얻을 수 있다.

지금까지 SQ3R의 Survey를 한 것이다.

책은 기본적으로 구조화가 잘 되어 있기 때문에 색인 페이지만 보면 무엇을 다루고 있는지 그 위치가 어디인지 쉽게 알 수 있다. 하지만 코드는 그렇지 않다. 위의 작업은 책의 색인 페이지를 만드는 과정과 비슷하다고 볼 수 있다.

코드 세부사항을 ‘의도적으로 생략하거나 감춤’으로써 전체 윤곽을 파악한다. 이 과정에서 업무 흐름이 보이고 중복도 보이고 의문감도 생긴다. 결국 대강 감이 온다.

그다음으로 기능 개발이라는 쓰임새로 마인드 맵과 PPT를 번갈아 보면서 구체적인 질문을 한다. SQ3R의 3R(Read, Recite, Review)을 시도하는 것이다.

‘분할하고 정복하라’ 복잡성을 다룰 때 자주 마주치는 말이다. 

출처: https://www.popit.kr/%EB%B3%B5%EC%9E%A1%ED%95%9C-%EC%97%85%EB%AC%B4-%EC%BD%94%EB%93%9C%EB%A5%BC-%EB%B9%A0%EB%A5%B4%EA%B2%8C-%EB%B6%84%EC%84%9D%ED%95%98%EA%B8%B0/

복잡한 업무 코드를 빠르게 분석하기 | Popit