단순히 일회성으로 만들어서 돌리고 버릴 코드는, 유지보수가 가능한지 여부는 크게 중요하지 않습니다. Python 2를 사용하는 것조차 크게 상관 없습니다. 단순히 돌아가기만 하면 되기 때문입니다. 당장의 니즈만 만족하면 됩니다.
앞으로 몇 년 이상 살아남을 것이 예상되는 상용 서비스의 코드를 만든다면, 유지보수가 가능하도록 작성해야 합니다. 오늘 작성한 코드는 1년 후, 2년 후에도 살아남아서 기능을 추가하거나 버그를 수정해야 할 수 있기 때문입니다. 코드를 잘 작성하는 것은 작성자 본인의 평판을 위해서라도 중요한 일입니다. 코드를 작성한 사람이 퇴사하면 유지보수하는 사람이 달라집니다. 작성한 코드는 본인의 꼬리표가 되어 곧 평판이 됩니다. 코드를 기가 막히게 잘 짜시던 분은 이직하고 수 년이 지난 시점까지도 후임자들에게 칭찬이 자자합니다. 안타까운 경우이지만, 반대의 경우도 보았습니다.
피플펀드컴퍼니의 개발자 채용 공고에도 공개되어 있듯이, 사업 구조 특성 상 레거시 시스템이 아예 없기는 어렵습니다.
# 피플펀드에서 소프트웨어 엔지니어로서 일하는 것의 특징
제품, 프로세스, 팀의 구성 등 모든 면에서 상상하시는 것보다 갖추어지지 않은 것이 많으며, 스스로 만들어나가야 합니다.
최초 런칭 후 수 년이 흘렀으나 제품의 품질보다 속도를 더 우선적인 가치로 두고 개발했던 시기의 레거시 코드가 아직도 많이 남아있으며, 새로운 기능을 제작할 때 항상 기존 코드의 개선 작업을 병행해야합니다.
금융당국의 정책 변화에 따라 제품의 큰 방향이 수정되는 일이 종종 벌어집니다.
시장 상황에 따라 사업적 우선순위를 끊임없이 수정하지만 비전은 바뀌지 않습니다.피플펀드컴퍼니에서 백엔드 개발자로 일하면서, 비즈니스 요구 사항을 충족시키기 위해 수많은 기능을 추가함과 동시에 수많은 레거시 코드를 개선했습니다. 대부분 리팩토링 하는 선에서 끝났지만, 2.0도 몇 번 진행하면서 전체 모듈을 재작성하기도 하였습니다. 그 과정에서 어떤 코드가 나쁜 코드인지를 깨달았습니다. 드디어 Code smell를 맡을 수 있게 되었습니다. 나쁜 코드를 좋은 코드로 리팩토링하고 재작성할 수 있게 되었습니다. 더불어, 좋은 코드를 작성하는 방법을 터득했습니다.
지키려고 노력하는 것들을 적어 보았습니다. 이력서 상의 “쉽게 부서지지 않으며 확장성 있는 코드를 작성하기 위해 치열하게 고민합니다.” 의 내용들이기도 합니다.
- 함수명과 변수명을 의미 있게 만듭니다.
aaa,h와 같은 네이밍을 지양하고,validate_email_address과 같은 네이밍을 지향합니다. 언어나 라이브러리의 표준 컨벤션이 있다면 이를 따릅니다. 컨벤션을 따르지 않으면 가독성이 떨어지고 심지어는 개발 툴이 오작동하여 개발자의 생산성을 떨어뜨릴 수 있습니다. - 함수를 적정한 선에서 잘게 쪼갭니다. 하나의 함수가 되도록 20줄을 넘어가지 않도록 합니다. 함수의 이름을 지을 때
and가 들어간다면, 여러 개의 함수로 쪼갤 수 있다는 신호입니다. while True:와 같은 무한 루프를 돌아가는 데몬 프로세스가 필요하다면, 하단의 코드는 별도의 함수로 쪼갭니다.- 비즈니스 로직은 순수 함수로 만듭니다. 데이터베이스나
global변수에 의존하지 않도록 합니다. - 유닛 테스트와 통합 테스트를 구분하여 사용합니다. 함수를 테스트할 때는 유닛 테스트로 작성합니다. 모든 테스트가 통합 테스트로 작성되면, 로직을 조금 수정했는데 관련된 테스트가 몽땅 깨져서 모든 테스트를 수정해야 하는, 배보다 배꼽이 더 커지는 주객전도의 상황이 될 수 있습니다.
- 호출하는 곳이 없는 함수는 삭제합니다.
if False:와 같은 Unreachable한 코드도 삭제합니다. 주석 처리한 코드도 삭제합니다. 불필요한 예외 처리도 삭제합니다. 어차피 모든 삭제 이력은 Git에 남습니다. 정말 필요한 핵심 코드와 실제로 발생하는 핵심 예외 처리만 남겨둡니다. - Early Return를 적극적으로 활용하고 함수를 잘게 쪼개서 Indent를 줄입니다. 언어를 불문하고 Indent가 많아지면 코드의 가독성이 현저하게 떨어집니다.
The only way to go fast, is to go well. - Uncle Bob
빨리 가는 유일한 방법은 제대로 가는 것이다. - 엉클 밥
처음부터 깨끗하게 작성해야 빠르게 개발하고, 유지보수의 비용이 현저하게 줄어듭니다. 적은 코드 라인의 수정으로도 기능을 추가하고 버그를 수정할 수 있습니다. 제가 1년차일 때 만들었던, 현 회사의 퇴사와 함께 서비스를 종료한 프리페이 서비스는, Django의 베스트 프랙티스를 따라 깨끗하게 만들었음에도 git init 부터 단 20일 만에 서비스를 런칭할 수 있었습니다. 작성한지 2년이 지난 지금, 마지막을 알리는 공지를 올리기 위해 오랜만에 소스 코드를 열었는데, 여전히 참 잘 만들었다는 생각을 했습니다. 해당 서비스의 코드를 외부에 공개할 수 없는 것이 그저 아쉬울 따름입니다.
관련 글: