本文讲述了我们如何处理一个物流管理系统（OMS）的国际化，以及与新的电子商务平台集成的挑战。该系统开发于2018年，旨在优化一个蓬勃发展的电商的订单准备流程，并与不同的物流运营商高效集成。它使用PHP（Symfony）、MySQL、Socket.io和jQuery构建，涵盖从包装到发货的整个流程，包括订单跟踪、快递员连接、标签生成和订单准备性能指标等功能。
多年来，该系统运行良好，但随着业务发展，其局限性日益显现。技术债务尤其令人担忧，它影响了项目的多个层面。在技术基础设施方面，该应用程序运行在过时的框架和基础语言版本上：
除了过时的版本，项目在软件开发的基础方面也存在严重缺陷：
技术债务的累积不仅对系统的稳定性和安全性构成威胁，还：
最初的架构存在耦合问题，严重影响了其灵活性和可扩展性：
这些结构性限制不仅降低了系统的可维护性和可扩展性，还增加了与任何修改或演进相关的风险，使应用程序处于技术上脆弱和战略上易受攻击的状态。
最显著的挑战之一不仅是技术性的，也是战略性的。尽管外部开发在功能上是正确的，但在组织方面存在重大局限性：
这种情况在长期内是不可持续的，因为它：
在本项目中，一个经常被忽视但特别重要的方面是基本成本，我认为这是软件开发中的一个关键概念，它指的是即使不添加新功能或进行改进，维持系统运行所需的最低成本。
在我们的案例中，基本成本包括所有因需要维护过时的框架和语言版本、解决因技术债务累积而导致的紧急事件、管理与其他系统的依赖关系、适应耦合的架构以及对领域知识的了解不足而产生的费用。所有这些都消耗了大量可用资源，直接影响了投资创新和持续改进的能力。
虽然这个因素并不是促使我们决定内部化开发的决定性因素，但在项目的初步诊断中，它具有相当大的影响力。基本成本通常在评估系统的可持续性时被忽略，但在本案例中，它清楚地表明当前的策略在长期内是不可持续的。此外，正如我们在后续文章中将看到的，任何试图维持现有结构的尝试都将随着时间的推移成倍地增加基本成本。
有关基本成本概念及其重要性的更详细解释，建议参考Eduardo Ferro的原始文章。
在任何重构项目中，都可以采用多种策略，并且经常会遇到以下两难选择：绞杀者模式（strangler fig）或彻底重写（big bang rewrite）。
最初的技术决策是在同一个遗留项目中工作，采用绞杀者模式，这种方法包括开发一个新的模块或系统，逐步替换旧系统的部分。这种策略允许我们进行并行更改，降低风险，并在构建更坚实的基础以支持未来功能的同时保持当前功能。
然而，从业务的角度来看，这种选择对现有系统（该系统已投入运行并履行其职能）构成了过高的风险。我们决定避免触碰现有项目，而是开发一个独立的应用程序来满足新的需求。
这种转变导致我们对现有代码库进行了分支，这是一个技术上可行但存在某些缺点的决定：
这种方法使我们能够朝着独立的解决方案前进，确保现有系统的稳定性，同时开发一个与新的战略目标相一致的项目。然而，必须详细分析利弊，才能充满信心地进行规划和应对这一挑战。此外，我们与业务层面达成了共识，即不扩展功能，并在完成向新电子商务平台的迁移之前严格控制项目的积压工作。
| 优点 | 缺点 |
|---|---|
| 在非生产环境中工作，降低生产环境的风险 | 需要暂时维护多个项目 |
| 自由地从零开始实施新技术和模式 | 在维护方面的努力暂时重复 |
| 不必担心旧系统的技术限制或依赖关系 | 由于需要在系统之间同步更改，功能的重复可能会长期减缓开发速度 |
| 能够专注于必要的特性 | 截止日期的风险，因为有两个代码库 |
| 有机会从一开始就实施最佳实践 | 项目管理的复杂性 |
| 更容易从一开始就实施测试 | 需要与历史数据保持兼容性 |
| 灵活地适应新的业务需求 | 初始时间和资源成本更高 |
| 更好地与公司的整体战略相一致 | 可能暂时丢失非必要的特性 |
决定内部化和重写遗留软件从来都不是一件容易的事，尤其是在该软件能够完成其功能的情况下。“如果它能工作，就不要碰它”这句话将始终存在。然而，有时需要后退一步才能前进两步。
在本系列的后续文章中，我们将探讨我们如何应对这些挑战，我们做出的技术和战略决策，以及我们如何将这些挑战转化为改进和团队发展的机遇。
以上是从软件遗产到战略机遇：起点（一）的详细内容。更多信息请关注PHP中文网其他相关文章！
