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