처음 개발자로서 일할때는 모든 프로젝트가 정말 바닥부터 코딩을 했다. 한마디로 main으로 코딩을 시작했다. 이런 코딩은 아주 재밌다. 내가 모든 것을 지배하니까..
그런 즐거움도 잠시 대기업이 들어간 이후 부터 지금까지 남들이 짜 놓은 방대한 코드에 뭔가 기능을 구현해야했다. 이때 부터 본격적인 코드 읽기가 시작되었다. 방대한 코드를 이해하는 것은 쉽지 않다. 그냥 코드만 읽어서는 절대 이해할 수 없는 것이 코드 읽기다. 오죽하면 이런 책도 있다. 그래서 지금까지 경험한 것을 잠깐 공유하려고 한다.
1.gdb로 step into를 통해 프로그램 동작을 이해한다.
call graph를 복사해 놓고 sequence diagram을 그려 놓으면 좋다. 이것을 바탕으로 class diagram을 그려놓고 프로그램 전체 구조를 이해한다. 그리고 layered architeture diagram을 그려 놓는 것도 좋다.
2. 버그를 잡는다.
오픈소스인 경우 버그를 잡아본다. 그러면서 코드를 이해한다. 버그를 잡은 경우에는 어떻게 잡았는지 잘 문서화 해 놓는다. 이렇게 여러군데 버그를 잡다보면 부분 부분 이해가 늘어나고 어느새 전체 구조를 이해하게된다.
3. 기존 문서나 비디오 등을 꼭 본다.
기존 개발자가 만들어 놓은 기술 문서, 기술 토크 비디오를 찾아서 질리도록 본다. 사실 코드가 자주 바뀌지만, 대부분 문서를 아주 자세한 경우가 드물기 때문에 좀 오래된 문서들도 도움이 된다.
4. 프로젝트내에 있는 작은 데모, 테스트케이스 코드를 본다.
이들 프로그램은 꼭 필요한 코드만 담겨져 있어서 이해가 쉽다.
5. Design Pattern에 익숙해진다.
많은 프로젝트가 익숙한 Design Pattern을 사용한다. 디자인 패턴에 익숙할 수록 코드 이해가 빠르다.
6. Concurrent programming, IPC에 익숙해진다.
Chromium이 Multiple Process Model을 도입한 이후, 프로그램 동작을 이해하기가 까다로워졌다.
7. API에 익숙해진다.
당연한 이야기지만, 윈도면 윈도 API, 유닉스면 POSIX API에 익숙해져야 한다..
8. Domain knowledge에 익숙해진다.
웹브라우저를 개발한다면, 웹기술에 익숙해져야 하듯이, 게임을 만든다면, 게임 자체를 이해해야 한다.
9. Refactoring을 해본다.
한동안 Blink Editing component을 기여한적이 있었다. Chromium 코드 가운데 복잡하기로 악명 높은 코드다. 여러 사람이 개발을 했고 Editing API가 표준화가 덜 된 탓도 있다. 어찌되었던 이런 시도는 코드 건강에 좋다.
지금 끝도 없는 방대한 코드를 보려다가, 그냥 두서 없이 정리해보았다. 자 이렇게 남의 코드를 볼 노력으로 그냥 나만의 프로그램을 만들자. ㅎㅎ
참고로 읽어본 글
댓글 없음:
댓글 쓰기