有没有证据表明存在连锁反应？

本文主要是介绍有没有证据表明存在连锁反应？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

该博客一直在讨论涟漪效应管理（或缺乏涟漪效应管理）及其确定源代码结构的质量。涟漪效应-在一处轻轻地打磨代码会产生摆动和裂缝，并在远处产生广泛的崩溃崩溃-于1974年定义，此后一直指导着结构上的辛劳。

但这真的存在吗？

或者更确切地说：存在连锁反应的证据在哪里？您将如何收集此类证据？

假设您有100个玻璃弹珠：40个红色和60个蓝色。不，不是蓝色：黄色。您将它们扔在地板上，闭上眼睛，随机捡起一只。您选择的大理石是红色的概率是多少？

如果回答“ 0.4”或“ 40％”，那就做得很好：您掌握了概率论。更换大理石并重复实验10,000次：您会发现选择历史与初始比率非常接近：也许是4095红色到5905黄色。喜欢大数定律。

暂时更改实验原因很简单：假设您现在拥有10,000个分散的大理石-4,000个红色，6,000个黄色-而不是选择一个大理石，而是随机选择200个大理石并将它们放在一个袋。该样品中有多少比例是红色大理石？

是：大约40％。这与执行200次单一选择的确没有什么不同：如果有40％的机会选择红色大理石，那么（几乎很少（尽管很少））您包中的大理石有40％将是红色的。

现在，考虑一种调用另一种方法的方法，即依赖于另一种方法。让我们将不依赖于任何其他方法的所有方法称为“子方法”，并将不依赖于任何其他方法的所有方法称为“父方法”。因此，在图1中，只有a（）是子方法。

图。1
图1：main（）和Wonder（）是父方法，a（）是子方法。

假设您有一个由10,000个方法组成的系统，其中40％是父方法，而60％是子方法。随机选择200种方法。您选择的父子方法的比例是多少？

是：大约40％的方法将是父方法。这是与上面的大理石袋相同的实验。

到目前为止，总延误了，对吧？

但是，现在让我们检查一下随着时间的推移发行的一些实际Java软件系统，并在每个后续发行版中选择许多方法。但是，我们不会随机选择。相反，我们将选择在该版本中更新的那些方法。

程序员出于多种原因更新方法，但是很少有会议以“快速！我们需要更新300个父方法-我们将选择哪些方法？” 因此，如果我们选择发行版的更新方法，那么选择本身当然不是随机的，因为程序员不会坐在他们的裤子里掷硬币来选择要更新的方法。但是他们也没有明确选择是父母还是孩子，因此选择父母还是孩子应该是随机的，因为心理平衡的程序员不在乎。如果一个版本包含40％的父方法和60％的子方法，那么我们应该期望看到这些比例大致反映在该版本中更新的方法集中：40％的更新方法应该是父方法，60％的更新方法应该是父方法应该是子方法。大致。

但是，纹波效应预示了一些不同的结果。

涟漪效应涉及到相关性，即“……变化和错误可以沿着这些路径传播到系统其他部分的路径”。由于从父母到孩子的直接依赖性是最强的依赖性，如果存在连锁反应，则涟漪效应预测，在一组更新方法中，对父母会有轻微的偏见：与子方法相比，将更新更多的父母。这是因为虽然父方法和子方法都可以独立更新，但由于子方法的更新，父方法被更新的可能性要大得多（反之亦然）（因为父方法取决于子方法，反之亦然）。

当然，如果在更新的版本中对父母没有偏见，那么我们甚至有证据表明实际上不存在连锁反应，并且可以将40年的软件结构装在黑色塑料袋中，放在河里。

图2显示了Apache Maven核心jar文件的21个连续发行版。红线显示在任何给定发行版中，作为父方法的Maven方法的百分比，这也是该发行版的更新方法中被预测为父方法的百分比。蓝线显示每个版本中实际上是父方法的更新方法的百分比。

如果存在波纹效应，则蓝线应高于红色。

图2：父更新占每个Maven版本中所有更新方法的百分比。