主页

索引

模块索引

搜索页面

复杂度

  • 研发效率的大幅降低,其中一个核心因素就是软件复杂度的指数上升。

  • 软件复杂度分为本质复杂度(Essential Complexity)和偶然复杂度(Accidental Complexity)。

  • 软件本质复杂度,指的就是来自问题域本身的复杂度,除非缩小问题域的范围,否则是无法消除本质复杂度的。

https://img.zhaoweiguo.com/uPic/2022/03/L5WF5I.jpg

软件工程要解决的一个核心命题,就是如何控制复杂度,以让研发效率不至于下降的太厉害,这是一场对抗软件复杂度的战争。

面对效率下降,最常见的错误应对方式是设置一个不可更改的 Deadline,用来倒逼研发团队交付功能。但无数经验告诉我们,软件研发就是在质量、范围和时间这个三角中求取权衡。研发团队短期可以通过加班,牺牲假期等手段来争取一些时间(长期加班实际有百害无一利),但如果这个时间限制过于苛刻,那必然就要牺牲需求范围和软件质量。当需求范围不可缩减的时候,唯一可以被牺牲的就只有质量了,这实际就意味着在很短的时间内往系统中倾泻大量的偶然复杂度。

https://img.zhaoweiguo.com/uPic/2022/03/EDB6FC.jpg

地图中的每个组件可以被理解成一个软件模块,纵坐标是价值方向,越往上越靠近用户价值,横坐标是进化方向,越往右越靠近成熟商业产品。如:Compute 是计算资源,在今天有许多成熟的云计算公司提供,但它离图中上下文业务的用户价值非常远。Virtual Fitting(虚拟试衣)则离用户价值非常靠近,因为它可以让用户更有信心自己是否购买了合适的衣服,但是这个技术显然还谈不上是成熟产品,只是自己研发的模块,远没有达到开放商业化的阶段。其左上角(贴近直接用户价值,不成熟)都必须是要自己研发和承担复杂度的,而只要做好正确的软件架构,那么就能把右下角的部分(远离直接用户价值,有现成商业产品)提取出来,直接购买。

优秀的代码应该是:

1. It works
2. It is easy to understand
3. It is safe to change

备注

除了控制复杂度之外,软件工程师必须明白及时质量反馈的重要性。核心是质量反馈,这个反馈时间越短,效率就越高,反馈时间越长,效率就越低。

软件研发的核心职责之一是关注软件复杂度,通过开放代码、文档,Code Review 等方式让软件复杂度的信息透明,并且让所有在增加 / 降低复杂度的行为透明,并且持续激励那些消除复杂度的行为。唯有如此,在微观层面的控制复杂度的方法才能得到落实。

参考

主页

索引

模块索引

搜索页面