쓰는 것 보다 읽는 게 어려운 것 - Code

무언가를 새롭게 만들어 낸다는 것은, 무엇이 되었든 분명 어려운 일이겠지요. 글을 쓸 때도, 프로그래밍을 할 때도, 창조적인 작업이란건 역시나 시간과 노력이 들어갈 수 밖에 없다는 생각듭니다.

그런데, 때로는 새로이 만들어 내는 것보다도, 남이 만들어 놓은 걸을 이해하는게 더 어려울 때가 있다는 것을, 최근에 회사에서 소스 코드를 들여다 보면서 느꼈습니다.

솔직히 자신이 작성한 코드도 시간이 지나서 다시 들여다 보면 잘 이해를 못할 때가 있습니다. 하물려 남이 만들어 놓은 것을 이해하기란... 물론 이걸 이제와서 깨달은 건 아니지만, 막상 본격적으로 덩치큰 소스를 살펴보게 되니까 생각만큼 만만한게 아니더군요.

일단 코드 자체가 정리가 잘 안되어 있었습니다. 간단히 말하자면, 군데군데 지저분한 코드들이 보인다는 것입니다. 이걸 보면서 마음속으로는 이렇게 한마디 했습니다.

"리팩토링 좀 하지..."

코드가 정리가 안되어 있으니, 그냥 눈으로 읽어나가는 것 조차도 슬쩍 신경이 거슬리더군요.

분명 소스 코드라는 것은 프로그램을 동작시키기 위한 것이고, 컴파일러가 알아 먹을 수 있는 언어로 적어놓은 것이지만, 그에 못지않게, 아니 사실 그보다도 더 중요한 것은, 결국은 인간이 알아먹을 수 있어야 한다고 생각합니다.

그런데 막상 코딩에 들어가면, 우선 잘 동작해야 한다는 생각이 앞서게 되는 것이 또한 현실이랄까요. 그러다 보면 보기 좋은 코드라는 것은 뒷전으로 밀려나기 마련이죠. 덤으로 일정까지 빠듯하다면야 더 말할 것도 없겠구요.

그래도 제발 나중을 생각해서라도 알아볼 수 있게 정리좀 했으면 합니다. 빈줄하나 없이 빽빽하게 20줄 이상이나 되는 코드 덩어리를 가진 메서드를 보고 있자면 참 기운이 빠집니다.

메서드의 길이가 길어졌다는 것은 한 메서드가 여러가지 책임을 떠맡고 있다는 징조입니다. 이런건 간단히 2, 3개의 메서드로 쪼개 주는 것만으로도 좀 더 보기 좋게 만들 수 있는 건데... 메서드 호출을 한두번 아낀다고 속도가 체감적으로 빨라지는 것도 아니고, 예초에 객체지향 언어를 쓰는게 성능을 적당히 희생해서라도 관리하기 편한 코드를 만들어 내는 데 있는거 아닙니까...


그리고 또 한가지 느낀 점은, 소스 코드는 절대로 문서가 될 수 없다는 사실입니다. 제가 소스를 분석할 때 가장 어렵게 느껴지는 것은, 객체들간의 관계나 상호작용을 이해하기가 어렵다는 것입니다. 정말 이럴때 UML 이라도 하나 그려져 있다면 훨씬 이해하기가 쉽겠구나하는 생각이 들었습니다. 만일 개발툴에서 코드를 바탕으로 UML을 자동으로 그려주는 시각화 도구가 지원된다면 더욱 좋겠지요.

문서상에서 간단히 훑어보면 알 수 있는 것도, 소스를 분석해서 이해하려면 제법 시간이 필요합니다. 원활한 인수인계를 위해서도 뭔가 문서적인 정리를 해놓은 것은 필요하다는 생각이 들었습니다.