随着时间的流逝，系统可能会发生很多丑陋的事情。 这就是关于技术债务的争论的全部内容–由于草率和短视决策，如何防止代码变得丑陋，脆弱，难以理解，以及随着时间的推移维护成本更高。 但是，代码中发生的最丑陋的事情与技术债务无关。 它们是有意识且精心设计更改的结果。

善意的更改可以创建难看的代码

当您决定重新架构或重写系统或开始进行大规模重构时 ，可能会发生坏事，但您无法完成工作。 其他更重要
在完成将所有代码过渡到新设计或新平台之前，需要进行工作–也许这永远不会发生，因为您没有预算和授权来完成整个工作。第一名。 或者是开始工作的人离开了，没有其他人足够了解他们的愿景以实现它–或没有人关心它以完成它。 或者，您仅够解决您或客户真正关心的任何问题，而没有继续前进的良好商业案例。

现在，剩下的就是我的同事所说的“ Frankensystem”：不同的设计和不同的平台以有效的方式拼接在一起，但是却很难理解和维护。

为什么会这样？ 您如何阻止系统变成这样的怪物？

通过抽象分支

至少在短期内，可以弄乱代码的一种方法是通过“ 抽象化分支”（Branching by Abstraction） ，这种想法在商店中很流行，因为Dark Launch通过持续部署或持续交付而发生了变化。

在“按抽象分支”（也称为“代码分支”）中，每个人都在主干中工作，而不是创建功能分支来隔离代码更改，然后在完成后将更改合并回去 。 如果需要进行较大的代码更改，请先编写临时脚手架（抽象层，条件逻辑， 功能部件之类的配置代码）以隔离您需要进行的更改，然后您可以直接在以较小的增量步骤编写代码主线。 在完成所有工作之前， 脚手架可保护系统的其余部分免受更改的影响。

按抽象分支试图解决管理功能分支 （尤其是寿命长的分支） 滥用的问题-如果您不让开发人员分支，则无需弄清楚如何使所有分支保持同步并管理合并冲突。 但是，通过抽象分支，直到工作完成并删除临时脚手架代码，该代码将更难以维护和理解，并且更加脆弱和容易出错，正如James McKay指出的那样 ：

“……可见与否，您仍在将代码部署到生产中，因为事实证明该事实存在错误，未经测试，不完整，甚至可能与实时数据不兼容。 您的if语句和配置设置本身就是受错误影响的代码-而且只能在生产中进行测试。 他们还付出了很多努力来维护，以致于很难用手指来指某些东西。 意外暴露是一个巨大的风险，很容易导致安全漏洞，数据损坏或商业秘密丢失。 您的功能可能不会像您以前想象的那样相互隔离，并且最终可能会在您的生产环境中部署错误。

如果您决定像这样在代码中分支（在某些情况下我们进行代码分支，而在其他情况下进行功能分支–代码分支则适合于进行幕后的管道更改，而不适合于大型功能更改），小心。 检查您的脚手架以确保代码更改完全隔离，并使用新旧配置（关闭和打开）进行测试以检查回归。 最大限度地减少团队一次发布的更改数量，以使更改没有重叠或冲突的机会。 为了避免“抽象分支”成为维护的噩梦，请确保在完成后立即删除临时脚手架。

半-死的僵尸

按抽象分支可能会导致代码难看，至少要花几周或几个月才能推出每个更改。 但是，如果您尝试以增量方式对系统进行主要的重写或重新架构，则代码中的情况可能会变得更糟，例如，使用新代码和新设计“扼杀”现有系统 （由ThougtWorks创造的另一种方法），以及慢慢使旧系统窒息 。

扼杀系统可以让您引入新的设计或切换到新的现代平台，而不必先完成漫长而昂贵的重写。 扼杀工作通常由一个单独的团队并行完成，让其余团队维护旧代码–这当然意味着在进行更改和修复时，两个团队都需要保持同步。

但是，如果您没有完成工作，您将留下一种僵尸，一种令人恐惧的半死半活的东西，上面有难看的接缝，正如Nat Pryce在此Stack Overflow帖子中警告的那样：

“要克服的最大问题是缺乏实际完成扼杀的意愿（通常是非技术利益相关者的政治意愿，表现为预算不足）。 如果您没有完全杀死旧系统，那么您将陷入更糟糕的困境，因为您的系统现在有两种方法，两者之间的界面很笨拙。 后来，另一波开发人员可能会决定扼杀那里的内容，编写另一个扼杀器应用程序，而又由于缺乏意愿，可能会通过三种处理方式使系统处于更加糟糕的状态。

我已经看到关键系统遭受了这两种命运的考验，最终出现了大约四到五个“战略架构方向”和“未来状态架构”。 一个大型的多站点项目最终在其新架构中使用了八种不同的新持久性机制。 另一个以两种不同的数据库模式结束，一种用于旧的工作方式，另一种用于新的方式，这两种模式都从未从系统中删除，并且还有多个类层次结构映射到这些模式中的一个甚至两个。 '

扼杀策略以及其他用于重新架构系统的增量策略，将使您在编写新系统的所有工作完成之前就尽早向客户展示收益。 这既是优点也是问题。 因为一旦客户开始得到他们真正关心的东西（一些漂亮的新屏幕或移动访问渠道，更好的性能或更快的规则更改周转时间……），您可能就无法使业务案例完成剩下的工作。 每个人都理解（或应该），这意味着您会陷入一些不一致的地方–肯定在内部，甚至在外部。 但是无论做什么工作，至少在短期内，保持混乱运行的成本可能比完成重写的成本低得多。

科学怪人和僵尸无处不在

在大型系统上，尤其是大型的，关键任务系统上，怪物的制造比通常情况下要频繁得多，许多人长期以来一直在使用这种系统。 正如Pryce所警告的那样，它甚至可能在一个大型系统的生命周期内发生多次，因此您最终将几个半实现的体系结构移植在一起，从而造成各种令人讨厌的维护和理解问题。

在进行更改或添加功能时，开发人员将不得不决定是采用旧方法还是新方法（或另一种新方法）–有时他们需要同时进行这两种操作，这意味着使用不同的工具跨不同的体系结构工作和不同的语言，并且经常不得不担心保持不同的数据模型同步。 这种复杂性意味着容易出错或遗漏或误解某些东西，并且测试可能比编码更丑陋。

当您开始逐步改变系统的方向和设计时，您需要意识到这些风险，即使您认为自己有决心和时间来正确完成工作。 因为您很有可能最终会创建一个必须与之共存多年的怪物。

参考： Building Real Software博客上来自JCG合作伙伴 Jim Bird的Frankensystems，半缠僵尸和其他怪兽 。

翻译自: https://www.javacodegeeks.com/2013/01/frankensystems-half-strangled-zombies-and-other-monsters.html