通过添加更多解决软件问题

这是一个星期六早上。我正在看youtube＆amp;在YouTube上看到了这个视频。

几周前，我在我们的一个产品中修复了一个小边缘案例错误。即使在开始解决问题之前，我也知道它将是一行代码更改。所以我做了这个修复程序和amp;第二天来到QA报告，因为那一行改变我所做的，我介绍了4个边缘案例，导致一些不一致。然后我开始将这些问题逐一修复，几个小时后我设法修复了所有内容，但对现有结构有几个更改。其中一些新的局部变量，为方法添加了一个可选参数，添加了一个新状态。

我开始思考是值得所有这些新的补充和amp;增加了一个小边缘案例错误的复杂性。几分钟后，我正在考虑与产品团队进行谈判，而不是解决初始边缘案例。因为它不是一个关键的错误和amp;只导致UI不一致。

然后我重新审视了初始错误＆amp;从头开始开始。因为现在我知道如果我做一行改变，它会介绍一些更多的边缘案例，我采取了不同的方法＆amp;在不引入任何边缘案例的情况下，管理初始错误。最重要的是没有新的局部变量或方法参数更改或新状态。我继续考虑那天发生的事情和amp;即使它最终结束了，我就有很高的机会，我可以通过所有额外的变化来实现，没有意识到有更好的方法。所以当我今天早上看了这个YouTube视频时，我知道这与我发生的事情完全相同。我继续建造更多的碎片而不实现拆卸第一件是更好的解决方案。

因此，我们可以将这种脑功能联系在软件开发中添加碎片而不是删除碎片。例如，存在这个库A，它在执行XYZ时比我们正在使用的当前库B很多。所以我们开始使用图书馆A＆amp;实现图书馆A的一个缺点是执行ABC动作的速度比图书馆B慢。因此，我们介绍库C以优化它。有案例仍然遵循这连锁利尼斯总体。但是可能还有其他可能的解决方案，而不是继续添加新图书馆。大多数时候我们错过了这些选择，因为我们喜欢添加东西而不是去除。

另一个例子我可以想到（有些人不同意这个），年前我们希望我们的Web应用程序动态地呈现HTML＆amp;每次用户转到新页面时不想刷新整个页面。因此，我们继续建立我们的前端框架，十年后，我们加载了十万行的JavaScript来前端为Web应用程序运行顺利＆amp;上帝知道他们的所作所为。