[2023년 4월 회고] - 리팩토링, 너무 어려운

 리팩토링, 디자인 패턴, 테스트 코드 등 개발자라면 어디선가 메아리처럼 들려오고 적용하고 싶고 그렇지만 힘들기도 한 그런 것들 입니다. 핑계 같지만, SI 프로젝트를 처음 TDD로 진행했을 때 실시간으로(프로젝트 마감 1일 전에도) 바뀌는 기획에 하나 둘 씩 추가되는 DB Column들과 그 때 마다 TestCode를 변경해야하는 번거로움으로 인해 첫 번 째 도전은 너무도 쉽게 실패로 끝났습니다.

 

 그리고 리팩토링, 프로젝트가 끝나고 리팩토링 할 때, 그리고 이미 개발된 기능의 기획 변경이 있을 때 혹은 복잡한 경우의 수가 있을 대 테스트 코드를 활용하여 잘 마무리 지었을 때는 조금 자신감도 붙었습니다.

 

 예전에 내가 작성한 소스코드를 보면, 비대해진 BaseClass와 이를 상속 받았지만 제대로 부모 클래스의 기능을 활용하지 못하는 서브 클래스들이 눈에 띕니다. 처음 개발 했을 때는 간결하게 잘 짰다고 생각했던 소스코드가 이런 저런 수정을 거치면서 너무도 비대해졌음을 알게 되었습니다. 그리고 '바빠서', '일정을 맞춰야해서' 라는 핑계를 대며 크기를 더 키워나간 흔적들이 고스란히 commit log에 남아있고, TODO: 리팩토링 .... 또한 쉽게 볼 수 있었습니다.

 

 Pythonic한 코드 작성과 디자인 패턴, 비대해진 코드를 조각내고 SOLID 법칙을 잘 준수하며 목적에 적합한 디자인 패턴을 잘 적용하고 테스트 코드로 감싸서 완성하고 싶습니다. 아마, 회사의 백엔드 개발자 동료들은 모두 저와 같은 생각일 것 입니다. 그래서 서로 스터디도 하고 신규 프로젝트를 대비해서 예상되는 큰 기능들은 PoC 수준으로 미리 개발 해보며 테스트 코드 작성 할 시간을 벌어보려 하는 공감대가 있는 것 같아 힘이 납니다.

 

 5월에는 4월에 했던 준비와 동료들과 함께한 테스트 코드 스터디가 빛을 발할 수 있으면 좋겠습니다.