本质复杂性 偶然复杂性
如今，很难找到不遵循敏捷的团队或组织，但是构建软件并不容易，项目缺少进度，预算超支，而且存在缺陷。
为什么构建软件如此困难？
如果您向任何工程师提出此问题，那么90％以上的人会说要求，但这是全部事实吗？
让我们尝试分解软件结构。 每个功能都有2个重要的组件，可决定功能是否成功。
- 基本并发症（ec）
- 意外并发症（ac）
我们将做一些功能编程复习。
特征= f（基本并发症）+ f（偶然并发症）
本质上的复杂性来自领域，例如，如果您正在为医疗行业构建软件，那么它很复杂。 偶然的复杂性是工程师，过程和管理人员为构建功能而增加的复杂性。
由于域的原因，很难减少基本的复杂性，但是在某种程度上，可以通过使用良好的分解技术来减少复杂性。 分解是一项艰苦的技能，来自一些失败项目的实验。
偶然的并发症可以控制，但不是线性函数，偶然的并发症在系统的每个部分都不相同，并且随着时间的推移变得越来越复杂。 这也提供了有关我们作为工程师或产品团队所做的糟糕工作的反馈。
复杂性有多种形式，例如团队间的沟通，了解不足，难以重用某些功能，将程序扩展到新功能，管理问题等。
现在我们知道意外并发症是指数的，因此让我们再次编写公式。
特征= f（基本并发症）+ f（偶然并发症*未知）
现在将变得清楚，为什么某件事花费的时间比估计或猜测要长很多倍。 产品负责人还可以通过标记对功能重要性的假设来增加意外复杂性。
该怎么办？
如果我们需要某种可预测性或交付一致性，那么我们必须不断努力降低意外复杂性。 让我们看看保持这种状态的方法。
- 使用高级语言。
- 通过开发而不是构建软件来进行增量开发。
- 良好购买与构建决策。
- 统一编程环境。
- 突袭原型以完善需求。
- 听设计压力。
- 测试驱动的开发。
- 停止“摆脱困境”的心态。
- 减少交付过程中的“ 外科手术努力” 。
弗雷德里克·布鲁克斯（Frederic Brooks）非常有见地的报价，无论是客户还是工程师，都必须学习询问，期望和承诺的内容，否则，唯一的选择就是系统崩溃。
“承诺在两分钟内完成的煎蛋可能进展顺利。 但是，如果在两分钟内仍未设置，则客户有两个选择-等待还是生吃。 软件客户有相同的选择。 厨师还有另一种选择。 他可以调高热量。 结果常常是煎蛋饼什么也做不了，要烧掉，一部分烧掉。
― 小弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.），
神话般的月刊：关于软件工程的论文
必须为每个产品所有者，项目经理和工程师阅读布鲁克斯先生的《神话般的月》 。
如果您喜欢该帖子，那么可以在Twitter上关注我 。
翻译自: https://www.javacodegeeks.com/2019/11/complexity-accidental-vs-essential.html
本质复杂性 偶然复杂性
