처음보는 복잡한 코드를 분석하는 좋은 방법 있을까요?
글쓴이: Lch@Naver / 작성시간: 화, 2020/06/02 - 11:20오전
대학생이고 현재 인턴업무 하고있습니다. 난생처음 1만줄 가량되는 복잡한 코드를 받고 코드를 분석하며 일정부분을 추가해야하는데 그 복잡함때문에 코드가 소화가 되질 않습니다 ㅠㅠㅠ
마치 영어 못하는 사람이 영영사전 보는것처럼 1함수를 분석하다 2클래스가 나오고 이건 또 3,4,5 클래스로 이뤄져 있고 또 3클래스 타고가면 a,b,c클래스들 나오고... 이러다보면 결국 하위로 나오는 이상한 클래스들만 잔뜩보고 찾고자 하는 함수 기능 세부분석은 못하게 되더라구여 ㅠ
혹시 여기계신 고수분들은(혹자는 혼자서 수만라인을 뚝딱뚝딱 짜신다 들었습니다) 큰 프로젝트를 받았을때 어떻게 분석하시고 자신의 아이디어를 녹이시나요? 기간은 대충 2달 조금 안되는 시간입니다
Forums:
왕도가 있을까요 ^^
일단 추가하고자 하는 동작위주로 코드를 분석하고 필요하다면 적절한 로그도 출력해보는 거죠
"하위로 나오는 이상한 클래스" 들도 결국 동적으로 생성되거나 하도록 만들어진거니 결국은 그 부분을 파고 들어야 되지 않을까 싶습니다.
------------------------------------------------------------
ProgrammingHolic
감사합니다
답은 시간과 노력이군요
수만 라인이면 소규모 프로젝트네요. 큰 그림 위주로
수만 라인이면 소규모 프로젝트네요. 큰 그림 위주로 보시고, 필요하시면 세부 구현을 보면 됩니다.
IDE 도움 받으시고요. 관련 지식 있으면 아.. 함수 이름 뭐뭐를 찾으면 되겠구나. 감이 올거고,
grep 으로 찾으면 직빵이죠.
분석하는 이유가 있을텐데
보통 버그 잡는거나 기능추가 이렇게 될텐데
목적에 부합되는 범위 내에서만 하세요.
그리고 답 안나오면 전체 흐름을 큰 종이에다가
그리고 답 안나오면 전체 흐름을 큰 종이에다가 그림으로 그리세요. 전체 흐름을 읽을 수 있으면 게임 끝난겁니다.
그리고 코드 분석이 어려운건 님이 못나서가 아니라
그리고 코드 분석이 어려운건 님이 못나서가 아니라 코드를 개떡같이 짜놓아서 그런거니 잘 안 되면 속으로 욕 열라하세요.
화이팅요~~~~~~~~~~~~
깊은 빡침은 님을 고수로 만들어줄겁니다.
대가분께서 조언을 해주시다니 ㄷㄷ
정성들여 다신댓글 정말 감사합니다 ㅠ 조금 감동받았습니다. 아 여담으로 1만라인이 소규모라니 ㅠ 고수가 되는길은 멀고도 험하군요
저의 경우...
저의 경우에는 uml과 sequence를 활용했습니다.
한 번 큰 클래스를 머리 속에 그려놓고, 그 다음에는 몰라도 일단 작성하면서 이해했습니다.
어느정도 기능별로 그렸으면, 그때에 다시 그림을 보면서 다시 한 번 분석합니다.
printf() 찍어 가면서 흐름 파악하는게 제일
printf() 찍어 가면서 흐름 파악하는게 제일 빠르더라구요.
----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라
가장 단순한 방법이 최고군요 ㅠㅠ
질문과 별개로 좋은책 잘봤습니다 신간은 이제 또 언제 나오나요?
...
일단 상위 수준에서, 큰 그림부터 파악을 합니다. 코드까지 내려오면 추상 수준이 낮고 디테일이 많아집니다. 그 디테일을 다 일일이 상대하면서 큰 그림을 잡는 건 쉬운 일 같지 않습니다. 가볍게는 위키피디아나 구글 이미지 검색부터 design documentation나 책 같은 거 찾아서 읽어서 어느 정도는 이 코드가 뭘 하자는 건지 상위 수준에서 파악할 필요가 있다고 생각합니다.
두 번째로 언어에 대한 부담이 없는 상태에서 시작하는데, 저는 보통 새 언어고 새로운 패러다임이라면 한 3 ~ 7일 정도는 그 언어만 공부합니다. 그러면 언어 때문에 읽다가 흐름을 잃는 경우가 좀 적은 것 같습니다.
그리고 좋은(?) 프로젝트는 개발자용으로 필요한 내부 데이터 스트럭쳐를 군데군데 덤프한다거나 하는 기능들이 들어가 있어서--유저는 못 보게 해놓은 경우도 많고요--, 이걸 이용해서 모듈 단위로 입출력을 봐가며 이해하는 것도 도움이 되는 것 같습니다.
아무 것도 모르고 그냥 무턱대고 코드부터 보는 경우를 제가 한국에 있을 때부터 많이 봐왔는데, 저는 이게 좋은 습관인지 모르겠습니다. 어려운 문제는 추상 수준을 높여서 해결을 하는 게 대체로 바른 방향인 것 같습니다.
제가 주로 쓰는 방법입니다.
제가 주로 쓰는 방법입니다.
1.gdb로 step into를 통해 프로그램 동작을 이해한다.
call graph를 복사해 놓고 sequence diagram을 그려 놓으면 좋다. 이것을 바탕으로 class diagram을 그려놓고 프로그램 전체 구조를 이해한다. 그리고 layered architecture diagram을 그려 놓는 것도 좋다.
출처: https://opensoftware.tistory.com/entry/남들이-짠-코드-읽기 [주네의 열린 소프트웨어]
_________________________
http://joone.net
https://kldp.org/blog/2725
http://opensoftware.tistory.com
http://joone4u.blogspot.com
https://gnome.or.kr
리눅스 기반 프로그램이면 uftrace 로 콜스택
리눅스 기반 프로그램이면 uftrace 로 콜스택 찍어봐도 좋습니다.
----------------------------------------------------
개인 블로그: https://kangssu.com
1. 설계 문서를 받는다... 없으면 패스~
1. 설계 문서를 받는다... 없으면 패스~
2. 전체 블럭도를 받는다... 없으면 패스~하고 직접 큰 그림은 그려 본다.
3. 중요 기능별로 함수 콜 그래프를 그려본다.
4. 1/2/3을 바탕으로 printf()를 넣어서 세부 기능을 확인한다.
결험상... 대책 없는 코드는 1/2/3번 불가능 경우도 있는데...
이경우는... 흠...
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
남이 짜놓은건...
설계서에 코딩 규약이랑 지침같은게 없다면 원체 파악하기 힘듭니다만...
저같은 경우라면... 먼저 작성 언어와 프레임워크, 특정 라이브러리의 사용 여부를 조사합니다.
프레임워크 같은경우 그 프레임워크에 맞는 약속같은것이 있기 때문에, 코드가 뜬금없어 보여도 그게 약속일수도 있고
xml같은곳에 별도 정의일수도 있고 경우의 수는 다양합니다.
그다음으로 받은 소스가 구체적으로 어떤 기능을 가진 프로그램이고 입출력이 어떻게 되는지 조사합니다.
이것은 대체로 서비스 사양 또는 설계서에 기재되어 있는것이 일반적이고
예를들어 REST API의 경우 입력은 HTTP Request이고 출력은 HTTP Response겠죠.
입출력이 파악되면 처리의 입구과 출구에 해당하는 소스가 어디있는지 찾습니다.
(여기서 프레임워크별로 처리의 시작점이 달라질수 있으므로 프레임워크가 사용되었다면 해당 프레임워크의 조사가 선행되어야 합니다.)
입구와 출구가 파악되면 프로그램이란게 어차피 입구 → 처리 → 출구 에서 벗어날수 없으므로 처리 부분이
이떻게 기술되어있는지 보고, 기능이 어디에 구현되어있는지 몸통을 찾습니다.
(예를들어 클래스를 4개 상속해서 구현되어있다고 치면 실제 처리가 구현되어있는 최종 클래스를 찾습니다.)
대체적으로 이렇게 여러개 상속하고 있는 경우, 클래스를 여러개 상속하고 있다는것은 공통적인 패턴이 있다는 이야기이므로
다른 기능도 비슷하게 구현되어 있을 확률이 크므로, 이 패턴을 찾습니다.
이렇게 처리가 호출되어 실행되는 패턴을 파악하고 나면 코드를 읽는 법이 보이기 시작합니다.
즉 코드를 읽어 처리를 파악하는 데에 한해서는 이 클래스 상속관계 파악의 중요도는 점점 떨어지고
결론적으로 어디에 구현을 주로 해놨는지를 보고 파악하는데 집중하기 쉬워집니다.
이 방법의 문제는, 해당 프로그램을 복수명이 제각각의 폴리시로 구현했을경우에는 효과가 적고
결과적으로 모든 패턴을 찾아내야만 읽어낼수 있다는 점입니다.
→ 라고 쓰긴 했으나 이렇게 패턴이 제각각이면 다른 방법으로도 효과적으로 분석은 힘들다 봅니다.
한 십년동안 담당자가 바뀌어가면서 기능추가 되고 한 프로그램은 물론,
담당자가 같은 사람이라도 장기간 수정된 프로그램은 폴리시 유지가 힘듭니다.
(처음 만들때 기능에서 덧붙이고 하다보면 다른 개념을 허용해야 하기도 하고 해서 예외투성이가 되기도 하기 떄문에)
--
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Hirameki --X-
Mail : hirameki_krjp@yahoo.co.jp
God is not customer center. Do it yourself
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL