复杂度¶
研发效率的大幅降低，其中一个核心因素就是软件复杂度的指数上升。
软件复杂度分为本质复杂度（Essential Complexity）和偶然复杂度（Accidental Complexity）。
软件本质复杂度，指的就是来自问题域本身的复杂度，除非缩小问题域的范围，否则是无法消除本质复杂度的。
软件工程要解决的一个核心命题，就是如何控制复杂度，以让研发效率不至于下降的太厉害，这是一场对抗软件复杂度的战争。¶
面对效率下降，最常见的错误应对方式是设置一个不可更改的 Deadline，用来倒逼研发团队交付功能。但无数经验告诉我们，软件研发就是在质量、范围和时间这个三角中求取权衡。研发团队短期可以通过加班，牺牲假期等手段来争取一些时间（长期加班实际有百害无一利），但如果这个时间限制过于苛刻，那必然就要牺牲需求范围和软件质量。当需求范围不可缩减的时候，唯一可以被牺牲的就只有质量了，这实际就意味着在很短的时间内往系统中倾泻大量的偶然复杂度。
地图中的每个组件可以被理解成一个软件模块，纵坐标是价值方向，越往上越靠近用户价值，横坐标是进化方向，越往右越靠近成熟商业产品。如：Compute 是计算资源，在今天有许多成熟的云计算公司提供，但它离图中上下文业务的用户价值非常远。Virtual Fitting（虚拟试衣）则离用户价值非常靠近，因为它可以让用户更有信心自己是否购买了合适的衣服，但是这个技术显然还谈不上是成熟产品，只是自己研发的模块，远没有达到开放商业化的阶段。其左上角（贴近直接用户价值，不成熟）都必须是要自己研发和承担复杂度的，而只要做好正确的软件架构，那么就能把右下角的部分（远离直接用户价值，有现成商业产品）提取出来，直接购买。¶
优秀的代码应该是:
1. It works
2. It is easy to understand
3. It is safe to change
备注
除了控制复杂度之外，软件工程师必须明白及时质量反馈的重要性。核心是质量反馈，这个反馈时间越短，效率就越高，反馈时间越长，效率就越低。
软件研发的核心职责之一是关注软件复杂度，通过开放代码、文档，Code Review 等方式让软件复杂度的信息透明，并且让所有在增加 / 降低复杂度的行为透明，并且持续激励那些消除复杂度的行为。唯有如此，在微观层面的控制复杂度的方法才能得到落实。
参考¶
【阿里】对抗软件复杂度的战争：https://mp.weixin.qq.com/s/Dil5Ual1aI_7dsGKV0f6Ig