소스코드 분석, 코드 리뷰 분석 방법 모아봤습니다.

 

 

소스코드 분석은 정말 어려운 일입니다. 그러니 오죽하면 분석보다 새로 짜는게 더 쉽다는 말이 나오기도 하고요. 그러나 소스를 본다는것은 새로운 철학을 만나는 것이라고 봅니다. 오래된 코드건, 만든지 얼마 안되어 유지보수가 필요한 코드건 말입니다.

 

개발된 제품의 소스코드를 보고 있는데 C 파일과 header 파일 갯수만 124 개나 됩니다. 헉~~  전투력 급저하 됩니다.

 

소스 코드 분석은 코드 리뷰와는 많이 다르다고 합니다. 제 생각엔 일단 큰 구조를 파악하고, 점점 반복해 가면서 세부적인 내용으로 분석해 들어가는 방법이 좋은 방법입니다. 아래 글들은 소스 코드 분석에 대한 좋은 글들을 몇개 모아봤습니다. 도움이 되면 좋겠습니다.

 

 

 

 

하나~

 

소스코드의 분석은 말은 쉽지만 실제로는 엄청난 일입니다.

 

코드의 크기나 복잡도에 따라 틀려지겠지만, 엄청난 양의 용량을 필요로 하는 일이기 때문입니다.

 

자기가 만든 것도 아니고 남이 만든 소스 코드 내에서 사용된 자료구조나 함수의 역할 등등을 머리속에 넣고 있지 않으면 무지하게 힘들어지기 때문입니다. 영단어가 약한 사람이 영어 소설을 읽는 것 같다고나 할까요.

 

그러한 것들을 극복하기 위한 방법 중 하나로 아래에서 많은 분들이 지적하신 것처럼 "관련 지식/정보의 습득" 이라는 방법이 있습니다. 대단히 중요한 내용이지요.

 

여기에 하나 더 덧붙이고 싶다면 "직관의 획득" 을 말씀드리고 싶네요.

 

많은 사람들이 직관을 통밥이라고 이야기하면서 그 능력을 비하시키지만, 어떤 큰 일을 하기 위해서는 가장 중요한 요소라고 생각합니다.

 

그렇다면 직관은 어떻게 획득할까요. 저는 "경험이 직관을 만든다." 라는 생각을 합니다. 많은 사람들이 "경험을 통해 획득한 획일적인 사고방식이 직관을 방해할 수 있다." 라고 이야기하지만, 제 생각은 약간 틀립니다.

 

일반적인 "척 보면 아는", "척 보면 간파하는" 직관을 가지기 위해서는 "다양한 경험"이 가장 필수적인 것이라고 생각합니다.

 

제가 SI 쪽에 있어서 그런지 이쪽의 일들은 굉장히 획일적입니다. 대부분이 RAD 를 가지고 개발하며, RDB 를 사용하여 자료 처리를 수행하지요. 그러다 보니 경험이 많아지면 나름대로 SI 에 대한 직관들은 가지지만, 약간이라도 다른 요소가 섞이게 되면 직관이 아집으로 바뀌는 경우를 종종 봐 왔습니다.

 

이런 방식보다는 다양한 소프트웨어의 소스 코드를 보시는 것이 좋을 것 같습니다. 시스템이면 시스템, 그래픽이면 그래픽, 에디터면 에디터, 등등등... 요.

 

처음에는 작은 코드부터 분석하시는 게 좋을 것 같습니다. 유닉스 시스템의 ls, ps, vmstat, sysctl 등을 분석하시는 게 좋겠네요. 프로그래밍의 스타일, 테크닉, 그리고 좀 더 깊게 들어가면 시스템의 원리들도 어느 정도 보일 것 같습니다.

 

그 후 직관이 어느정도 생기면 - 통밥이 어느정도 생기면 ^^ - 중간 크기의 프로그램 또는 커널 쪽으로 분석을 하시는 것도 좋겠지요.

 

반응형

 

둘~

 

1. 조급해하지 말것.. 

소스분석이 쉬운 일이 아니라고 봅니다. 덩치가 커다랄수록 하루이틀 밤새서 가능한 일이 아닌이상 느긋한 마음을 가져야 할겁니다. 제 생각엔 어떤 소스를 완벽하게 분석하려면 그 소스를 직접 짜는 것보다 더 뛰어난 실력이 있어야 가능하며 시간은 그 소스를 직접 짜는 것보다 조금쯤 덜 걸린다.. 라고 생각합니다. 즉 소스분석이란게 쉽지 않은만큼, 분석할만한 가치가 있는 소스만 분석해라.. 라고 말하고 싶군요. 지저분하게 짰거나 구조적으로 불명확한 소스같은건 웬만하면 안들여다보는게 정신건강에 좋지 않을까..

 

2. 덩치가 크다고 주눅들지 말 것..

옛날 베이직 소스도 아니지 않습니까? 수만줄짜리 소스가 구조화되어있지 않을 리가 없습니다. 중요한 것은 그러한 구조를 파악하는 것이지 소스 한줄한줄이 어떤 의미인지를 파악하는 것은 그 다음의 일입니다.

 

3. 스타일을 파악할 것

