Heart’s Develop Inside

내가 요즘 자주 다루고 있는 프로그램들은 회사 내에서는 꽤 오랜 역사(?)를 가지고 있는 프로그램들이다.
솔루션의 메인 어플리케이션인데, 오랜 역사를 가지고 있는 만큼 많은 사람이 손 댄 흔적이 소스에 남아 있다.
무슨 뜻일까?
음… ‘인수인계’ 라는 것을 받아 본 사람들은 무슨 이야기를 하려던 건지 아마 알 것이다.

아무튼, 그 오랜 역사를 남의 손에서 뒹굴다가 내 손으로 들어온 친구들(?)은 솔직히 내가 설계부터 구현, 테스트, 구축까지 참여한 어플리케이션들보다 더 정감이 갈 수는 없겠지만, 어쨌던 내 일이니까 군말 없이 작업하고 있다.
(울고싶다 ㅜ.ㅜ)

특히 회사 솔루션 전략(특성?) 상 사이트 별로 커스터마이즈가 꽤 많다.
사이트 커스터마이즈가 있을 때 마다 소박하지만 나름 심각한 고민을 하게 된다.
이걸 전처리기 & Conf. 로 추가/수정을 해야 할 지, 아니면 새로운 프로젝트로 분화시킬지…

입사 초기에는 소스가 깔끔한 쪽이 낫지 않을까 싶어 조금 복잡하게 커스터마이즈되는 경우(기존 소스와 뒤섞이는 경우)에는 새로운 프로젝트로 만드는 방법을 써 왔고, 그 때는 나름 괜찮은 판단인 듯 보였다.

하지만, 원본 소스 자체가 개선의 여지가 많은 프로젝트였기에 시간이 갈 수록 원본 프로젝트와 분화한 프로젝트의 갭이 커져만 갔다. 대부분의 버그 패치는 원본 프로젝트에만 이루어졌다. 한번 두번 그렇게 지나가다 보니 원본 프로젝트에서 버그가 발견된 것이 분화한 프로젝트에서도 동일하게 일어난다는 보장이 없을 정도가 되었다.

그래서, 요즘은 쪼개진 프로젝트들을 다시 하나의 프로젝트로 묶고 있다. 리소스도 ‘#undef 와 #define 으로 리소스 번호 바꿔치기’ 를 통해 합치고 있다. 소스 코드는 전처리기 & Conf.로 거의 점령된 상태이지만, 일단 일관된 관리는 확보했다.

이제 전처리기 & Conf. 가 점령하고 있는 소스들을 재정리해 줄 멋들어진 방법을 찾아 머리를 굴려보고 있는데, 실력이 부족한 탓인지 그다지 생각이 나진 않는다. 커스터마이즈용 커스텀 클래스를 만들까 싶은데 커스터마이즈 자체가 일관성이 그다지 없다 보니 잘 될까 의문이다. 아무튼 계속 생각해 봐야 겠다.

리팩토링의 중요성을 몸으로 실감하는 중이다. 음… 리팩토링도 난잡한 코드 앞에서는 무릎을 꿇을라나?
TDD, CI 등이 적용된 프로그램에서 고생 없이 일하고 싶다. 그 전에 내가 실력을 키워야겠지.