一、一个让我坐在食堂里想了很久的中午
前阵子中午吃饭，我拿起手机看了下公司群的消息，有一条让我很震惊。
公司表扬了一个技术攻关项目里的人员------有硬件的，有测试的，唯独没有软件。
我第一反应是不对劲，直接找攻关负责人问：一个产品的技术攻关，怎么会没有软件的人？那它还算个产品吗？
我又把疑问转给了老板，他回了我一句："确实没看到软件有什么动静"，然后劝我别激动。
我当时回了：不能这么说。如果没有软件的修改和调参，不可能达到现在的效果。
我坐在食堂里想了很多。
这个攻关已经不是第一次了，前前后后历经一两年。最初的状态是------距离稍远就卡得没法用。现在做到了流畅稳定。中间软件那一部分，恰恰是我做的。
而我做的事情是什么？是分析出问题的几个方向，是在其中一端做重连机制，是调参数，是判断某个功能应该放在哪一端改。最后的改动很小。
小到"没看到软件有什么动静"。
委屈和愤愤不平涌上心头。但冷静下来之后，我觉得有必要好好捋一下自己，捋一下这个事件背后，关于软件的认知。
二、我为什么会走上架构这条路
我工作很多年，也换过一些公司，但有件事始终没停：思考和学习。我也没有停止追逐内心的那个目标------成为一名优秀的架构师。
想成为架构师，是源于中间那家工作了九年的公司。
在那里，我把 NVR 从 128 路提升到 200 路，把跨平台 NVR 从无到有重构出来。我第一次感受到自己具备了一定的架构设计能力------我觉得可以往这个目标冲了。
当时我已经认识到：重构最重要的是思路和模块化，而思路说到底就是抽象，抽象就是把各种表象找到规律、提炼出来。 C++ 面向对象的核心之一，也正是抽象。
于是我在重写回放模块的时候，系统地使用了虚拟继承，把这个思想贯彻下去。带来的结果是------后来要加"即时回放"这个功能时，变得非常简单、非常自然。
而在这之前一年，我维护老版本（只支持单一系统的）NVR 时也加过类似功能，那个痛苦劲儿至今还历历在目------牵一发动全身的那种。
前后一对比，我真实地感受到了：设计有多重要。
三、那句话，让我把零散的想法串成了一条线
从那家工作了九年的公司出来后，我在网上学习，也找过架构师的培训课程。有一家大数据云计算机构抛出了这么一句话：
优秀的架构师把复杂问题简单化，把简单问题解决掉；反之，拙劣的架构师把简单问题复杂化，复杂问题把自己给解决掉。
我一下子就 get 到了其中的精髓------不就是化繁为简吗？
这不正是验证了我之前的所思所想吗？
思路进一步打开后，我一方面跟着他们学习 Kafka 开源库的设计思想，另一方面开始有意识地研究 MySQL 的实现，写了一系列总结博客，其中《MySQL InnoDB 技术内幕：内存管理、事务和锁》就是探秘内部原理的。
写那篇总结时我非常兴奋，因为我的软件认知又升华了一个档次 。为什么要死磕 MySQL？一方面我的 NVR 重构用了它，另一方面它的优秀早有耳闻------想搞清楚它为什么优秀，就得学它的精髓。
后来我如愿去了一家科技公司当架构师，师从一位从腾讯出来的架构师，从理论上又升华了一次。当时做得最多的就是画架构图。那位主管兼导师说得最多的一句话是：
未来无论你们去哪里、做什么工作，都不要忘了架构的思维。
四、回到开头那个疑问
后来我又回到了安防行业，也回到了文章开头那个疑问：我到底做了什么没有？
我想通过前面的唠叨，答案应该很简单------
我肯定做了事情。只是我做的事情是化繁为简，简单到最后，领导以为我没有动静。
这恰恰说明了：架构的重要性，设计的重要性，思路的重要性。
五、那化简为繁又是什么？
化繁为简是设计阶段的事，那执行阶段呢？
时间拨回到去年，我们需要做一个新形态的客户端，开始找第三方合作，进展很慢。可我们内部一直说这个简单------因为主体产品都出来了，Web 端、APP 端都已完成，接口早就定义好了。
那为什么还这么慢？
我反思后突然意识到：我们就是因为它"太简单"，而轻视了。
于是我反馈给领导：战术上一定要重视，一定要分解。
这就是开发时要做的------化简为繁：
-
每个功能模块要分开想，该怎么具体实现
-
关键点在哪儿
-
真正需要关注的细节在哪儿
-
哪些细节容易出问题
-
要反向思考
六、两者的关系：一个硬币的两面
写到这儿，我想把这件事讲透。
化繁为简，是设计阶段的能力------面对一堆混乱的表象，抽象出结构，找到规律，定下层级。产出是：一个判断、一个结构、几行关键改动。
事实上，很多公司的架构师，就是接口定义，即接口开发工程师。如果你能把模块接口都定义出来，也就是对产品功能理解透彻。我在最近一家做某个业务模块时也是这样的，把接口写好了，实现就交给了小伙伴。
化简为繁，是执行阶段的能力------面对一个看起来简单的任务，反过来把它拆开，把细节想透，把风险前置。产出是：一份分解清单、一堆被提前发现的坑。
它们不是对立的，是同一个人需要的两种能力，甚至是一件事的两个阶段。
先化繁为简，才知道劲该往哪儿使；再化简为繁，才知道这一脚踩下去会不会塌。
七、为什么化繁为简的人最容易被低估
这是我最想说的一段，也是我坐在食堂里想明白的。
因为这两种能力的产出，"可见度"完全不同。
-
化简为繁的产出是看得见的：分解清单、讨论记录、改了一堆问题、忙了很久
-
化繁为简的产出是看不见的：它最后只留下"几个参数的调整""一个否决""几行改动"
于是出现一个残酷的等式：
你把难事做简单了，别人就以为这事本来就简单。
而"想清楚"那一段，不留痕迹，不产生提交记录，无法被度量。它发生在你坐在食堂的时候，发生在你散步的时候，发生在你盯着现象发呆的时候。
更残酷的是：化繁为简做得越纯熟，这个效应越明显。 新手要改三天，你改三行------反而是你显得更不重要。
我想了很久怎么破，目前有三条：
第一，把"想"的过程留下来。 文档、评审记录、方案对比。不是为了邀功，是为了让认知成本变得可见。我很庆幸自己早年养成了写博客和写专利的习惯------它们在我说不清的时候，替我说了话。
第二，把结果量化。 "优化了无线"没有力量，"从卡顿到流畅、稳定性提升数倍"才有力量。认知价值必须翻译成别人看得懂的单位。
第三，别等别人来发现。 等待是最差的策略。要么自己讲出来，要么找一个看得懂的地方。
八、写在最后
化繁为简是慢功夫。因为"想清楚"这一段，看不见、说不清，也没人给你计时。
但它是唯一不会返工的路。
我在《如何做到慢即是快》里写过，慢不是目的，不返工才是 。这篇算是它的续篇------所谓慢，很多时候就慢在这里：你花在"想清楚"上的时间，跟别人花在"反复改"上的时间其实一样多，只不过你的那一段没人看见。
另外，把我那篇《自以为是与思考》也一并推荐。化繁为简最大的敌人 不是技术难度，是自以为已经想清楚了。
而对执行者来说，化简为繁最大的敌人同样如此------自以为很简单，于是掉以轻心，于是轻敌，于是进度一拖再拖。
一个提醒自己多想一层，一个提醒自己多拆一层。
多想一层再动手，多拆一层再下手。