2022년 스타트업을 위한 리팩토링 방법: 이유와 장단점

( Klotho 웹 사이트 에서 교차 게시됨 )

이 블로그 게시물은 시작 설정에서 코드 및 시스템을 리팩터링하는 이유에 대한 높은 수준의 개요입니다. 2022년에 고려해야 할 위험, 접근 방식 및 장단점을 다룹니다.

비용이 이익의 가치가 있는지 판단하는 방법

자신에게 정직하십시오

리팩토링에 대한 유혹은 항상 있을 것입니다. 실제 코드는 지저분하고 엔지니어는 지저분한 코드를 좋아하지 않습니다. 고객이 직접 볼 수 있는 기능에 팀이 소비하는 시간을 측정하여 리팩토링에 대한 비즈니스 사례가 있는지 확인합니다.

우리의 연구에 따르면 중간 규모 기업과 빠르게 성장하는 신생 기업은 인프라와 같은 차별화되지 않은 작업에 엔지니어링 역량의 39%를 소비합니다. 스토리를 인프라 및 리팩토링과 같은 하위 작업으로 분할하여 시간이 어디로 가는지 측정할 수 있습니다.

잘 짜여진 것은 잘 관리되고 있다

모듈 간의 명확한 경계를 통해 모듈을 더 쉽게 테스트, 배포 및 모니터링할 수 있습니다. 고객이 보고한 버그, 서비스 대기 시간 및 코드를 되돌려야 하는 빈도를 주시하십시오. 소프트웨어 수명 주기의 다른 쪽 끝에는 병목 현상이 진행되고 있다는 여러 가지 지표가 있습니다. 설계에서 배송까지 걸리는 시간, 엔지니어링 만족도 및 인프라 비용 증가 등이 모두 선행 지표가 될 수 있습니다. 빚을 졌다는 것입니다.

기업의 변곡점

코드 베이스는 팀 규모, 새로운 기능의 속도, 고객 수의 세 가지 차원으로 구성되는 경향이 있습니다. 이 숫자가 크게 변경되면 구성 요소를 분할해야 할 때일 수 있습니다.

팀을 성장시키거나 기능 개발 속도를 높이는 경우 제한 요소는 코드의 가독성입니다. 표적화된 기회주의적 리팩토링으로 시작하십시오. 고객 기반이 성장하고 있다면 더 확장 가능한 기술이나 워크플로가 필요할 수 있습니다.

할 수 있는 것은 통제하고 나머지는 계획하세요

올바른 선택은 재설계를 방해하지 않습니다.

리팩토링 및 재설계가 이전에 잘못된 선택을 했다는 의미는 아닙니다. 대부분의 경우 재구조화 이면의 원동력은 요구 사항 변경 또는 외부 요인과 관련이 있습니다. 제품 수명 기간 동안 재설계를 강제하는 최소 4가지 중요한 차원이 있습니다. 새로운 기능 개발 속도, 엔지니어링 팀 규모, 차별화되지 않은 작업에 소요되는 시간, 고객 성장입니다. 이들 각각은 직접 제어하기가 점진적으로 더 어려워집니다.

쉬운 다이얼로 시작…

네 가지 차원에서 제어하기 가장 쉬운 두 가지는 새로운 기능의 비율과 엔지니어링 팀의 규모입니다. 계획 및 우선 순위 지정에 대해 더 엄격해짐으로써 새로운 기능의 속도를 제어할 수 있습니다. 팀을 확장하는 것은 더 느린 프로세스이지만 일반적으로 적어도 계획할 수 있는 프로세스입니다.

팀과 새로운 기능의 비율이 모두 작다면 리팩토링은 비즈니스에 큰 영향을 미치지 않을 것입니다. 스펙트럼의 다른 쪽 끝에서 많은 기능을 작업하는 대규모 팀은 소규모 팀으로 재구성하는 것이 도움이 될 수 있으므로 일치하도록 코드를 리팩터링하거나 재설계하는 것을 고려해야 합니다. 보다 명확한 조직 및 코드 경계를 가능하게 하는 아키텍처를 통해 제품과 회사를 확장할 수 있습니다.

… 그런 다음 더 어려운 작업으로 이동합니다.

팀이 차별화되지 않은 작업에 소비하는 시간은 통제하기 어려울 수 있으며 고객 성장은 영향을 미치기 가장 어려운 척도입니다. 이것이 쉬웠다면 모두가 획일적인 업무를 최소화하고 고객 성장을 극대화했을 것입니다! 그래도 할 수 있습니다

