Hal*_*ard 34 architecture design-patterns
就在最近,我遇到了一个名为Application Strangler Pattern的想法.据我了解,它是大型遗留系统问题的解决方案.我们的想法是围绕旧应用程序创建一个新的应用程序.这种成本和风险远远低于完全重写系统的成本和风险.慢慢地,随着时间的推移,新应用程序将做越来越多的工作,并最终扼杀旧的遗留应用程序.与此同时,开发人员可以在一个干净的新系统中工作,效率更高,并希望能够生成更好的代码.
我现在工作的地方是新功能,即使是看似微不足道的事情,需要很长时间才能开发,有很高的破坏风险.我们坐了大约一百万行代码,单元测试覆盖率可能达到1-2%.该系统是一个使用Web服务的SOA系统(两者都不是必需的),并且在风格上比面向对象更具程序性.该系统既是web又是win,都是用.net编程语言编写的.
最后一个问题: 在考虑这个新的想法/模式时,我想知道是否有人有使用这种模式的经验,他们想分享.例如,实现它的好方法是什么(例如,连接旧应用程序中的事件)？此外,如果任何人对这个问题有任何想法,为什么它会是一个好的或坏的想法,那也是值得赞赏的.
参考文献:
Nat*_*Nat 23
要克服的最大问题是缺乏实际完成扼杀的意愿(通常来自非技术利益相关者的政治意愿,表现为缺乏预算).如果你没有彻底杀掉旧系统,那么你最终会陷入更糟的混乱状态,因为你的系统现在有两种方法可以通过两者之间的尴尬接口来完成所有事情.后来,另一波开发人员可能会决定扼杀那里的东西,编写另一个扼杀者应用程序,再次缺乏意志可能会使系统处于更糟糕的状态,有三种做事方式.
如果项目规模很大,从多个地区开始,那么你必须就最终状态应该是什么以及每个人如何合作达成目标达成全球共识.当旧的应用程序被勒死时,远程团队每天进行通信,在可能的情况下通过远程结对编程进行合作至关重要,并在出现时立即解决任何误解或分歧.否则,每个区域团队都会决定编写自己的扼杀者应用程序,并且他们将在中间的某个地方相遇并将其解决,从而使系统更糟糕.
无论你做什么,都不要在与主流开发不同的分支中进行重构/扼杀.合并困难将变得无法克服.
我已经看到了遭受这两种命运的关键系统,并最终得到了大约四到五个"战略架构方向"和"未来的国家架构".一个大型多站点项目最终在其新架构中使用了八种不同的新持久性机制.另一个最终得到了两个不同的数据库模式,一个用于旧方式,另一个用于新方式,两个模式都没有从系统中删除,并且还有多个类层次结构映射到这些模式中的一个或甚至两个.
最后,如果您要引入团队新手或支持/维护人员的技术(例如,将可靠的异步消息传递添加到当前的同步三层客户端/服务器架构),那么您必须确保有经验丰富的技术领导项目谁知道如何使用该技术构建系统,并支持这些系统.在旧应用程序被完全勒死之后,那些技术主管必须坚持使用该项目一段时间.否则,架构将会降级,因为没有经验的开发人员会以他们所知的方式修改它,但不会以适合新架构的方式修改它.
这种模式的最大风险在于,您最终会避开旧代码和新代码以获得所需的行为,特别是如果旧代码从未设计为被勒死(即不提供干净一致的接口).
我对此的经验是调试变得越来越困难,因为不清楚新代码或旧代码(或两者之间的共享问题)是否出现了问题功能.
我知道Martin Fowler谈到编写被扼杀的代码,但在我看来,这只是说模块化设计很好的另一种方式,mmmkay; 它没有争议且相当明显.
扼杀者背后的基本前提是非常好的:不是试图一次性替换遗留系统而试图做"大爆炸"风格,而是通过在层上制作垂直切片来构建一个扼杀者应用程序,将每个现有特征替换为一直到原来的系统可以退役.它在理论和实践中运作良好 - 可能最好的事情之一就是它可以大大降低技术风险并帮助团队专注于替换最重要的功能.如果新系统不起作用,人们可以简单地使用旧系统.
怎么可能出错？
所有这些问题点当然都是可以管理的.重新安排团队,保持系统之间的清晰分离,特别关注项目方向,以及围绕替换现有系统设定现实目标可能会有所帮助.