긴 소스코드를 분석할 때 뭘 먼저 하는게 좋을까요?

awdxawdx101의 이미지

모듈이나 라이브러리가 아닙니다.

main()부터 차근차근 그 코드의 실행 흐름에 따라가면서 분석도 해보고, 그전에 모든 함수들을 분석해보려고도 했었는데 어떤 방법이 효율적인지, 초보자에게 적절한 방법인지 모르겠습니다.

그리고 두 방법 모두 시도해보았는데, 계속 이전에 분석했던 함수를 잊어버리고 또 분석하는 상황이 생깁니다. 이 문제는 주석만 달아주면 해결될까요?

세벌의 이미지

두 가지 다 해 보셔요. 장단점이 있으니. 그러면서 실력이 느는게 아닐까요?
주석만 달아준다고 다 해결된다면 얼마나 좋겠어요?

ymir의 이미지

모듈이나 라이브러리가 아닌 긴 소스코드란게 어떤 건지 감이 안 오네요.

일단, 일반적인 제품 관련 소스 코드라 가정하고..;;
분석을 왜 해야 하는지를 먼저 고민해 보셔야 할 것 같습니다.
목적이 분명하면 어떻게 행동해야 할 지도 확실해 집니다.

설계를 하면, 기능 명세를 정하고 내부 모듈에 대한 아키텍쳐와 인터페이스를 만들고..
적당한 로직에 따라 해당 기능이 동작할 수 있도록 로직을 구성합니다.
그리고 나서 코드를 만들게 되겠죠.

분석은 역으로, 구현된 코드를 통해 설계가 제대로 반영되었는지 확인하는 작업이라고 보시면 됩니다.
설계가 없다면, 설계를 추정하는 작업이 되겠죠.

소스 구조를 통해 모듈과 인터페이스를 분리해 내고..
main 으로부터 call graph 를 그리고, pseudo code 로 바꿔서 어떤 로직으로 흘러가는지 보고..
필요하면 sequence diagram 이나 state machine 등 다양한 형태로 로직을 정리해야 합니다.

그 외에 기능이나 OS 와 관련된 어떤 매크로들이 존재하고 각각의 역할은 무엇인지 파악해야..
선택적으로 기능을 on/off 하는 경우에 대처할 수 있을 겁니다.

소스 코드가 잘 정리되어 있고, header 의 include 구조가 잘 잡혀 있다면..
doxygen 만으로도 모듈간의 hierarchy 를 쉽게 유추할 수 있고, call graph 추적하기가 쉽습니다.
doxygen oupput 을 html 로 뽑아내고, 웹 서버에 붙이면 언제든 쉽게 검색할 수도 있구요.

만약 코드에 뭔가 추가해서 분석을 쉽게 하고 싶다면..
doxygen 을 염두에 두고 주석이나, include 관계를 정리하는게 더 나을 수도 있을 겁니다.

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』

reistrem의 이미지

세세한 로직보다는 전체적인 흐름을 먼저 파악하는게 좋을거 같네요. 소스간의 연관이나 함수들간의 관계들 같은것 위주로요.

joone의 이미지

cats96의 이미지

분석할 파트를 나누어서 하나씩 하는게 좋다고 봐요

UI, 핵심기능, 초기화, 구조, 프로세스(스레드)간 통신방식 등등

요즘엔 시리얼한 프로그램이 별로 없어서 main()부터 따라가는 분석 방식은 그다지 효율적이지 못하고

오히려 더 복잡하게만 느낄수있습니다

각각 기능별, 파트별로 쪼개서 하나하나 분석하다보면 나중에 전체적인게 차즘 보이지 않을까 싶네요

ap4200의 이미지

주로 보던 코딩스타일이랑 너무 다른 코드를 보게되면 로직이나 컨셉이 비슷해도 이해가 잘 안되는 현상이 있더라구요 ㅜㅜ
그래서 전 가끔 너무 이해 안될때는 코딩스타일을 좀 고쳐서 보기도 해요