JUnit을 이용한 코드 개선 과정 녹화
인간의 피조물인 코드는 마치 인간이 그러하듯 수명이 있다. 그뿐만 아니라 조금만 유연하게 생각하면 코드의 건강을 이야기할 수 있다. 수정이 쉬운 코드가 건강하다면, 그렇지 않은 코드는 건강하지 않다. 코드를 건강하게 유지하기 위해서는 늘 최근 상황을 반영해야 한다. 그리고 불필요한 내용은 가지치기를 통해 썩는 일을 막는다. 코드를 건강하게 유지하는 방법은 여러 가지가 있겠지만, JUnit을 통한 자동화 테스트를 이용하는 방법을 공유한다. 테스트 코드를 통해 레거시(legacy)라 불리는 기존 코드를 배우고 정리하며 개선한다. JUnit 덕분에 우리는 결과물뿐 아니라 과정까지 재생할 수 있다. 놀랍게도 테스트 과정이 바로 녹화과정이었다.
개발자에게 미치는 복잡다단한 변화는 코드에도 드러나기 마련이다. 사용자가 새로운 기능을 요구하면, 개발자는 코드를 수정해야 한다. 개발자가 새로운 삶을 찾아 떠나거나 조직의 변화에 의해 자리를 옮겼다면 다른 사람의 손에 코드가 넘어간다. 코드를 너무나 아껴서 영화 ‘엽기적인 그녀’에서처럼 코드의 새 주인에게 소상하게 설명해주었다면 좋겠지만, 마음은 있어도 시간이 없어 많은 코드를 일일이 설명해주지 못한다. 결과적으로 자세한 사연을 알 수 없는 코드가 서버에 올라가 많은 사용자에게 서비스를 제공하는 상황이라면, 무작정 코드를 바꾸거나 제거할 수 없는 일이다. 또, 완벽한 코드 작성에 대한 필요성을 느끼지 못해 기능 구현만 마치면 코드를 완전하지 못한 상태로 두고, 다른 삶을 누리기도 한다. 외주 개발 결과물을 받는 경우라면 익숙해지는 데 필요한 시간은 더 길어져 불완전한 인수인계가 빈번하게 발생한다. 사실 현장을 둘러보면 배경지식이 부족한 개발자나 안타깝게도 자기 일에 자부심을 느끼지 못하고 마지못해 일하는 개발자를 볼 수 있다.
이 글은 예제 하나 달랑 받아 고전하면서 개발했던 과정을 고스란히 물려주지 않기 위한 기록이다. 아직 비슷한 경험을 하는 개발자가 많다는 사실을 알기에 딱 한 분의 독자라도 자신의 코드를 건강하게 만드는데 이바지할 수 있기를 기대하며 글을 쓴다.
예제파일 하나로 시작하기
입사하자마자 혹은 생소한 곳에서 하는 프로젝트에서 프로그램을 작성한다고 가정해보자. 딸랑 예제 파일 하나 던져주며 새로운 프로그램을 개발하라는 지시를 받았다. 사실, 예제를 따라 하는 방식이 프로그램을 가장 빨리 작성하는 방법이기는 하다. 하지만, 예제를 보고 따라 하는 식으로 완벽한 프로그램을 작성할 수는 없다. 설사 예제를 응용해 원하는 기능을 뚝딱 만들었다고 해도 가까운 미래에 장애나 예외 상황을 처리하느라 훨씬 긴 시간을 보내곤 한다. 미리 생각지 못한 예외 상황일수록 대응에는 훨씬 긴 시간이 필요하다.
구체적인 사례를 보여주기 위해 EAI(Enterprise Application Integration) 서버를 통해 다른 시스템이 제공하는 서비스를 호출하는 프로그램 작성 상황을 가정한다. 어느 날 상관이 EAI 서버를 통해 다른 시스템이 제공하는 서비스를 호출하는 코드를 던져주며 새로운 기능을 하는 프로그램을 추가하라고 한다. 예제는 정상적인 상황을 위한 코드 작성에는 부족함이 없었다. 하지만, 오류가 발생하면 원인을 알기 어려웠다. 메소드 시그니처(method signature)를 보면 인자가 매우 많은데 예제 코드에서 사용한 인자는 두세 개를 넘지 않아 어떤 인자가 필수인지 알 수가 없다. 상관을 찾아가 물었더니 예제를 만든 사람은 지금 회사에 없고, 비슷한 코드를 유지 보수하는 다른 사람을 소개했다. 인사를 나누고 예외 상황이나 예제만으로 알 수 없는 사항에 대해 질문을 했더니 매우 친절한 표정으로 ‘그건 나도 잘 몰라요.’라고 답했다. 그리고 ‘우리는 그렇게는 안 써요.’라고 덧붙였다. 어찌어찌 수소문을 해서 며칠이 걸려 문서를 구했더니 외산 솔루션 영문 매뉴얼과 현실을 반영하지 못하는 개발 초기 문서를 구할 수 있었다.
테스트를 이용한 학습 과정
필요하지도 않은 기능이나 메소드에 대한 설명으로 가득 찬 영문 매뉴얼은 진작에 던져 버렸다. 대신에 EAI 서버 개발을 완료 후에 개발업체가 건네준 문서 내용을 보며 이런저런 상황을 시험해본다. 필요한 인수를 빠뜨리면 어떤 일이 발생하는지. 유효하지 않은 값을 제공하면 어떤 일이 발생하는지 차근차근 파악을 한다. 꽤 긴 시간을 EAI 서버 API와 현재 설정상황을 이해하는데 쏟았다. 이제야 비로소 자신감을 느끼고 프로그램을 작성할 수 있다. 여기서 일을 마칠 수도 있지만, 다른 일로 바쁘다가 몇 달 후에 EAI 서비스를 이용할 일이 생기면 앞선 과정을 다시 반복하지 않을까? 잘 정리해두면 EAI를 써야 하는 다른 개발자가 하는 시행착오도 줄여줄 것 같아 문서로 정리하기로 마음먹는다.
문서를 고치려고 하다가 생각을 바꿨다. 문서로 정리한 내용도 나중에 다시 실행해서 결과를 확인해야 빨리 이해한다. 그래서, 문서 대신 JUnit 테스트케이스(Testcase)를 만들기로 한다. 테스트케이스 실행으로 확인할 수 있는 내용은 굳이 문서로 작성할 필요가 없다. 메소드와 변수 이름을 지을 때 조금만 신경 쓰면 다른 설명이 없어도 테스트 코드를 이해할 수 있다. 코드나 수행 결과만으로 알기 어려운 코드 작성 의도는 코드에 주석을 추가하여 드러낼 수 있다. 이제 그 과정을 자세히 살펴본다.
