앞으로 이곳에 채워갈 이야기
참 블로그 잘 못 쓴다. 티스토리도 찔끔. 이글루스도 찔끔.
이번엔 브런치를 써 보려는데 잘 유지하도록 함 노력해 봐야겠다.
1995년 대학원 때부터 돈 받고 개발을 하기 시작해서 지금도 가끔은 코딩(?)을 하니 20년 정도를 개발을 하고 있다. 처음 4년 정도는 Visual C++을 주로 했고, 99년 10일 이후론 Java만 한 것 같다. 가끔 ruby, python, scala 등을 공부하고 뭔가를 만들긴 했지만 역시 나의 주력은 Java인 것 같다.
처음에 Java를 사용하기 시작한 회사에는 내겐 정말 대단하게 여겨지는 선배가 계셨다. 그분을 통해 객체지향 분석/설계/프로그래밍, 디자인 패턴, 리팩토링 등을 공부하게 되었다. 그분과 같이 일하기 위해서는 그런 것들을 알아야 할 것 같았다. 디자인 패턴, 리팩토링은 학교 때는 안 배웠는데 참 재미있는 분야라고 생각되었다.
그 후 어찌어찌하다 대용량 게시판을 만들게 되었고, 최초 개발 후 5년 이상을 개선/유지보수/기능 추가 등을 하게 되었다. 이때는 Clean Code, DDD, TDD, Working Effectively with Legacy Code 등을 공부하고 현업에 적용했다. 그렇게 할 수밖에 없는 상황을 겪었다. 우리가 만든 게시판은 하나의 소스로 20여 개의 서비스에 사용되고 있었고, 서비스별로 특화된 기능을 요구했다. 버그 발생시에는 해당 버전/서비스만을 위한 핫패치가 있어야 했고, 모든 서비스에 점진적으로 적용되는 주기적 정기 배포도 있었다. 다양한 문제를 겪으면서 어떻게 하면 안정적으로 코드를 고치고, 배포할 수 있을까에 고민과 노력을 많이 했다.
Uncle Bob으로 유명한 Robert C Martin은 소프트웨어의 제1가치는 요구사항을 반영하기 위해 수정할 수 있는 것이고, 제2가치가 스펙대로 동작하는 것이라고 했다.
나는 이 의견에 매우 공감할 수밖에 없는 경험을 했다.
그래서 "읽기 쉬운 코드, 고치기 쉬운 코드, 테스트하기 쉬운 코드"를 만드는 것이 개발자의 큰 역량 중 하나라고 생각한다.
물론 요즘 많은 경우 빨리 만드는 것이 가장 중요하게 보여질 때가 많지만...
나는 이 블로그에서 빨리 개발하는 것이 아니라 읽기 쉽고, 고치기 쉽고, 테스트하기 쉬운 코드가 되도록 기존 코드를 리팩토링하는 것과 관련된 실사례 들을 정리해 보고자 한다.