똑같은 C언어라고 해도 짜는 사람마다 스타일이 틀립니다. 변수나 함수작명법, 소스파일을 에디팅하는 스타일, Indenting같은 기본적인 부분부터 typedef, 매크로, 유틸리티 함수, 에러처리, 헤더파일, 루프 스타일, if문에 조건거는 스타일, 함수 하나당 대충 어느정도의 일을 처리하는가.. 기타등등 그 사람의 스타일을 이해하면 소스를 한층 빨리 읽을 수 있게 됩니다. 그러니까 일단 소스를 접하게 되면 이런 부분들을 유심히 관찰하는 것도 필요하다고 봅니다.

 

4. 소스의 목적을 명확히 이해할 것

분석하려는 프로그램, 또는 소스가 정확하게 어떤 일을 하는지 우선 이해하고 있지 못하다면 그야말로 삽질입니다. 주석이라던가 파일명, 함수명, 호출위치등에서 최대한 정보를 얻어내어 우선 이 소스파일은 이런이런 일을 하는구나.. 하고 예상을 해야만 합니다.

 

5. 구조를 파악할 것

뭐 쉬운 얘긴 아닙니다만.. 일단 소스파일 수준에서 파악합니다. C파일이 30-40개쯤 되면 각각의 파일들이 어떤 역할을 하는 모듈인지 파악합니다. 유틸리티 모듈인지 아니면 UI모듈인지 아니면 데이터 모듈인지 또 서로 의존적인 것끼리 묶어서 그룹화도 합니다. 헤더파일도 마찬가지입니다. 잘 모르면 최대한 가능한 범위내에서 가정하고 들어갑니다.

그리고 나서 파일내부를 들여다봅니다..

 

6. 자료구조를 파악할 것

함수는 어차피 블랙박스라고 배우지 않았습니까? 한줄한줄 코드의 분석은 의미가 없고 함수단위로 '이 함수는 이런 일을 한다' 정도만 이해하고 있으면 됩니다. (물론 구조적이지 않은 소스라면 이런 말은 모두 무의미해집니다..)

그보다는 자료구조를 파악해야합니다. 물론 자세한 주석도 없는 상황에서 변수명과 데이타타입만 가지고 자료구조를 정확히 파악하기는 무리일 수도 있습니다만 코드를 들여다보기 전에 변수정의, 특히 C의 경우 전역변수 정의는 철저하게 들여다보고 들어가야만 합니다.

 

7. 배경지식을 갖출 것

말그대로입니다.. 만약 정렬이라던가 검색같은데 특정 알고리즘을 사용했다면 그 알고리즘을 모르는 상태에선 삽질이 될겁니다. 세마포를 썼다면 세마포를 우선 알고 있어야 합니다. FTP프로그램이라면 FTP프로토콜 및 작동원리에 대해 충분히 이해하고 있어야만 합니다. 그 소스를 작성하는데 필요한 충분한 배경지식이 없다면 분석은 더더욱 요원한 일입니다. 다시 말씀드리지만 어떤 소스를 분석하려면 그 소스를 작성하는 것보다도 더욱 뛰어난 실력이 있어야만 가능하다고 생각합니다. 만약 공부를 목적으로 소스를 분석한다면, 즉 자신이 짤 수 없는 소스를 분석하려고 든다면 짜는 것보다도 더 많은 시간이 필요할겁니다.

 

개인적으로.. 공부를 목적으로 분석을 한다.. 라는 것은 별로 바람직하지 않다고 봅니다. 예를 들면 GIF파일을 사용하는 방법을 공부하고 싶다고 해서 GIF.C를 어디서 구해다가 분석을 한다면.. 그건 좋지않습니다. GIF파일의 구조도 압축알고리즘도 정확히 이해못한 상황에서 소스코드만 들여다본다고 이해할 수 있을리가 없습니다. 정리된 문서나 책을 통해 공부를 하는 것이 훨씬 낫죠.

다만 큰 프로그램을 분석해보면 "이렇게 짜는거구나", "이렇게 구조화시키는거구나"하고 규모가 큰 프로그램을 작성하는 방법에 대해 느낄 수는 있다고 봅니다.

 

글 일부 출처 : 출처: http://kldp.org/node/67385#comment-295224  - 소스코드 분석의 왕도

 

 

 

 

셋~

 

저 같은 어떤 소소를 분석한다고 맘을 먹으면, 모조리 프린트 합니다.

그리고 무작정 끝까지 한번씩 훑어 봅니다. 그러면, 대충 어떤 함수들이 중요한지 알게 되더군요. 형광펜은 필수^^

그리고는, 그 중요 함수를 중심으로 흐름을 파악할려고 합니다. 즉 알고리즘을 파악하죠. 

여기까지 하면, 소스 코드의 90% 를 파악됐다고 생각합니다.

그리고는, 그 알고리즘을 제가 알고 있는 랭귀지로 구현합니다.

(일일이 소스를 한줄 한줄 뜯어 볼필요는 없습니다.

제 경험상 대부분 core 부분은 얼마 안됩니다.)

프로그래머가 자기 실력을 늘리는데, 남의 소스를 뜯어보는것 만큼 좋은건 없다고 봅니다.

 

정말이지 모방은 창조의 어머니란게 이런데에 들어맞는게 아닐까요?

 

출처 : http://kldp.org/node/67385#comment-295224