리팩터링을 할 것인가, 새로 작성할 것인가를 결정하는 방법
모든 개발자는 이런 순간을 마주합니다.
코드베이스가 느려집니다. 기능을 추가하는 데 너무 오래 걸립니다. 신규 입사자들이 시스템을 이해하는 데 어려움을 겪습니다. 결국 누군가가 전체를 새로 작성하자고 제안합니다.
팀은 보통 두 그룹으로 나뉩니다. 한 그룹은 처음부터 다시 시작하고 싶어 합니다. 다른 그룹은 과거의 재작성(rewrite)이 실패했던 경험을 두려워합니다. 양측 모두 일리가 있는 주장입니다.
재작성은 마법 같은 해결책이 아닙니다. 계획보다 오래 걸리는 경우가 많습니다. 결국 두 개의 시스템을 동시에 유지 관리해야 하는 상황에 처하게 됩니다. 심지어 새 버전에서도 똑같은 실수를 반복할 수도 있습니다.
재작성이 의미 있는 경우는 다음과 같습니다:
• 데이터 모델이 비즈니스에 근본적으로 맞지 않을 때. • 기술이 사장되어 보안 업데이트가 지원되지 않을 때. • 비즈니스 요구사항이 너무 많이 변해서 기존 시스템이 쓸모없어졌을 때. • 현재 팀원 중 아무도 시스템이 어떻게 작동하는지 이해하지 못할 때.
그렇다 하더라도, 한꺼번에 모든 것을 바꾸는 '빅뱅 방식(big bang replacement)'은 피하십시오. 스트랭글러 피그 패턴(strangler fig pattern)을 사용하세요. 기존 시스템과 병행하며 새 시스템을 하나씩 구축해 나가야 합니다.
대부분의 경우, 실제로 필요한 것은 리팩터링입니다.
리팩터링이 올바른 선택인 경우는 다음과 같습니다:
• 속도는 느리더라도 여전히 기능을 추가할 수 있을 때. • 팀이 현재 코드를 이해하고 있을 때. • 문제가 특정 모듈에 국한되어 있을 때. • 비즈니스 상황상 새로운 기능 출시를 멈출 수 없을 때.
선택하기 전에, 코드가 왜 나빠졌는지 자문해 보십시오.
만약 문제가 기술 부채라면, 가장 심각한 부분부터 리팩터링하십시오. 만약 문제가 코드 리뷰의 부재나 좋지 않은 문화 때문이라면, 재작성은 도움이 되지 않습니다. 똑같은 나쁜 습관을 가진 채 새로운 난장판을 만들 뿐입니다.
결정하기 전에 다음 질문들을 던져보십시오:
• 가장 심각한 부분들을 독립적으로 수정할 수 있는가? • 데이터 모델이 현재의 비즈니스 요구사항에 맞지 않는가? • 처음부터 다시 시작한다면 어떤 지식을 잃게 되는가? • 비즈니스가 긴 전환 과정을 견딜 만큼 안정적인가?
새로 시작하는 것은 기분이 좋습니다. 하지만 재작성을 끝마치는 것은 매우 어려운 일입니다. 대부분의 경우, 구조화된 리팩터링 계획을 세우는 것이 더 안전하고 효과적입니다.
출처: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk