소프트웨어 레거시에서 전략적 기회로: 출발점(I)

기존 소프트웨어 리팩토링: 과제를 기회로

이 기사에서는 물류 관리 시스템(OMS)의 국제화와 새로운 전자 상거래 플랫폼과의 통합 과제를 처리하는 방법에 대해 설명합니다. 이 시스템은 급성장 중인 전자상거래 기업의 주문 준비 프로세스를 최적화하고 다양한 물류 운영업체와 효율적으로 통합하기 위해 2018년에 개발되었습니다. PHP(Symfony), MySQL, Socket.io 및 jQuery를 사용하여 구축되었으며 주문 추적, 택배 연결, 라벨 생성 및 주문 준비 성과 지표와 같은 기능을 포함하여 포장부터 배송까지 전체 프로세스를 다룹니다.

기술부채 축적

이 시스템은 수년 동안 잘 작동했지만 비즈니스가 성장함에 따라 한계가 점점 더 분명해졌습니다. 기술 부채는 특히 걱정스럽습니다. 프로젝트의 여러 수준에 영향을 미치기 때문입니다. 기술 인프라 측면에서 애플리케이션은 오래된 프레임워크와 기본 언어 버전에서 실행됩니다.

• Symfony 버전(4.0)은 장기 지원(LTS) 버전이 아니며 2019년 1월부터 보안 업데이트 수신이 중단됩니다.
• PHP 7.1도 수명주기가 종료되었으며 시스템에 중요한 보안 업데이트가 부족합니다.

이 프로젝트에는 오래된 버전 외에도 소프트웨어 개발의 기본에 심각한 결함이 있습니다.

• 테스팅 부족 또는 불충분: 자동화된 테스트(단위, 통합 및 엔드투엔드 테스트)가 부족하면 버그를 조기에 발견하는 데 방해가 될 뿐만 아니라 수정 사항이 잠재적으로 안정성을 위협할 수도 있습니다. 시스템의.
• 코딩 표준 부족: 코드베이스는 문서화된 패턴이나 표준을 따르지 않으며, 있다고 하더라도 업계 모범 사례와 일치하지 않습니다. 이로 인해 프로젝트 유지 관리와 새로운 개발자 온보딩이 모두 어려워집니다.
• 부적절한 문서: 기존 문서가 부족하고 불완전한 경우가 많습니다. 이는 기술 개발뿐만 아니라 코드에 구현된 비즈니스 프로세스에 대한 이해에도 영향을 미칩니다.
• 불완전한 버전 제어: Git 기록에 설명이 부족하고, 커밋 세분성이 거칠고, 메시지가 규칙을 따르지 않으며, 변경 사항에 대한 배경 정보가 부족합니다. 이로 인해 시간이 지남에 따라 이루어진 코드 및 결정의 발전을 이해하기가 어렵습니다.

기술 부채의 축적은 시스템의 안정성과 보안에 위협이 될 뿐만 아니라,

• 새로운 기능의 개발 속도 감소
• 버그 유입 위험 증가
• 새 멤버의 팀 합류 난이도가 높아졌습니다
• 유지비 증가
• 문제 진단 및 해결이 복잡함

구조적 한계

원래 아키텍처에는 유연성과 확장성에 심각한 영향을 미치는 결합 문제가 있었습니다.

• 주 전자상거래 플랫폼에 전적으로 의존: 애플리케이션은 독립적으로 실행될 수 없으며 모든 물류 운영은 전자상거래 플랫폼의 데이터와 프로세스에 직접적으로 의존합니다. 이는 메인 플랫폼을 변경하면 시스템 기능이 중단될 수 있음을 의미합니다.
• 성능 문제를 일으키는 공유 데이터베이스: 물류 애플리케이션과 전자 상거래 플랫폼은 동일한 데이터베이스를 사용하므로 특히 두 애플리케이션의 최대 로드 기간 동안 성능 문제가 발생합니다. 또한 이 구성은 데이터베이스에 대한 액세스로 인해 다른 시스템의 중요한 데이터가 손상될 수 있으므로 권한 관리를 복잡하게 만듭니다.
• 독립형 실행 불가: 이 앱은 전자상거래 플랫폼에서만 실행되도록 설계되었습니다. 이로 인해 이식성이 제한될 뿐만 아니라 격리된 환경에서 테스트하거나 다른 플랫폼으로 마이그레이션하는 것도 방지됩니다. 해당 종속성이 제대로 캡슐화되지 않았고, 격리를 시도하려면 전체 시스템에 대해 크고 비용이 많이 드는 변경이 필요하며, 기본 클래스에서는 SRP(단일 책임 원칙)가 준수되지 않습니다.
• 새로운 기능 구현의 어려움: OCP(개방/폐쇄 원칙) 및 LSP(리스코프 대체 원칙) 준수 부족은 시스템 발전을 크게 방해합니다. 새로운 기능을 사용하려면 기존 코드를 수정해야 하므로 회귀가 발생할 위험이 높아집니다. 또한 모듈 간의 직접적인 종속성으로 인해 DIP(종속성 역전 원칙)를 따르는 것이 거의 불가능합니다.

