타인의 소스를 살펴볼때 조언 부탁드립니다
글쓴이: kws4679 / 작성시간: 월, 2011/04/11 - 10:17오전
우선 잘 알고 있는 구조 하에서는 눈에 확 들어옵니다만
잘 모르는곳에서는 정말 보기 힘들더군요 코드가 잘 짜여졌든 아니던...
어쨋던 저보다는 실력이 더 좋으신 분이 짜신걸로 추정되는 소스를 보는데
생성자나 자동적으로 처리되는부분이 많아서 소스의 흐름을 따라가기 약간 힘들기도 한데
이런 경우 어떤 방식으로 보시는지 조언 부탁드립니다
추가적으로 비쥬얼 스튜디오 기능에 대해서 정리되있거나 알수 있는 방법 없나요?
코딩 내용보다도 기타 디버깅이나 단위 테스트등 그런 기능을 좀 체계적으로
학습하고 싶은데... 도움말을 봐야 하는지 감이 안잡힙니다..
Forums:
..
일단은 당장필요하고 제일 많이 쓰이는 소스만 따라가보는게 좋을 것 같습니다. 그러다보면 레이어나 옵젝트 사이를 왔다갔다하는 아키텍쳐가 보일 것 같습니다. 단위 테스트가 있다면 예외를 전부 무시하고 리턴할때 따라가보는 것도 도움이 될 것 같습니다. 아예 디버거로 메인 브렌치를 따라가보는게 쉬웠던 것 같습니다.
A rose is a rose is a rose..
사람에 따라 다를 수 있는데, 일반 c 코드라면 일단
사람에 따라 다를 수 있는데, 일반 c 코드라면 일단 모듈간의 의존성을 빠르게 파악한 이후, 흐름을 따라 다니면 됩니다.
제대로 설계가 되어 있다면 대충 함수 이름이나 동작만 살펴봐도 전체적인 흐름이 잡힙니다.
그 중에서 필요한 부분을 더 자세히 보면 보통 문제가 해결됩니다.
제대로 설계가 되어 있지 않다면, 전역을 많이 쓰고 있거나, 불필요하게 인자로 포인터를 넘긴다거나 하면,
한줄 한줄 살펴보면서 디버깅 툴과 함께 해야할 경우가 많습니다.
c++라면, 흐름과 관계없이 일단 파일간의 의존성, 클래스간의 의존성부터 검사하고 시작합니다.
이것만 제대로 되도 설계가 제대로 되었는지 안되었는지 파악이 됩니다.
그 다음에 main부터 흐름을 따라가는데, 딱 보기에 중요한 클래스를 우선적으로 살펴봅니다.
이후 필요한 부분을 집중적으로 보면 문제가 해결됩니다.
그런데, 설계가 제대로 되어있지 않다면, 싱글톤을 많이 쓰고 있거나, 클래스간 의존성이 거미줄처럼 엮여있거나 하면,
역시, 한줄 한줄 살펴보면서 디버깅 툴과 함께 해야할 경우가 많습니다.
참고로, 의존성 파악하는데는 A3지와 샤프, 지우개가 최고로 좋습니다.
------------------------------
How many legs does a dog have?
SVN 기록을 추적하기도 합니다.
요새는 debugging만 하면서 살아서인지 SVN 도구 사용시간이 작업시간의 절반이군요.
"Show me your flowcharts and
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified.
Show me your tables, and I won't usually need your flowcharts; they'll be obvious."
- Fred Brooks, 1975
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
저는
그냥 브레이크포인트 걸어서 아 이때 여기가 실행되는구나.. 하고 노트에 적어놓고
또 구조체나 전역변수 파악해서 아 이게 여기와 여기에서 같이 사용하는구나 하고 노트에 적어놓고
또 별개로 함수목록 가능하면 다 만들고 cscope 같은걸로 함수 호출관계 파악해서 노트에 적고
그다음 프로그램 목적이 뭔지 생각해서 거기에다가 이프로그램흐름이 어떻게 적용되겠다 추측해서 살펴본걸 노트에 적고..
그다음에 노트에적은걸 모아서 정리하고.. 코드파일별로 정리하고..
그렇게 하는데 사실 다른사람코드를 보는건 사실 힘들죠 ㅋㅋ
저같은 경우는
일단. 내가 이 프로그램을 만든다면 어떻게 만들까?
하고 고민하는 것이 중요한 것 같습니다.
다만 아무런 정보없이 고민하는 것이 아니라 해당 프로그램의 장점 이라던지.. 해당 프로그램의 특징과 관련된 글을 읽어봅니다.
그리고 나서 내 스스로 이런 프로그램을 만들면 어떻게 만들까? 어떤 구조로 만들까? 하고 고민해봅니다.
아키텍처를 그려봅니다.
그리고 나서
리버스 엔지니어링이 이럴때 필요한게 아닐까 생각합니다.
일단. 관련 클래스에 대한 클래스 다이어그램을 리버스 엔지니어링을 통하여 생성하고 프린트 합니다. (이때 의존 관계는 표시가 안되죠)
그리고 나서 메인메소드부터 찾아 나갑니다.
찾아나가면서 중요 의존관계는 프린트한 다이어그램에 표시하고 노트하고 해나가면서 밝혀(?) 나갑니다.
물론, 해당 소스에서 다른 오픈소스 라이브러리를 이용하는 부분도 있기 때문에 해당 부분은 api를 찾아보거나.
역시 중요부분이라 판단하멶 해당 오픈소스를 위와 같은 방식으로 반복합니다.
이 때 디자인 패턴에 익숙하다면 도움이 많이 되더군요.
클래스를 만드는 사람들이 패턴의 이름을 가져다 사용하는 경우가 많기 때문입니다. 예를 들면 ListAdapter 클래스 와 같이 클래스를 만드는 거죠.
그러면.. 아 이부분은 아답터 패턴이 적용되었겠군...
하면서 접근하면 쉽게 해석 할 수 있습니다.
즉, 소스 분석도 잘할 수 있다는 건.....
구력이 필요한게 아닐까 생각합니다.
Human based
몇 년전에 "뉴욕의 프로그래머" 를 읽으면서 느낀 점은...
윗분께서 말씀하신 것처럼 "사람"을 먼저 review 해야 합니다.
세상에는 수많은 코드멍키가 있습니다. 그 만큼 타인의 소스르 분석하는 것은 어렵습니다.
정형화된 방법은 없다면 다각도에서의 접근이 필요할 것 같습니다.
0. 소스코드의 목적(용도)에 따른 api, libaray, spec, tools, standard survey 하기.
1. svn log, core review history, wiki ... 등을 문서 읽어보기
2. strace, debugger, valgrind, gprof, ... 툴로 실행 및 분석 해보기.
3. ctags, cscope, grobal, source insight ... 등으로 2번과 병행하기.
4. 소스 조금씩 수정해서 debug 해보기.
5. boundchecker, vTune, purify, coverity, codesonar, klocwork ... 등의 상용툴로 본석해보기.
6. 버그, 성능개선... 등 해보기
결국 정답은 자기만의 스타일, 요령(스킬)을 익히는 것입니다.
일단 단번에 모든 코드를 이해하기는
일단 단번에 모든 코드를 이해하기는 어려울것입니다.
대부분의 경우 다른 사람의 코드가 어떤 문제가 있는데 이걸 해결해보라는 작업일겁니다.
저같은 경우는 코드의 흐름을 따라 읽습니다. 단번에 이해가지는 않습니다만,
일단 실마리가 잡히면 어느정도 내용을 파악하게 됩니다.
코드를 계속해서 읽고 분석하다보면 어느새 흐름을 외울 정도가 되게 되고,
심지어 어느 경지에 이르면, 소스의 구조적 논리를 이해하는 것도 가능하고
코드 자체가 각각이 무슨 역할을 하는지는 정확히 이해하지 못하고 있어도
논리적인 버그를 잡을 수 있게 되며, 코드를 더 간결하게 고칠 수도 있습니다.
윗분중에 SVN 기록을 보신다는 분이 계셨는데,
저역시 커밋기록을 수시로 살펴봅니다. 커밋 로그와 변경내역에 나온 몇구절이 큰 힌트가 되더군요.