不安全驱动的发展

有观察表明，某些软件想要解决的问题越容易-其架构越复杂。 从学者到网络开发，我一直在多个领域工作，我可以肯定这是普遍的。 在我目前的工作中，我使用相当复杂的算法，并且对所有事物的唯一模式感到非常满意。 但是在我以前的工作中，我不得不处理一个怪异的14K SLOC，即所谓的数据提供程序，该数据提供程序旨在将一部分数据从一个内存区域移动到另一个内存区域。 不用说，它是99.9％的体系结构和0.1％的memcpy 。

就像有某种“舒适的复杂程度”，人们感到不舒服的事情要比这简单。

如果您的问题本质上很复杂，例如浮点数中的3D布尔运算，那么您就将所有的认知能力用于避免数字问题和算法不一致。 您不希望事情变得比现在复杂。 但是，如果您要做的事情与从配置文件中读取参数一样琐碎，那么您就不能只读取文件并找到基准。 您需要词法分析器，解析器，词法分析器的适配器以使其能够与解析器一起使用，需要读取值的处理程序以及将该处理程序推送到解析器的委托。 哦，您需要一个供处理程序使用的工厂。 解析器也应该是单例。

好吧，不应该。 并不是说解析器不应该是单例的，在大多数情况下，您根本不需要解析器。 整个解决方案不应该那么复杂，读取简单数据本质上就很简单。

我不知道怎么来的这常常是这样，但是我有一个理论。 我原本打算在这里写“总是”，但是我看到了一些幸运的例外，所以我写了“经常”。 问题是，这些例外有一些共同点。 它们都是由极其自信的程序员编写的。

我的理论是，编程中意外复杂性的主要来源是不安全性。 人们只是没有足够的自信来编写简单的代码。

当您掌握了模式和实践后，就不必对结果承担任何责任。 没有人因为跟随GoF而被解雇。 只做非常简单的事情就是有风险的。

如果我从文件中读取了UserName ，但是方案发生了变化，突然出现了NameOfUser怎么NameOfUser ？ 那会出什么问题呢？ 好吧，如果我使它可配置，那么这不再是我的责任。 我将为此编写一些代码，并添加几个依赖项，并考虑一些没人会关心的数据结构。 无论如何，这不是一个好习惯吗？

该代码比写回去要容易得多。 因此，是的，虽然通常使您的解决方案可配置是一种好的做法，但不一定适合每种情况的最佳解决方案。 如果该计划在未来十年内保持不变，该怎么办？ 或者，如果它在2027年发生一次更改并且需要您编辑一行代码以使其在未来十年内运行，该怎么办？ 我肯定会喜欢一种由于其简单性而可扩展的代码，而不是一种通过添加更多代码而被编写为可扩展的代码。 如果每当一位建筑师像十年前一样每次预测扩展都会得到一美元，我就会得到一美元（嗨，Wout！）

并不是像有一盒现成的决定，但是大师和传道者都希望您思考。 有时您必须选择复杂性，有时则不必。 矛盾之处在于，您无法撰写有关选择简单性的书。 您不能在会议上发表演讲。 这将是一个不合适的简短谈话，而且一页书也不是很好卖。 因此，当您感到不安全时，根本无权支持使事情变得简单的决定。

编写简单的代码需要信心。 我不能帮你。 但是也许我可以保证。 如果您觉得自己的工作很简单，请要求我进行独立的代码审查。 我的下班电子邮件是[email protected] 。 我每隔一个周末有空，所以可以尝试一下，好吗？

From: https://hackernoon.com/insecurity-driven-development-63055b943088