이 기사에서는 물류 관리 시스템(OMS)의 국제화와 새로운 전자 상거래 플랫폼과의 통합 과제를 처리하는 방법에 대해 설명합니다. 이 시스템은 급성장 중인 전자상거래 기업의 주문 준비 프로세스를 최적화하고 다양한 물류 운영업체와 효율적으로 통합하기 위해 2018년에 개발되었습니다. PHP(Symfony), MySQL, Socket.io 및 jQuery를 사용하여 구축되었으며 주문 추적, 택배 연결, 라벨 생성 및 주문 준비 성과 지표와 같은 기능을 포함하여 포장부터 배송까지 전체 프로세스를 다룹니다.
이 시스템은 수년 동안 잘 작동했지만 비즈니스가 성장함에 따라 한계가 점점 더 분명해졌습니다. 기술 부채는 특히 걱정스럽습니다. 프로젝트의 여러 수준에 영향을 미치기 때문입니다. 기술 인프라 측면에서 애플리케이션은 오래된 프레임워크와 기본 언어 버전에서 실행됩니다.
이 프로젝트에는 오래된 버전 외에도 소프트웨어 개발의 기본에 심각한 결함이 있습니다.
기술 부채의 축적은 시스템의 안정성과 보안에 위협이 될 뿐만 아니라,
원래 아키텍처에는 유연성과 확장성에 심각한 영향을 미치는 결합 문제가 있었습니다.
이러한 구조적 제한은 시스템의 유지 관리성과 확장성을 감소시킬 뿐만 아니라 수정이나 발전과 관련된 위험을 증가시켜 애플리케이션을 기술적으로 취약하고 전략적으로 취약한 상태로 만듭니다.
가장 중요한 과제 중 하나는 기술적인 것뿐만 아니라 전략적인 것이기도 합니다. 외부 개발은 기능적으로는 정확하지만 상당한 조직적 한계가 있습니다.
이 상황은 다음과 같은 이유로 장기적으로 지속 불가능합니다.
이 프로젝트에서 종종 간과되지만 특히 중요한 측면은 기본 비용입니다. 기본 비용은 소프트웨어 개발의 핵심 개념이며 새로운 기능을 추가하거나 필요한 최소 비용을 개선하지 않고도 시스템을 계속 실행하는 데 드는 비용을 말합니다.
우리의 경우 기본 비용에는 오래된 프레임워크 및 언어 버전 유지, 기술 부채 축적으로 인한 긴급 상황 해결, 다른 시스템과의 종속성 관리, 결합 아키텍처 적응, 이해 부족으로 인해 발생하는 도메인 지식 비용과 관련된 모든 비용이 포함됩니다. . 이 모든 것은 상당한 양의 가용 리소스를 소비하며 혁신과 지속적인 개선에 투자하는 능력에 직접적인 영향을 미칩니다.
이 요소가 개발을 내재화하기로 결정한 결정적인 요소는 아니었지만 프로젝트의 초기 진단에는 상당한 영향을 미쳤습니다. 시스템의 지속 가능성을 평가할 때 기본 비용은 종종 무시되지만, 이 경우 현재 전략이 장기적으로 지속 가능하지 않다는 것을 분명히 보여줍니다. 더욱이, 후속 기사에서 살펴보겠지만, 기존 구조를 유지하려는 시도는 시간이 지남에 따라 기본 비용을 기하급수적으로 증가시킬 것입니다.
기본 비용 개념과 그 중요성에 대한 자세한 설명은 Eduardo Ferro의 원본 기사를 참조하는 것이 좋습니다.
모든 리팩토링 프로젝트에는 다양한 전략을 사용할 수 있으며 딜레마에 자주 직면합니다. 즉, strangler fig 또는 big bang rewrite입니다.
초기 기술 결정은 Strangler 패턴을 사용하여 동일한 레거시 프로젝트 내에서 작업하는 것이었습니다. 이 접근 방식은 기존 시스템의 일부를 점진적으로 대체하는 새로운 모듈 또는 시스템을 개발하는 접근 방식입니다. 이 전략을 통해 우리는 병행 변경을 수행하고 위험을 줄이며 현재 기능을 유지하는 동시에 미래 기능을 지원하기 위한 보다 강력한 기반을 구축할 수 있습니다.
그러나 비즈니스 관점에서 볼 때 이 옵션은 (이미 운영 중이며 기능을 수행하고 있는) 기존 시스템에 과도한 위험을 초래합니다. 우리는 기존 프로젝트를 건드리지 않고 대신 새로운 요구 사항을 충족하기 위해 독립형 애플리케이션을 개발하기로 결정했습니다.
이러한 변화로 인해 기존 코드베이스를 포크하게 되었는데, 이는 기술적으로는 실현 가능하지만 몇 가지 단점이 있었습니다.
이러한 접근 방식을 통해 우리는 새로운 전략적 목표에 맞춰 프로젝트를 개발하는 동시에 기존 시스템의 안정성을 보장하는 독립적인 솔루션을 향해 나아갈 수 있습니다. 그러나 이러한 과제를 자신있게 계획하고 해결하려면 장단점에 대한 자세한 분석이 필요합니다. 또한 새로운 전자상거래 플랫폼으로의 마이그레이션이 완료될 때까지 기능을 확장하지 않고 프로젝트 백로그를 엄격하게 통제하기로 비즈니스 레벨과 합의했습니다.
| 优点 | 缺点 |
|---|---|
| 在非生产环境中工作，降低生产环境的风险 | 需要暂时维护多个项目 |
| 自由地从零开始实施新技术和模式 | 在维护方面的努力暂时重复 |
| 不必担心旧系统的技术限制或依赖关系 | 由于需要在系统之间同步更改，功能的重复可能会长期减缓开发速度 |
| 能够专注于必要的特性 | 截止日期的风险，因为有两个代码库 |
| 有机会从一开始就实施最佳实践 | 项目管理的复杂性 |
| 更容易从一开始就实施测试 | 需要与历史数据保持兼容性 |
| 灵活地适应新的业务需求 | 初始时间和资源成本更高 |
| 更好地与公司的整体战略相一致 | 可能暂时丢失非必要的特性 |
기존 소프트웨어를 내부화하고 다시 작성하기로 한 결정은 결코 쉽지 않습니다. 특히 소프트웨어가 제 역할을 할 수 있는 경우에는 더욱 그렇습니다. "효과가 있으면 만지지 마세요"라는 말이 항상 거기에 있을 것입니다. 그러나 때로는 두 걸음 전진을 위해 한 걸음 후퇴가 필요한 경우도 있습니다.
이 시리즈의 후속 기사에서는 이러한 과제에 어떻게 대응했는지, 우리가 내린 기술 및 전략적 결정, 이러한 과제를 개선 및 팀 개발의 기회로 전환한 방법을 살펴보겠습니다.
위 내용은 소프트웨어 레거시에서 전략적 기회로: 출발점(I)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
