推荐软件工程好文：《对抗软件复杂度的战争》

作者许晓斌是阿里技术专家，《Maven实战》作者，很多见解都很有深度。

研发效率下降的背后，核心因素是来源于软件复杂度的上升。

作者借用《人月神话》的论述，将软件复杂度分为本质复杂度（Essential Complexity）和偶然复杂度（Accidental Complexity）。

本质复杂度，指的就是来自问题本身带来的复杂度，比如用户规模过大，技术难度很高；而偶然复杂度则来源于解决方案本身，例如你选择的技术带来的，比如你选择某前端需要去学习，选择了某分布式框架引入了复杂度，还有团队成员的工程管理、项目管理等等。

而要解决复杂度带来的问题，应对方法不对可能会治标不治本。

比如常见的一个错误方式就是设置不靠谱切不可更改的Deadline，即使靠加班和缩小需求范围也无法达成，最终只有牺牲软件质量，反而是大幅提升了偶然复杂度。

还有一种错误方式就是用所谓“先进”技术，例如微服务，或者某个新出的前端框架。但如果你面临的问题从业务的角度来说，正好是这种先进技术所能弥补的，那么没问题，但如果你的问题是研发效率问题，先进技术不仅不能帮忙，还反而因为新老技术切换带来更多的偶然复杂度。

那么什么是正确的应对方式。

一种方式是宏观层面。

将一些复杂的系统，分离出去，通过购买或使用第三方成熟系统来降低复杂度，例如数据库、调度系统、消息队列等等。

通过对系统架构和组织架构的调整，将系统的复杂度层层分解，将复杂的系统拆分成相对简单的模块，同时组织架构和系统架构保持一致。

一种方式是微观层面，提升代码质量、增加单元测试的覆盖，并且从团队的流程、工程文化上下功夫，借助好的流程，例如CI/CD和代码审查；激励消除复杂度的行为；让增加、降低复杂度的行为透明。

我觉得文章中提出的复杂度问题都是很现实的问题，从宏观和微观两个层面入手也是很好的思路，但还是需要根据团队的情况自己调整。

推荐阅读原文：
https://t.co/bpsjv0ZCgi

#软件工程之美

点击图片查看原图