前言

伟大的思想家们知道如何将复杂的世界简化为一个单一的、有组织的想法 — 一种统一、有组织、指导所有决策的基本原则。减少复杂性，将事物简化为简单而深刻的想法，是很多具有敏锐洞察力和深刻理解力的思想者们一直努力进行的尝试 ，诸如爱因斯坦的相对论，牛顿的万有引力，亞當·史密斯的看不见的手，和达尔文的进化论。所以，在保证事物完美运行的同时减少其复杂性，一直是我们需要重点关注的议题。如何去做到呢？有一种可能有效的方式是：定期对现有状态进行重构。我们将力求使这一观点可以拓展于适组织，产品，甚至个人生活的方方面面。

案例

工作的时候，同事用一句话激起了我极大的兴趣：昨天，我使用几十行代码代替了一万行代码。理所当然地，我们都想知道他是怎么做到的。以下是他分享的分析过程：

现状和问题

项目中针对这个特定功能采取的是比较灵活和细分的逻辑和层级结构，这样可以方便团队协作和编辑代码。然而，随着产品功能的逐步拓展，在代码协作的过程中，由于任务的时限紧迫，每个工程师在编辑代码时仅会关注与单次任务相关的代码，而这种做法导致：
（1）系统出现大量重复的功能和雷同的代码；
（2）代码之间的层级结构太深；
（3）代码之间相互调动过于频繁，形成千丝万缕的网状结构，不便于修正和管理（容易出现bug）。

方案

对于现有代码（特定功能单元）的代码进行重构，以最精简必要的代码代替臃肿冗余的代码。

反思

在项目拓展开来的过程中，当复杂度达到一定规模时，需要对当前的事物进行梳理、整理，必要的话，针对整体或局部进行重构，以恢复保持事物正常运行的最精简状态。这样做的好处是，可以使得业务/产品/其他一直保持轻量、易于管理的状态，在外界环境改变时（如增加新的功能需求），由于体量较为轻盈，可以迅速适应外界环境，找到最好的生存之道。如果当复杂度达到阈值的时候任由其发展而不做任何干预，只会使得整体变得越来越臃肿肥胖，且复杂度会呈指数级增加，不仅不便于监控和管理，在外界环境发生改变时，也无法做到及时有效的反馈从而导致被竞争者淘汰。

画板.png2.png

现实的挑战

然而，由于现实中需要考虑的变量因素非常多，往往会导致理论与实践之间存在差距，甚至完全无法将理论付储实践。同样的，针对定期降低复杂度的议题，也有许多挑战：
（1）精简步骤需要投入成本，而这段投入期间将不会有任何实质性、明显的收益，甚至在精简任务完成之后也无法看到这个行动带来的直接的对于商业利润的积极影响。因此，如何说服领导者们去支持这项行动？
（2）精简意味着暂停，然而原业务仍然需要稳定的商业表现。旧模式与新方案如何共存，以保证渐进式地稳定迭代而非暂停后的突变？
（3）任何一次重要决策都有巨大的风险，如何规划以保证风险属于可控范围内？
（4）谁会愿意承担这份优化的风险？如何去衡量风险和获益？