이러한 구조적 제한은 시스템의 유지 관리성과 확장성을 감소시킬 뿐만 아니라 수정이나 발전과 관련된 위험을 증가시켜 애플리케이션을 기술적으로 취약하고 전략적으로 취약한 상태로 만듭니다.

개발 관리 및 전략적 연계

가장 중요한 과제 중 하나는 기술적인 것뿐만 아니라 전략적인 것이기도 합니다. 외부 개발은 기능적으로는 정확하지만 상당한 조직적 한계가 있습니다.

• 글로벌 전략과의 단절: 개발은 회사 내부 목표와 프로세스에 대한 완전한 이해 없이 사일로에서 수행됩니다. 이로 인해 기술적으로는 정확하더라도 비즈니스의 실제 요구 사항을 항상 충족시키지 못하는 기능이 생성됩니다.
• 전략적 우선순위 부족: 새로운 기능 구현 시 명확한 평가 및 우선순위 지정 프로세스가 부족합니다. 기능이 정말 필요한지, 기능을 구현하는 가장 좋은 방법인지, 더 효율적인 대안이 존재하는지에 대해서는 의문의 여지가 없습니다.
• 반응적 개발과 사전 예방적 개발: 개발은 주로 반응형 모델을 따르며, 회사 내 다른 프로세스와의 장기적인 영향이나 잠재적인 시너지 효과를 고려하지 않고 즉각적인 요구 사항을 해결합니다.
• 검증 프로세스 부족: 구조화된 검토 및 검증 프로세스가 부족하여 기능이 작동하는 동안 최종 사용자나 회사의 전반적인 목표에 항상 최상의 솔루션을 제공하지는 않습니다.

이 상황은 다음과 같은 이유로 장기적으로 지속 불가능합니다.

• 실제 요구 사항에서 점점 벗어나는 제품 발생
• 다른 회사 시스템 및 프로세스와의 통합을 방해합니다
• 제품에 대한 전략적 결정을 복잡하게 합니다
• 팀의 혁신과 지속적인 개선 능력이 제한됩니다

기본비용의 영향

이 프로젝트에서 종종 간과되지만 특히 중요한 측면은 기본 비용입니다. 기본 비용은 소프트웨어 개발의 핵심 개념이며 새로운 기능을 추가하거나 필요한 최소 비용을 개선하지 않고도 시스템을 계속 실행하는 데 드는 비용을 말합니다.

우리의 경우 기본 비용에는 오래된 프레임워크 및 언어 버전 유지, 기술 부채 축적으로 인한 긴급 상황 해결, 다른 시스템과의 종속성 관리, 결합 아키텍처 적응, 이해 부족으로 인해 발생하는 도메인 지식 비용과 관련된 모든 비용이 포함됩니다. . 이 모든 것은 상당한 양의 가용 리소스를 소비하며 혁신과 지속적인 개선에 투자하는 능력에 직접적인 영향을 미칩니다.

이 요소가 개발을 내재화하기로 결정한 결정적인 요소는 아니었지만 프로젝트의 초기 진단에는 상당한 영향을 미쳤습니다. 시스템의 지속 가능성을 평가할 때 기본 비용은 종종 무시되지만, 이 경우 현재 전략이 장기적으로 지속 가능하지 않다는 것을 분명히 보여줍니다. 더욱이, 후속 기사에서 살펴보겠지만, 기존 구조를 유지하려는 시도는 시간이 지남에 따라 기본 비용을 기하급수적으로 증가시킬 것입니다.

