良好代码结构的惊人不稳定

先前的一篇文章指出，源代码结构会退化，因为构建结构不良的系统的方法要多于结构良好的系统，因此，如果没有严格的结构准则，系统将不可避免地更深入地探索无序状态空间，直到找到黑暗泥泞的必杀技，很少有人逃脱。 这篇短文仅以图形方式展示了该现象。

图1显示了结构良好的系统的斯皮克林图 。

图1：结构合理的封装图。

在图1中，每个圆圈是一个包装，每个直线从上方的包装到下方的包装都是一条曲线，从下方的包装到上方的包装是每条曲线（没有曲线）。

当一个软件包的依赖关系易于跟踪时，当一个系统很容易地暗示对任何软件包的更新可能如何影响其他软件包时，系统就具有良好的结构。 图1底部的深红色包装严重依赖于此，因此修改成本可能很高； 沿着顶部的包装是相对隔离的，因此修改起来很便宜。

现在，假设负责此系统的团队是一个糟糕的程序员– Ropy先生，“请叫我'Ent'！” –显然无视结构准则的人。 这家伙更了解。 他做自己的事。 为了给管理层留下深刻的印象，Ent发起了10个“重构”的批处理：他将10个类移到了包中，他认为其中的类更正确地属于“包”。

第一批重构的结果如图2所示，与原始版本并排比较。

图2：原始重构和第一批10重构。

您对此有何立即反应？ 您可以在此重构前后的图中看到系统之间的区别吗？ 您认为哪个系统的结构更合理？ 具体来说，更容易跟踪哪个系统的依赖项？

该团队Swift审查了这批“重构”，并投票拒绝批准提交干线的许可。 但是，请不要忽视，我们的新年轻入门者提出了另一批10项重构的方法-这批方法比以前更正确。 图3并排显示了原始系统和第二批结果

图3：原始的和第二次替换的10个重构。

再说一次：您认为哪种系统更好？ 哪个系统的依赖项更容易跟踪？

小组Swift再次删除了分支。 粘稠先生大吃一惊，花费整个周末完善最后的最好的最以往 批次的10个重构，一次包间移动只有10班。 图4显示了结果。

图4：原始和备用的第三批10项重构。

Ent被解雇。

他之所以被解雇，是因为他的“重构”毫无意义。 重构改善了系统结构：它们使依赖关系更容易跟踪，而不是更难。 Ent的重构简直糟透了。

Ent不为所动，在其他地方找到了工作。 图5显示了新的系统，他的工作时，的封装结构最近检讨 FitNesse的 。

图5：Fitnesse的包装图。

没有快是他在门口接着他踏上了勇敢的新批的10个重构，批，这将使该产品只是让工作更容易使用，并留下他的经理采空区，砸到。 重构再次简单地将10个类迁移到不同的包中，图6显示了结果以及原始系统。

图6：原始和第一批10项重构。

立即反应时间：这批重构使系统变好还是变差？ 在重构之前或之后更容易跟踪依赖项吗？

产品团队拒绝提供此类报价并删除分支。 Ent可以预见地反省并设计第2 批 ，请参见图7。

图7：原始和第二批10重构。

而这一次，他的想法超前了。 他同时准备了第三批重构，以备不时之需。 见图8。

图8：原始和备用的第三批10项重构。

您如何看待Ropy先生在第二套系统上的努力？

很少有程序员能轻易分辨出这些批次是否使系统的结构更好或更差。 您可能会猜到（也许第三个看上去更糟？），但它并不立即显而易见。

现在，令人震惊的发现：罗皮先生不存在！ 以上六个批次是完全随机选择的：要移动的类是随机选择的，目标包装也是这样。

当然，没有人会真正进行这样的更改，但是这里的要点是，您的系统应具有良好的结构，以使所有批次的随机重构所造成的性能下降应该立即对所有人显而易见。 从这个意义上说，好的结构是脆弱而不稳定的，因为即使很小的变化也会产生很大的有害影响。 另一方面，不良的结构非常稳定：您可以对其进行一系列的更改，但其属性或多或少保持不变。 秩序趋向于混乱，混乱趋于停留在原地，非常感谢。

如果您正在开发上面的第一个系统，并在星期一早上到达那里查看那些“重构的”包装图，那么您将捣碎紧急WTF警报并锁定整个建筑物以寻找罪魁祸首。

老实说，如果您在第二个系统上工作，当您开始一周的工作时，您是否还知道有什么变化？

换句话说，如果您可以对系统进行随机的结构更改而不注意到明显的降级，则您的系统结构是随机的。 它是最大的混乱。 您预测修改成本的能力将被最小化，而实际成本与您希望实现的修改大小几乎没有关系。

问题是：您想让Ropy先生加入您的组织吗？ 您对系统的结构是否足够自信，以至于他的无能将被暴露？ 而且你知道他是否已经在你旁边工作吗？

摘要

宇宙讨厌程序员。

当涉及到行为时，我们希望我们的程序是稳定的：我们希望它们在广泛变化的条件下能够一致且可预测地做出反应。 但是，正如每个程序员所知道的，所有程序都想做的是，在其数字功能允许的范围内，尽可能快地抛出NullPointerExceptions。

当涉及到结构时，我们希望我们的源代码组织尽可能地不稳定，以便我们可以清楚地看到对一个部分的修改如何影响其他部分。 但是，每个程序员都知道，所有源代码结构都希望以光速崩溃，成为地球上部署最广泛的源代码结构：泥球。

当涉及到重构时，生命是至关重要的。

翻译自: https://www.javacodegeeks.com/2016/02/spectacular-instability-good-code-structure.html