3일에 걸친 리펙토링을 하고나서, 코드를 잘 작성하는 법에 대해 생각해봤다.

NVR/DVR에 저장되어있는 기록을 검색해서, 리스트 형태로 보여주는 UI에 추가기능을 구현해야했다. 전임자는 MFC를 이용해서 윈도우 프로그래밍을 하던 사람으로, 팀 내에 안드로이드 개발자가 관두게 되면서 잠시 땜빵식으로 일을 맡게 됐다고 한다. 안드로이드를 하던 사람은 커녕, 자바를 쓰던 사람도 아니었기 때문에 코드를 열어보기 전까지 어느정도의 각오는 되어 있었다.

 

하지만 현실은 생각보다 더 처참했다. channel이라는 변수명을 입력하다가 자동완성이 되지 않아서 다시 확인해보니, 해당 클래스 내 전체에서 chennel이라고 오타가 난 변수명을 그대로 사용하고 있는 것(심지어 참조하는 부분도 꽤 있었다.)은 애교. 버튼을 선택했을 때는 #ffffff로, 선택되지 않았을 때 #000000로 변경해주는 코드는 버튼마다 하드코딩되어 있었다. '전체 카테고리 선택'이라는 버튼과 '하위 카테고리 버튼'들이 있을 때, 선택된 '하위 카테고리 버튼'의 갯수를 카운트해서 전체 선택인지 아닌지를 검사하고 있었다. 게다가 변수명의 컨벤션도 굉장히 제멋대로였으며, 연관된 UI의 변수명에 이렇다 할만한 연관성도 없었다. pButtonCh라는 이름의 파라메터를 받고 있기에 당연히 채널과 관련된 메소드겠거니, 하고 코드를 따라가다가 이벤트와 관련된 메소드라는 걸 깨닳았을때도 적잖게 당황했다.

 

당연히 버그가 존재했었는데, 간단한 버그같아서 수정하려고 하니 도무지 코드를 따라갈 수가 없었다. 결국 기능 추가고 뭐고 코드를 전부 뜯어고치기 시작했다. 우선은 통일되지 않은 컨벤션부터, 카멜 케이스로 변경하기 시작했다. 코드를 리펙토링하기 시작하니 조금씩 무슨 기능을 하는 함수인지 파악이 되기 시작했고, 함수의 이름을 적절하게 변경했다. 예를 들면 setChannel이라고 명명되어있고 실제로는 인자로 전달된 채널 버튼에게 이벤트 리스너를 등록해주는 기능을 하는 메서드에게는, setChannelButtonEventListener라고 지어주는 식으로. xml에서 사용하고 있는 id중에서 Linear Layout인지, Relative Layout인지 코드상에서는 중요하지 않음에도 불구하고, 굳이 linear나 relative가 들어간 변수명도 변경했다.

 

리펙토링을 진행하면 진행할수록 커다란 카테고리가 있고, 그 하위 카테고리에 변수와 함수가 종속되는 형태로 쓰이고 있다는 걸 파악할 수 있었다. 예를 들어 화면 분석이라는 기능의 하위에는 물체 감지라는 기능이 있고, 그 하위에는 사람, 자동차, 동물등이 있는 식으로. 비록 변수명은 길어지지만 화면분석_물체감지_사람, 화면분석_물체감지_자동차, 화면분석_물체감지_동물과 같은 식으로 변경했다.(변수는 카멜케이스로 작성했지만, 한글에는 대소문자가 없기에 예시는 스네이크 컨벤션으로 작성한다.) 자동완성 기능이 있으니 변수명이 길어지는 건 크게 문제되지 않았고, 오히려 코드를 타이핑할 때 상위 카테고리를 입력하면 연관된 하위카테고리가 리스트로 출력됐다. 물론 이게 정답이라고는 생각하지 않지만, 이전보다 유지보수하기 편해졌다는 건 분명했다.

 

위와같이 코드를 3일간 뜯어고치고나서 SVN을 확인해보니, 약 50%정도의 코드가 대체되어있었다. 남아있는 코드는 아직까지 건드리지 않은 기능과, 공백 정도. 결과적으로 좋은 코드를 작성하는 법 중 하나는, 코드를 타이핑하면서 이전에 작성한 변수와 함수명을 연상할 수 있는 코드가 아닐까싶었다. 내 경우에는 큰 카테고리를 잡고 하위 카테고리로 점점 파고들어가는 식이었고, 변수명/함수명이 길어진다는 단점이 있기는 했지만 이전보다는(물론 이전이 너무 엉망이었기 때문에 가능한 일이었지만) 훨씬 보기 편한 변수명/함수명을 작성할 수 있었다.

 

이번에 리팩토링 작업을 하면서 안드로이드 스튜디오의 리펙토링 기능을 너무 유용하게 써서, 나중에 기회가 된다면 인텔리J를 써볼까 하는 생각도 들었다. 뭐, 그 전에 VS Code에 동일한 기능을 수행해주는 플러그인이 있는지부터 찾아봐야겠지만 말이다.