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

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 等）
• 您需要什么类型的文件？（源代码、最终用户等）
• 您使用什么样的指标来确定应用程序的运行情况？
• 回顾三年来你开始的时候 - 了解你现在所知道的，你希望当时实施哪些设计决策？

软件：

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

硬件：

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

人员：

• 您是否得到了所有利益相关者的“认可”？如果不是全部，你至少得到了决策者的支持吗？
• 利益相关者是否了解这将是一项多么艰巨的任务？

灾难预防/恢复：

• 如果主服务器/网络不可用，您将如何提供冗余？
• 您将如何备份数据（现场、异地、短期、长期）？
• 您需要设置什么样的监控？出现问题时应如何通知您？应该通知谁？

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