复杂性偶然与本质

如今，很难找到不遵循敏捷的团队或组织，但是构建软件却变得不容易，项目缺少进度，预算超支并且也存在缺陷。

为什么构建软件如此困难？

如果您向任何工程师提出这个问题，那么90％以上的人会说要求，但这是全部事实吗？

让我们尝试分解软件结构。 每个功能都有2个重要的组件，可决定功能是否成功。

• 基本并发症（ec）
• 意外并发症（ac）

我们将做一些功能编程复习。

特征= f（基本并发症）+ f（偶然并发症）

本质上的复杂性来自领域，例如，如果您正在为医疗行业构建软件，那么它很复杂。 偶然的复杂性是工程师，过程和管理人员为构建功能而增加的复杂性。

由于域的原因，很难减少基本的复杂性，但是在某种程度上，可以通过使用良好的分解技术来减少复杂性。 分解是一项艰苦的技能，来自一些失败项目的实验。

偶然的并发症可以控制，但不是线性函数，偶然的并发症在系统的每个部分都不相同，并且随着时间的推移变得越来越复杂。 这也提供了有关我们作为工程师或产品团队所做的糟糕工作的反馈。
复杂性有多种形式，例如团队间的沟通，了解不足，难以重用某些功能，将程序扩展到新功能，管理问题等。

现在我们知道意外并发症是指数的，因此让我们再次编写公式。

特征= f（基本并发症）+ f（偶然并发症*未知）

现在将变得很清楚，为什么某件事花费的时间比估计或猜测要长很多倍。 产品负责人还可以通过标记功能重要性的假设来增加意外复杂性。

该怎么办？
如果我们需要某种可预测性或交付一致性，那么我们必须不断努力以减少意外的复杂性。 让我们看看保持这种状态的方法。

• 使用高级语言。
• 通过开发而不是构建软件来进行增量开发。
• 良好购买与构建决策。
• 统一编程环境。
• 突袭原型以完善需求。
• 听设计压力。
• 测试驱动的开发。
• 停止“摆脱困境”的心态。
• 减少交付过程中的“ 外科手术努力” 。

弗雷德里克·布鲁克斯（Frederic Brooks）非常有见地的报价，无论是客户还是工程师，都必须学习要问，期望和承诺的内容，否则，唯一的选择就是系统损坏。

“承诺在两分钟内完成的煎蛋卷似乎进展顺利。 但是，如果在两分钟内仍未设置，则客户有两个选择-等待还是生吃。 软件客户有相同的选择。 厨师还有另一种选择。 他可以调高热量。 结果常常是煎蛋饼什么也做不了，要烧掉，一部分烧掉。
― 小弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.），

神话般的月刊：软件工程随笔

必须为每个产品所有者，项目经理和工程师阅读Brooks先生撰写的Mythical-Man-Month 。

如果您喜欢该职位，那么可以在Twitter上关注我 。

翻译自: https://www.javacodegeeks.com/2019/11/complexity-accidental-vs-essential.html