今天去听了一天的“工程效率”专场交流会。这次交流会邀请了Facebook, Amazon，Pintrest及上海几个知名大厂的工效团队负责人坐台。给大家分享了一下他们经历，方案及对于“工程效率”的见解。
整场交流会还是蛮成功的，尽管台下的听众只有几十人且一点儿都不活跃。参会嘉宾们讲的东西还是比较有诚意的。先从工程效率所解决的问题入手，从工具，理念，协同，流程，技术等方面的展开了分析与对话。该讲的基本都讲到了。有几个主要观点我是非常认同的（虽然并没有什么新观点，基本都是大家已经知道的东西）。
- 工程效率的本质，是解决复杂度问题，化繁为简，提高效率。
- 善用工具并且能把各个工具有机地串联起来，一提高工作效率的有效手段之一。任何需要被做两次以上的事儿，都值得自动化起来，避免低效的手工执行，但是又要避免过度自动。什么是过度自动呢？我的理解是判断都自动化就过度了。判断应该由人来做，判断好之后的处理，手工触发，自动执行，以免误伤。
- 工程效率要落地。可以以两个方面入手：
- 找到合作方，积极合作，共同推进。
- 找到真实的业务痛点（即使他们自己都不知道），并解决问题，提供价值。要以做产品，提供服务的心态来做工程效率。
- 工程效率不是一个技术问题。而是融合技术，人员与流程的综合性问题。我个人还想加上业务。因为业务不同，对效率的改进点的需要也是不一样的。
- 对于工程实践上的问题，没有银弹。不存在这样一个方案：每个公司拿去就能化腐朽为神奇创造奇迹。因为每个公司的成熟度是不同的，所适合的工程实践也会大相径庭。把一个公司跑得好好的方案照搬过来，跑不通还算好的，不好的是反而会产生严重的负面影响。每一个方案，必须是因地制宜地、因人而异的。
- 软件工程，与传统工程是非常不一样的。传统工程，做完就是完工了。而软件工程，做完只是开始，一个软件，从出生到消亡，始终都在发生变化。从外部的需求，到内部的技术方案，再到参与的人员，全部都是在持续变化的。
- 提高效率，要从最薄弱的环节入手，把瓶颈找到。有针对性地解决问题。
- 技术开放，以赋能扩展能力，而非以规范约束能力。
- 每个公司间的文化不同，但是同一个公司，要上下一致，形成共识。这样才能劲儿往一处使。
- 工程效率的度量指标，不应该被纳入KPI或ORK，更不要以此为团队做排名，因为很容易产生误导。
- 不要写那么多文档，没人看。重要的处置方案，直接内化成系统功能。
- 系统不是设计出来的，是演化出来的。
另外想补充一个比较有意思的现象，因为本次与会的嘉宾比较多，会出现这样一种很奇妙的碰撞。阿里中间件的李云老师前脚说，团队是培养出来的，不是招聘出来的。后脚许式伟就在另一个话题上，表示严把招聘关是非常重要的，因为人是不可塑造的，“基本上大学毕业是什么样就是什么样了。”他们说得其实都对。但是话，都是有上下文的，脱离了上下文，单独去看，甚至会有些自相矛盾。
我下面想讲讲他们没有讲的。点也比较多，我争取讲得有条理点儿。
- 关于“工程效率的本质是降低复杂度”的论题，我有一点儿补充。假定工程效率本身的范畴包括：CICD，自动化测试，设计规约，代码审查，开发流程，发布流程，团队协作，工具打通并平台化，最佳工程实践的推广及开源。那么工程效率本身其实并没有降低复杂度。而只是把复杂度遮盖起来，让人们看不到。而上面这此东西的引入，其实反而增加了实际的复杂度（尽管不可见）。在平时的软件开发工作中，真正需要被降低复杂度的部分，是人为的额外的复杂度。比如一个用四则运算可以解决的问题，用了微积分来描述与求解。其实是人为地增加了复杂度。而在真实的项目中，这部分的复杂度，其实是远超工程效率所涉及的部分的。比如服务间的不必要的耦合，接口设计不必要地暴露了内部实现并强绑定，都会带来不必要的复杂度。而且，这种复杂度，影响范围更大，不仅仅会影响开发效率，还会影响服务的稳定性，可扩展性等。
- 老板们讲“工程效率”，本质上是指：“从公司整体，最终业务的层面，用更少的资源（一切成本，如：人，时间），办更多的事儿。”。个体的效能高，不代表整体产出高。但是个体效能低，整体一般也高不到哪儿去。所以工程效率，一方面是提高单兵作战能力，但是更更重要的，是团队协同作战的能力及规划调度的能力。
- 提高做事效率是一方面。但是在此之前，更重要的是明确，我们正在做的这个“事”本身。是不是必要的，有价值的。不然效率再高，也是无用功，白白浪费宝贵的时间。具体指什么呢？从最简单的，个人及团队层面上，要保证每个人不重复造轮子，起码做到一个公司内部，不要有两个人在做重复的事情。当然，B计划除外。从产品与技术的协同的角度，产品前期做好必要的充分调研，避免不必要的反复或返工。总结下来就是，专门的人或团队，用正确的方式，充分利用现有资源，做一次，做到位，推广开。
我在会上还问了一个比较尖锐的问题，经济学上有一个原理，就是劳动分工是生产力进步的原因，那么现在DevOps所倡导的，开发即运维，同一个组织或个人负责服务的方方面面，是不是与这个原理冲突呢？
有位嘉宾解释得比较形像，DevOps就像是工厂里的流水线。这个比较还是很贴切的。
我自己当然其实思考这个问题很久了，并不是在会上突发奇想想到的，所以自己其实是有自己的答案的。
在我看来，DevOps不是一个纯粹的方法论，而是一套体系，有方法论，有工具，有相应的人员素质模型要求。DevOps并不是真的要求开发人员去按传统的运维人员的样子去实施运维。DevOps是构建在现代的虚拟化的自动化的运维体系与工具链之上，在让运维本身接近透明的情况下，消解了开发、运维的协作壁垒，让开发能专注开发而且对于服务有更高的控制能力，从而提高了整体工作效率。这恰恰是分工的进化而非倒退。单就运维工作本身而言，运维已经比过去的搬机器、拉网线、登跳板，传文件，换硬盘的传统运维有了云泥之别。已经失去了成为一个独立的职业的必要。有些公司，打着DevOps的旗号，又没有执行现代化运维的能力，仅仅是为了强迫开发同时做运维，以求省掉运维的开支。这种DevOps，才是那种反分工的伪DevOps。
