이직으로 인해 타 업체 개발자에게 업무를 인수인계하던 중~ 좀 더 효율적으로 소스를 분석하면 좋겠다는 생각에 Assembly dependency를 출력해서 주었습니다. 사실, 관련 업종에 있다 하더라도 특정 업무에 의한 Business logic을 단 몇일만에 이해한다는건 불가능합니다. 그래서 대부분 핵심적인 내용을 듣고 그 이후에는 스스로 소스를 분석해 가며 관련 기능들을 알아가게 되죠. 아무리 문서화가 잘 되어 있다하더라도 결국은 분석하는 사람의 능력 또는 관련 업무 경험에 크게 좌우됩니다.

 

(그 업체는 아직도 Doc에 일일이 장표를 만들고 있네요-_-; 과연 이 문서들이 관리가 될지 의문입니다. 보니깐 2년동안 진행한 프로젝트던데 문서들 Version이 다 1.0인거 보니 알만하죠-_-; 맥가이버칼(TFS)을 사놓고 이쑤시게(SourceSafe)만 사용하는 형국이라 갑갑합니다.)

 

 

소스에서 클래스, 메소드를 따라다니면서 일일이 정리하는 분들은 없으리라 생각하지만, 간혹 보면 아직도 이렇게 정리하고 계시는분들이 종종 보입니다. 엑셀에서 그림을 일일이 그려가며 Depth를 화살표로 연결하고 자신이 이해한 수준에서 코멘트를 달고 하는 것들이 무의미하다는 것은 경험적으로 알 수 있습니다. 당장은 분석하면서 따라가는게 도움이 되기도 합니다. 머리속에서 정리도 되구요. 하지만 Depth가 많아질수록 소스 분석이 어려워지고 향후에 이렇게 정리한 문서를 다른 사람이 볼 때는 또다른 정리가 필요할 수 있습니다. 더큰 문제는 지속적으로 문서가 관리되지 않을 가능성이 100%라는 점입니다. 처음 분석 단계에서는 열심히 작성 했겠지만 시간이 흐르고 익숙해지면 또는 일정상 쪼이게되면, 문서 작업은 아무래도 뒷전이 되겠죠. 대부분 소스 코드 변경에 대해서 문서가 업데이트되는 일은 없을겁니다. 

 

 

어떻게 하면 좀 더 쉽게 소스를 분석하고 빠르게 내재화하여 자신의 것으로 만들 수 있는지에 대한 고민은 아주 오래전부터 있어왔습니다. 제 홈페이지에서도 설명한 TFS처럼 형상관리를 해야 하는 것이죠. 부수적으로 코드를 정량적으로 관리하기 위한 솔루션도 도입이 되어 있다면 더 좋을겁니다. 이런 내용들은 이미 강좌에서 설명했으므로 간략하게 방법에 대해서 알아보겠습니다.

 

일반적으로 메시지를 확인하기 위해 Sequence Diagram을 작성하게 됩니다. 만약, 엔터프라이즈급 프로젝트라면 여러 업체들이 SI를 하면서 서로 인터페이스도 만들고 OOP의 장점인 캡슐화로 인해 빠르게 시스템을 구축할 수 있겠죠. 하지만, 여기에서 한 업체가 계약 종료되어 인력이 빠져나갔다고 하면, 이 업체에서 개발한 모듈 또는 라이브러리들이 내부에서 어떻게 동작하는지 이해하기는 쉽지 않을겁니다. 그래서 상속 다이어그램, 협력 다이어그램 및 영향도 분석 다이어그램을 활용하여 유지보수를 이어나가게 되겠죠. 또한, Doxygen을 이용하여 문서화가 잘 되어 있다면 더 좋겠죠. 여기에 각 업체가 관리하는 모듈들에 대한 종속 관계를 파악하고 추적할 수 있다면 외부 모듈에 대해 분석이 더 용이할 것입니다.

 

 

Visual Studio의 Ultimate버전의 경우에는 Architecture메뉴가 존재합니다. 이 메뉴를 이용하여 Assembly Dependency Diagram을 작성할 수 있습니다. 각 모듈을 클릭하면 항목이 확장되면서 내부로 들어갈 수 있습니다. 주석이 잘 달려있다면 메소드, 속성, 특성등등에 대해서도 쉽게 확인이 가능합니다.

 

 

TFS에 요구사항을 등록하고 Check-in시점에 변경된 파일들을 Mapping시키면 변경에 대한 이력 확인 및 추적이 빛을 발하게 됩니다. 실제로 이런 프로세스를 경험하게 되면 드라마틱한 개발 생산성 향상을 가져올 수 있게됩니다.

 

개발자에게 후원하기

 

추천, 구독, 홍보 꼭~ 부탁드립니다.

여러분의 후원이 빠른 귀농을 가능하게 해줍니다~ 답답한 도시를 벗어나 귀농하고 싶은 개발자~

감사합니다~

추천0 비추천0