리팩토링에 대한 신중하고 사전 예방적인 접근 방식으로 문제를 미리 파악하십시오.

첫 번째 단계는 리팩토링 하지 말아야 할 때를 아는 것 입니다. 고객 성장과 차별화되지 않은 작업에 소요되는 시간이 적다면 리팩토링에 시간을 소비하지 말고 영향력 있고 고객이 볼 수 있는 기능에 집중하십시오. 마찬가지로 고객 성장이 좋고 차별화되지 않은 작업량이 적다면 팀이 잘하고 있는 것입니다. 차별화되지 않은 작업의 양이 늘어나지 않도록 전술적 리팩토링을 고려하되 너무 많은 시간을 할애하지 마십시오.

팀이 차별화되지 않은 작업에 너무 많은 시간을 할애하고 있다면 현재 회사에 더 잘 맞는 아키텍처로 아키텍처를 재검토해야 할 때입니다.

고객 채택률이 낮다면 더 많은 활주로를 제공할 더 저렴한 아키텍처가 우선순위가 되어야 합니다.
고객 채택률과 팀이 차별화되지 않은 작업에 소요하는 시간이 모두 높다면 중앙 집중식의 최적화된 솔루션에 집중해야 할 때일 수 있습니다. 이것은 일반적으로 인프라 작업을 효율적으로 실행할 수 있는 전담 운영 팀의 형태를 취합니다. 이것은 큰 문제입니다. 그러니 잠시 시간을 내어 여러분과 여러분의 팀이 여기까지 온 것을 축하해 주세요!

목표를 정하고 거기에 도달하기 위한 지름길 찾기

완벽하지 않아도 계획을 세워라

아키텍처 재설계를 결정했다면 크게 생각하는 것을 두려워하지 마십시오. 엔지니어에게 원하는 최종 상태를 제시하고 필요에 따라 줄입니다. 대대적인 아키텍처 재설계의 기회는 제품 수명 주기에서 한두 번만 올 가능성이 있으므로 어떠한 타협도 감수할 준비를 하십시오. 그러나 마찬가지로 가장 잘 짜여진 계획도 구현을 시작하면 잘못될 수 있음을 아십시오.

큰 계획을 세우고 작은 조치를 취하십시오.

코드를 배치할 위치를 파악한 후에는 코드를 해당 위치에 배치하는 방법에 대해 전술적으로 결정하십시오. 한 번에 하나의 구성 요소를 작업하거나 가능한 한 서로 멀리 떨어진 구성 요소를 선택하십시오. 장치 및 시스템 수준 모두에서 견고한 테스트에 아직 투자하지 않았다면 지금이 적기입니다. 테스트는 변경 사항이 기존 고객 경험을 손상시키지 않는다는 확신을 줄 뿐만 아니라 팀이 완료에 대한 정의를 내리는 데 도움이 될 수도 있습니다. 테스트를 통과하면 구성 요소가 준비됩니다!

최고의 기술은 적응할 수 있는 기술입니다.

특히 신생 기업에 대한 리팩토링 및 재설계의 영향을 줄이는 핵심은 적응 가능한 기술을 사용하는 것입니다.

역사적으로 기업은 VM, 서버리스 또는 컨테이너와 같은 특정 기술을 선택하여 애플리케이션을 호스팅했습니다. 문제는 한 기술에서 다른 기술로 전환하는 데 엄청난 비용이 들고 오늘 필요한 것이 내일 필요한 것이 아닐 수도 있다는 것입니다.

적응형 아키텍처는 모든 기술에서 동일하게 쉽게 애플리케이션을 호스팅할 수 있는 아키텍처입니다. 이를 통해 현재 요구 사항에 맞게 호스팅 환경을 즉석에서 조정할 수 있습니다. AWS Lambda, Fargate, Kubernetes, gRPC, Linkerd, Azure/GCP와 같은 특정 기술 선택은 상호 교환 가능합니다.

적응형 아키텍처는 함수 및 이벤트 핸들러와 같은 기존 프로그래밍 언어 구조와 각 언어에 관용적인 인터페이스를 재사용함으로써 클라우드 서비스를 보다 쉽게 ​​사용할 수 있도록 합니다.

가볍지만 기술을 전환할 수 있을 만큼 충분히 유연한 추상화 및 도구를 찾으십시오. 우리는 Klotho 주석이 배포 구성에서 아키텍처의 의미론적 의미를 분리할 수 있기 때문에 청구서에 적합하다고 생각합니다. 그러나 런타임 라이브러리 및 인프라 자동화에 대한 충분한 투자로 유사한 솔루션을 직접 구축할 수 있습니다.