本质复杂性 偶然复杂性_吻与本质复杂性

本质复杂性 偶然复杂性

从广义上讲，偶然的复杂性是开发人员添加到其代码中的复杂性，而对于代码的工作则不是必需的。 这可能包括工程过度，设计模式过度使用，工具，框架和范例选择不当，以难以理解的方式编写代码段。 例如，如果您可以使用简单的分层架构进行项目，则可以使用微服务（必须决定粒度，进行协调等）或消息驱动的架构（可以设置代理及其各种队列）的配置）不必要地增加了软件的复杂性，因此是偶然的复杂性。 如果您想解析XML并将其隐蔽到对象，则与xmo到对象的映射器（例如JAXB）相比，使用SAX会增加很多偶然的复杂性（希望添加一些注释）。 如果您的逻辑可以用几个lambda表达式来表示，但是相反，您要在其中包含if子句的情况下使用嵌套的for循环，那么这就是偶然的复杂性。 至少对我而言，偶然的复杂性是除了不了解得更多之外，没有充分的理由使其难以阅读，维护和部署。

另一方面，本质上的复杂性来自您尝试使用软件建模的世界。 如果要使软件适合实际使用， 就必须处理不可避免的极端情况 。 本质上的复杂性可以而且确实使您的代码更难阅读和维护。 它使它看起来像“旧版”代码，但是正如Spolsky所指出的那样 ，这就是事物的方式，也应该是它的方式。 意外的API调用，在实际使用半年后发现的一些异常情况下存在的类，您认为可以删除的ifs和fors –这些是真实软件的标志。

（我知道了偶然复杂性的另一种观点，即它仍然可以增加价值，但不是您要解决的问题。这是一个漫长的讨论，但是我认为任何本质上复杂且需要完成的事情（例如滚动更新）是必不可少的复杂性，即您不能没有它。）

如果您正在建模的业务流程有很多分支甚至是循环，并且无法进行优化，那么处理该业务流程的代码就必须“冗长”。 当您必须在可能会失去连接或连接不良的设备上运行软件时，可以随时重新启动该设备时，则需要重试代码，重新应用脱机步骤等的代码，即使庞大而又难以遵循。

但是是吗？ 难道我们对基本的复杂性无能为力，只能在那儿留下丑陋的代码，耸耸肩说：“好吧，我知道这很不好，但是，您可以做什么–基本的复杂性”。

好吧，我们不能摆脱它。 但是我们可以使其稍微友好一些。 我有两种具体方法。

记录需要复杂性的方案。 直接在代码中，或在代码中链接。 如果您知道其中存在的原因，大多数看起来像“ WTF”的代码看起来就完全符合逻辑。 如果我们通过解释其背后的商业原因来确保所有离奇的代码对每个人都有意义，那么我们已经解决了部分问题。

但这只是表面上的。 当涉及到本质复杂性时，我们真的可以遵循“保持简单，愚蠢”（KISS）的原则吗？ 是的，在一定程度上。 您不能使复杂性变得简单，但是可以以一种更简单的方式来表示它。 我们想要实现的是降低感知的复杂性，使其更易于遵循和推理。

首先要寻找的是您围绕基本要素引入的任何偶然的复杂性。 通常会发生这样的情况：基本的复杂性使偶然的复杂性更有可能出现，这可能是因为开发人员的所有重点都在于掌握他正在处理的方案的各个方面，而他却忘记了良好的做法。 但是，消除这一点也不足够。

具有讽刺意味的是，这里是常见的（设计）模式和特定框架很方便的地方。 您需要代表应用程序的复杂状态序列吗？ 使用有限状态机实现，而不是零零散散。 您需要代表一个复杂的业务流程吗？ 使用业务流程管理框架，而不只是流程控制结构。 您的类中有很多依赖项（即使您的类设计和打包都很好）？ 使用依赖项注入框架。 或在许多情况下–仅重构，我知道我的回答是最明显的事情，但是我们所有人都已经看到了复杂的方法，它们只会做很多事情，而不会遵循这种方法。 由于它随着时间而增长，所以没有人意识到它已经变得如此之大。

但是，除了几个例子之外，我无法给出一般性的规则。 降低感知的复杂性（显然）高度依赖于降低复杂性的感知。 但是，作为单行建议，请始终考虑如何围绕应用程序固有的基本复杂性重新排列代码，以使其看起来不太复杂。

翻译自: https://www.javacodegeeks.com/2015/04/kiss-with-essential-complexity.html

本质复杂性 偶然复杂性