复杂的应用程序堆栈重构/重新设计策略

Question

我参与了一项涉及重大重构或完全重新设计的项目维护计划。我们有一个非常复杂的现有技术堆栈，在五年的时间内有机地发展。三年前我自己加入了，并且在疯狂中“陷入了困境”。这个堆栈是根据客户不断变化的需求而组合在一起的，并且很快成为一个由许多技术和无法控制的数据收集组成的无法管理的庞然大物。

我们的主要目标是使堆栈更易于使用和管理，并提出一个更好的系统来管理未来的数据。我们希望将主要用PHP编写的紧密集成的业务模型和REST控制器系统转换为一致的REST API。

我们的PHP业务模型依赖于包含大部分数据的eXist XML数据库，以及支持2个子应用程序数据的MySQL。我们有一个SQL和XQuery源代码库，可以动态地管理数据存储中的数据。通过使用PHP-Java Bridge和SAXON以及FOP来创建存储在XML数据库中的文档的PDF传真，业务模型的某些部分依赖于Java代码。由于这是一个Web应用程序，我们使用PHPTAL，XSLT，CSS，XHTML和JavaScript的组合来方便客户端UI。最后，我们有一堆管理脚本来管理PHP，Apache，用Perl编写的函数，这些脚本使用Ant任务进行管理。

堆栈的基本功能是为各种用户模型提供便利的电子表格。多年来，应用程序背后的简单哲学被客户摆弄，过度的最终用户手持，缺乏系统分析监督，糟糕的测试方法以及缺乏未来目标和明确的项目范围所破坏。

我们目前正计划阻止任何进一步的开发，更好地描述可能包含或不包含更好的单元测试计划的系统，并使用相同的技术组件为API创建基础。我的直觉反应是提出一个可靠的范围，并使用一个良好支持的编程语言和框架重新设计系统，该语言和框架非常适合编写Web API，可能会丢失一些功能，但保留最重要的功能。我还建议将现有数据迁移到单独的“只读”平台。

我对那些遇到类似情况的人的问题是：

• 你是怎么摆脱这种情况的？
• 在这种情况下采用哪种规划步骤会有用？
• 有这些堆栈的源代码管理技术吗？我该找什么？ - 搜索关键词

我意识到没有完美的解决方案，为了回答这些问题，我需要进一步指出我们的项目问题。出于各种原因，我无法真正做到这一点。我在寻找有用的资源以帮助我解决这个问题时遇到了问题，我很感激有关如何继续的建议。

Answer 1

如果我在你的鞋子里，我会问一些问题或想一想：

数据库设计：

• 您需要捕获哪些信息？
• 如何将它们捆绑在一起？
• 您需要做什么样的报告？
• 您想收集哪种指标？
• 什么时候应该将旧数据永久清除到长期存档？

应用程序设计：

• 您现在可以在系统中设计哪些内容，以减少客户需要“手持”的程度？
• 目前缺少或缺少哪些功能？
• 您是否可以进行任何简单的更改以扩大您的客户群？
• 你有正式的编码标准吗？它是强制执行的吗？
• 您想要什么样的测试？ （单元测试，正式QA等）
• 您想要什么样的文件？ （源代码，最终用户等）
• 您使用哪种指标来确定应用程序的运行情况？
• 回首三年到你开始的时候 - 知道你现在知道什么，你希望你在那时做出哪些设计决定？

软件：

• 是否可以使用较少的一组技术在同一级别提供相同的服务？
• 您现有员工最熟悉哪些技术？
• 如果你需要雇用更多的人，那么哪些技术最容易引入永久或顾问？

设备：

• 您现有的硬件是否满足您的需求？如果没有，你需要什么？更多服务器？更大的服务器？负载平衡器？等
• 您目前正在利用虚拟化吗？

人员：

• 您是否从所有利益相关者那里“买进”？如果不是全部，你至少从决策者那里买进来吗？
• 利益相关者是否理解这将是一项多大的工作？

防灾/恢复：

• 如果主服务器/网络不可用，您将如何提供冗余？
• 您将如何备份数据（现场，非现场，短期，长期）？
• 您需要进行哪种监控？如果出现问题，您应该如何得到通知？应该通知谁？

抱歉，我无法将其纳入评论中:-)而且我没有时间详细说明其中任何一项，我只是在等待会议的时间。