코드 읽기에 대해서

문득 코드를 작성하던 중 이런 생각이 들었다.

"과연 지금 내가 작성한 이 코드가 분석하기 쉬운 코드일까?"

생각해보면 아마추어 일때를 제외하고는 새 코드 작성보다 다른 사람의 코드 분석하는 시간이 더 잦았고, 새 코드를 작성하더라도 다른 코드와 어울려야 했기 때문에 코드 분석은 늘 필요했다.

심지어 내 코드를 분석해야 되는 일도 잦았다. 기억력에는 한계가 있고, 시스템의 전체적인 이해도는 높을 수록 좋겠지만 세세한 코드 하나 하나가 하는 일까지 외울 필요는 없다고 생각한다.

그렇기에 내 코드를 내가 몇달이 지나고, 심지어 몇년 후에 봤을 때도 읽기 쉽고 유지보수하기 쉬운 코드를 만들기 위해 노력해야 한다.

그래서 우리는 디자인 패턴, 리팩토링 등을 통해서 좋은 코드를 만들기 위해 노력하고, 표기 법을 만들었으며, 코딩 규약도 만들었다.

그런데 왜 코드 읽는 법에 대한 논의는 없을까?
코드를 잘 "작성"하는 것과, 코드를 잘 "읽는" 것과는 엄연히 다르다.

그런데 많은 사람들이 코드를 잘 작성하는 사람이 코드를 잘 읽을 것이라고 생각한다.
과연 그럴까?

분명히 좋은 코드가 무엇인지 이해하고 있는 사람은, 그렇지 않은 사람보다 코드를 잘 읽을 것이다.

코드 읽기와, 코드 작성은 별개로 보아야 한다. 또한 코드 읽기를 잘하기 위해선 단순한 코드 작성이 아닌, 유지보수하기 쉬운 코드 작성이 되어야한다.

좋은 코드가 무엇인지 이해하려면 경험이 필요하고, 그런 경험을 해오며 코드 읽기에 대한 노하우도 쌓였을 것이라 이미 코드 읽기에 대한 노하우가 있을 것이다.

그렇지 않은 사람들은 코드 읽기를 어떻게 해야 할까?

내가 생각하는 코드 읽기 방법이다.

1. 특정 클래스를 따로 떼어내서 사용해본다. 
만약 해당 클래스가 다른 클래스와의 결합도가 높다면, 별개의 모듈로 동작할 수 있도록 해체 작업을 해본다. 실패하더라도 그 과정에서 해당 모듈에 대한 이해도가 높아졌을 것이다.

2. 이미 완성된 프로그램을 돌려본다. 그리고 디버깅을 통해서 해당 코드가, 프로그램에 어떤 영향을 주는지 살펴본다.
 이 방법의 단점은, 나무는 볼 수 있지만 숲을 볼 수는 없다는 것이다.

3. UML등을 이용해서, 클래스 구조도를 그려본다.
그리고 각 클래스 별로 따로 분석한다. 1번과 2번 방법을 적절히 사용하면, 코드 분석이 좀 더 이로울 것이다.

이 글이 이제 갓 프로그래밍을 시작한 초보 개발자나, 코드 작성은 자신 있지만, 아직 다른 사람의 코드를 분석하고 수정하는 것은 어렵기만한 분들에게 코드 읽기에 대한 도움이 될 수 있는 글이 되었으면 좋겠다.