我参与了一个涉及重大重构或完全重新设计的项目维护计划.我们有一个非常复杂的现有技术堆栈,在五年的时间内有机地发展.我自己三年前加入了,并且在疯狂中被“赶上了”.这个堆栈是根据客户不断变化的需求而组合在一起的,并且很快成为一个由许多技术和无法控制的数据收集组成的无法管理的庞然大物.
我们的主要目标是使堆栈更加可行和可管理,并提出一个更好的系统来管理未来的数据.我们希望将主要使用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,可能会丢失一些功能,但保留最重要的功能.我还建议将现有数据迁移到单独的“只读”平台.
我对那些遇到类似情况的人的问题是:
>你是怎么摆脱这种情况的?
>在这种情况下采用哪种规划步骤会有用?
>这些堆栈有源代码管理技术吗?我该找什么? – 搜索关键字
我意识到没有完美的解决方案,为了回答这些问题,我需要进一步指出我们的项目问题.出于各种原因,我无法真正做到这一点.我在寻找有用的资源以帮助我解决这个问题时遇到了问题,我希望有关如何继续的建议.