很受启发，没有足够的全局视角，设计出来的架构肯定是有局限的。具体业务里，就是因为不知道修改这个功能会影响到哪里，要加各种兼容逻辑，时间长了代码非常冗余复杂，ifelse 看的头痛

说那么多有啥用，国内只重视赶需求，功能越来越臃肿，哪有那么多时间搞重构

为什么代码越写越难维护？代码屎山是怎么来的？业务系统的复杂性究竟是怎么回事？

这篇文章是鹅厂内部 2023 年度收藏 TOP 1 的文章，我读完后受益匪浅，分享给大家。

作者关于业务系统复杂性的思考非常深入，文字娓娓道来，有理有据。无论你是写业务代码还是做基础设施，相信读完这篇文章，对于提高你的技术视野会有很大帮助。

文章有点长，但干货很多。需要耐心阅读，以下为正文。

过去一整年我都一直在思考「业务系统复杂性」这个问题。

其实对这个问题，从我开始工作就有不断地思考，不过这些思考大多在读完一两本软件工程或者软件架构的书之后就戛然而止。

因为书中那些高度抽象的概念以及似是而非的论点，总是让人觉得这个东西是玄学，好像说了什么，又好像什么都没说，你不知道它说得对不对，好像有道理但又好像脱离实际。

我依然非常清晰地记得去年的某个时候，Leader 曾跟我们谈过一次话：

我担忧的是，我们团队规模的扩张并不是因为用户规模或营收规模的增长，仅仅是因为我们有越来越多的事情要做导致人手紧缺。

这个担忧我相信很多人能感同身受，并且很多团队也正面临同样的问题。为什么用户规模或者营收规模不增加，但事儿却越来越多呢？

01 系统复杂性

这个现象的原因其实也不难想到：

由于业务规模停滞或者下滑，产品侧不得不做更多的事情来止住颓势甚至力挽狂澜。

要么是不断地拓展产品的边界，在一个应用里加入更多的功能，也就是所谓的交付更多的用户价值，从而吸引更多潜在用户。

要么是不断地优化现有功能，比如通过调整排版布局来从心理学角度提高用户停留时长和点击率，或者是进一步优化产品的交互流程，也就是所谓的提升用户体验，从而提升口碑稳固用户基本盘。