Wednesday, December 27, 2006
소스 분석 하기 -- 개요 및 간략한 내용
소스 코드 분석하기.
(어떻게 쓸 것인가?)
0. 왜 다른 사람이 작성한 소스를 읽어야 하는가? ( 배경 언급 )
(소프트웨어 엔지니어로 일한다면 남의 소스를 읽을 기회를 많이 접할 수 밖에 없다.)
0.1 프로젝트 수행 기간 단축,
0.2 잘 모르는 분야의 기능을 사용해야 하는 경우,
0.3 재활용을 강조하는 최근의 추세 -> Component Based Design,
0.4 프로젝트 전임자의 코드를 인수 인계하는 경우,
0.5 기존 소프트웨어와의 호환성 문제를 해결하기 위해 기존의 코드를 사용하는 경우,
...
1. 문제가 무엇인가?
남이 작성한 코드는 읽기가 힘들다. 그렇지만 이해해서 사용해야 한다.
그것도 제한된 시간내에
2. 왜 읽기가 힘든가?
코딩 스타일이 다르다.
제대로 된 설계 과정을 거치지 않은 코드가 많다. 회사 단위에서 수행하는 프로젝트도
무식하게 설계된 소스를 많이 양산한다. 오픈 소스는 관리 부실로 인해 읽기 어려운 코드를
양산함.
문서화가 제대로 되어 있지 않다. (왜 안할까? 귀찮아서?)
...
3. 어떻게 소스를 읽을 것인가?
왕도는 없다. 하지만, 이러한 방법을 쓰면 좀 더 편하게 빨리 분석할 수는 있을 것이다.
3.1. 일단 전체 연관관계(Dependency)를 파악한다.
include 파일들을 보고, 각 파일들의 관계를 그림으로 그려라.
3.2. 코드의 시작 부분을 파악하라.
그림에서 다른 파일들에 의해 include 되지 않는 마지막 노드를 찾아라
대부분의 경우 main() 함수는 그곳에 존재한다.
3.3. Control Flow를 그려라.
실행 순서를 대충이나마 그려볼 수 있다.
4. 어떤 이득이 있는가?
숲을 먼저 보고, 나무를 보게 되니까 이해가 좀 더 쉬워진다.
어떤 소스를 이용하기 위해 소스를 완전히 이해할 필요는 없다. 대부분의 경우, 입력/출력만
확인해서 기능을 사용하는 것이 고작이다. -> 대부분 최종 종착 파일에서 확인할 수 있다.
문제가 발생했을 때, 문제 범위를 제한할 수 있다. (그래프에서 연관성이 있는 부분만 보면 된다)
한장의 그림은 100마디 말보다 더 많은 것을 말해준다. (직관의 힘!!)
5. 결론 (권유)
나는 이런 방법론을 쓰고 있다. 당신도 써보라. 조금은 괜찮아질 것이다.
6. 기타 코멘트....
이러한 분석을 수행해주는 도구들이 존재한다. (관련 tool들, Doxygen, GraphViz, ...)
UML과 같은 도구는 위의 과정을 거꾸로 수행한다. 즉, 그림에서 코드를 만들어 내려는 노력인 것
