业务系统的复杂性在哪里？
Leader：”我担忧的是，我们团队规模的扩张并不是因为用户规模或营收规模的增长，仅仅是因为我们有越来越多的事情要做导致人手紧缺。”
现象一：业务越不好活就越多
问题：为什么用户规模或者营收规模不增加，事情反而越来越多呢？
由于业务规模停滞或者下滑，产品侧不得不做更多的事情来止住颓势甚至想要以此力挽狂澜。要么是不断地拓展产品的边界，在一个应用里加入更多的功能，也就是所谓的交付更多的用户价值，从而吸引更多潜在用户；要么是不断地优化现有功能，例如通过排版来从心理学角度提高用户停留时长和点击率，亦或是进一步优化产品的交互流程，也就是所谓的提升用户体验，从而提升口碑，稳固用户基本盘。这些要做的事情对应到开发侧，那自然就是有更多的需求。
现象二：增效比降本难的多
降本，就是减少不必要的浪费；比如更精细化地使用服务器和存储资源，该省的省。
降本手段在短期很有用，但很快就会达到收益天花板，更大的收益还是要提升效率。
说的增效，大多数人首先想到的就是工程效能（EP），比如利用各种各样工具、服务来提升开发、部署的效率。
最终目标让程序员可以专注于业务的开发，但问题是，在整个软件的开发中，到底是业务开发工作量的占比高，还是非业务开发工作量占比高？实际上，只靠工具提效是远远不够的，还需要关注业务本身。
最终。不管基础设施多么优秀，业务代码依然是屎山。然而帮助公司赚钱，给大家发工资、发奖金的，就是这些屎山代码。
业务系统复杂的根因
功能之间隐蔽增加耦合
随着时间推移，大家还是会发现代码改起来越来越痛苦——总会牵一发而动全身，或者明明是修改功能 A，却不得不关注功能B是否受影响。这是为什么呢？答案就是“耦合”。
很多时候不合理的耦合是万恶之源。但是耦合又是不可避免的。当系统变得复杂，功能之间一定会逐渐产生耦合，它们的关联关系也会变得复杂。相信我，你总会在某个时刻，因产品的某个需求，总会将原本设计之初毫不相关的概念关联在一起了，慢慢的在此之上再建立关联关系，任谁在系统设计之初也不可能在架构层面满足未知的需求。
这些无意间引入的耦合，会给后续所有的需求开发增加一些额外的负担。到项目后期，每新增一个变更，除了修改这个变更本身，可能还要修改和它耦合的n+1 个位置。因此，建议在做新需求时，还必须考虑它和一些旧的特性怎么结合。
这些是技术架构不合理或者代码写得不好导致的吗？显然不是，这就是随着产品功能不断叠加，功能复杂度天然带来的耦合导致的。 没有办法通过软件上的优化来消除这种复杂性，工程上的任何架构或者设计模式的引入，只会把复杂性从一个位置转移到另一个位置，但永远不会消失。即使你认真的进行架构设计去拆分模块，这种耦合也是难以避免的，随着产品功能的迭代，组合模块这件事复杂性就会导致耦合的产生。
不可避免的代码腐化
腐化除了来自开发者低质量的代码，更核心的是来自于系统架构的腐化。由于架构设计和模块抽象只能面向当下，它天然是短视的或者说是有局限性的。这种局限性即使是最优秀的架构师也是无法逾越的。
目前互联网公司，通常采用敏捷开发流程，简言之，就是小步快跑，先做最重要的部分。要注意的是，敏捷开发并不会提高开发效率和交付速度，甚至它会更慢。因为这种开发方式缺失了对整体目标的把控，设计上天然有欠考虑的地方，后期要改就得花更多的成本。但是其优势在于，它能够快速捕捉市场机会，先让自己活下来，活下来才有机会谈成本，再找到性价比高的地方去优化。
何为“中华田园敏捷开发”？
虽然在流程上和国外提倡的敏捷开发存在较大差异，可以称之为“中华田园敏捷开发”，但确实也是敏捷开发。现在互联网公司基本上都是快节奏的发布，做App 都是先发 MVP 版本，然后再持续优化。每个迭代，产品经理都是只提几个有限的需求，开发也只开发这几个需求就上线。然后就进入不断堆功能的小步快跑阶段，缝缝补补又一年。产品经理也会用各种方式尝试去识别功能的收益，埋点、报表、同比环比等等。
敏捷开发中架构设计总是短视的。
在“中华田园敏捷开发”的这种开发方式下，需求本身就是零散的，目标也是模糊的。在没有全局视图的情况下，架构自然就是有局限的，只能适应当下。这也是为什么前面说架构设计和模块抽象只能面向当下，它天然是短视的。这不是人的问题，这是开发方式的问题。如果意识不到这个问题，后续在这种失效的架构上进行任何修修补补和魔改可能都会进一步加剧它的腐化，导致代码更难以看懂。
盲目追求复用，可能适得其反。
有些“可复用的能力”就像你免费获得了一只可爱的小狗，在收获短暂的快乐后，你需要各种铲屎、各种照护。到底快乐多还是负担多，就看你是不是爱狗人士了；而那些在设计之初就没有经过精心考虑的“通用系统”，对于用户来说，要用只得捏着鼻子用，后续要改动加功能还很困难。建议各位开发者在想着做“通用”的时候，先想想自己的“通用”指什么、边界在哪里？当然也不是所有的系统都是短视的。业界也有很多复用性很好的系统，例如 ERP、CRM，以及云上各种 Saas Paas。要注意的是，它们都是面向特定场景的产品，有明确的边界，只有这样它们才能在内部进行充分的建模，从而构建出符合特定场景的通用产品。