기본 비용 개념과 그 중요성에 대한 자세한 설명은 Eduardo Ferro의 원본 기사를 참조하는 것이 좋습니다.

전환점: 새로운 도전과 전략적 결단

모든 리팩토링 프로젝트에는 다양한 전략을 사용할 수 있으며 딜레마에 자주 직면합니다. 즉, strangler fig 또는 big bang rewrite입니다.

초기 기술 결정은 Strangler 패턴을 사용하여 동일한 레거시 프로젝트 내에서 작업하는 것이었습니다. 이 접근 방식은 기존 시스템의 일부를 점진적으로 대체하는 새로운 모듈 또는 시스템을 개발하는 접근 방식입니다. 이 전략을 통해 우리는 병행 변경을 수행하고 위험을 줄이며 현재 기능을 유지하는 동시에 미래 기능을 지원하기 위한 보다 강력한 기반을 구축할 수 있습니다.

그러나 비즈니스 관점에서 볼 때 이 옵션은 (이미 운영 중이며 기능을 수행하고 있는) 기존 시스템에 과도한 위험을 초래합니다. 우리는 기존 프로젝트를 건드리지 않고 대신 새로운 요구 사항을 충족하기 위해 독립형 애플리케이션을 개발하기로 결정했습니다.

이러한 변화로 인해 기존 코드베이스를 포크하게 되었는데, 이는 기술적으로는 실현 가능하지만 몇 가지 단점이 있었습니다.

• 코드 베이스 중복: 이제 두 개의 별도 코드 베이스를 유지 관리해야 합니다.
• 데이터베이스 분리: 데이터 구조는 각 시스템에 맞게 복사되고 조정되어야 합니다.
• 인프라 복제: 독립적인 서버를 배포하고 각 시스템에 대한 적절한 관찰 가능성을 보장해야 합니다.
• 팀의 인지 부하 증가: 이러한 모든 중복에는 두 시스템 간의 일관성을 유지하기 위한 추가 노력이 필요하므로 팀의 복잡성과 오류 위험이 증가합니다.

이러한 접근 방식을 통해 우리는 새로운 전략적 목표에 맞춰 프로젝트를 개발하는 동시에 기존 시스템의 안정성을 보장하는 독립적인 솔루션을 향해 나아갈 수 있습니다. 그러나 이러한 과제를 자신있게 계획하고 해결하려면 장단점에 대한 자세한 분석이 필요합니다. 또한 새로운 전자상거래 플랫폼으로의 마이그레이션이 완료될 때까지 기능을 확장하지 않고 프로젝트 백로그를 엄격하게 통제하기로 비즈니스 레벨과 합의했습니다.

优点	缺点
在非生产环境中工作，降低生产环境的风险	需要暂时维护多个项目
自由地从零开始实施新技术和模式	在维护方面的努力暂时重复
不必担心旧系统的技术限制或依赖关系	由于需要在系统之间同步更改，功能的重复可能会长期减缓开发速度
能够专注于必要的特性	截止日期的风险，因为有两个代码库
有机会从一开始就实施最佳实践	项目管理的复杂性
更容易从一开始就实施测试	需要与历史数据保持兼容性
灵活地适应新的业务需求	初始时间和资源成本更高
更好地与公司的整体战略相一致	可能暂时丢失非必要的特性

결론 및 다음 단계

기존 소프트웨어를 내부화하고 다시 작성하기로 한 결정은 결코 쉽지 않습니다. 특히 소프트웨어가 제 역할을 할 수 있는 경우에는 더욱 그렇습니다. "효과가 있으면 만지지 마세요"라는 말이 항상 거기에 있을 것입니다. 그러나 때로는 두 걸음 전진을 위해 한 걸음 후퇴가 필요한 경우도 있습니다.

이 시리즈의 후속 기사에서는 이러한 과제에 어떻게 대응했는지, 우리가 내린 기술 및 전략적 결정, 이러한 과제를 개선 및 팀 개발의 기회로 전환한 방법을 살펴보겠습니다.

위 내용은 소프트웨어 레거시에서 전략적 기회로: 출발점(I)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!