我之前写过一篇《加班与效率》的文章，从概念上讲了我对“效率”的理解，但是那篇文章偏概念化。对于处于这样环境中的学生来说，可能会觉得太抽象了。很久以前，想写一篇更具体、更可执行的文章来补充这篇文章《加班与效率》，特地补充《建一支强大的小团队》（新浪微盘）加强观点。但我的思考方式遇到了一些麻烦——我总是从我的经历背景出发，而不是从其他人的经历背景出发。就好比，我在酷壳里说了很多（比如：全职QA，CodeReview很重要，编程时代，创业，Rework...），有人觉得不可能甚至太理想化，其实我说的都是真的，我都经历过。所以，不同的经历，不同的环境，不同的眼光就造成了——有的人我讲的不明白，他们讲的我也听不懂。所以，在过去的一段时间里，一有机会，我就找一些人交流，观察身边的一些事情，努力去追随和理解那些自己无法理解的东西。现在觉得差不多了，所以写了这篇文章。（但越是了解对方，越是坚持自己的观点，所以本文可能还是会出现鸡鸭鸭讲的情况，没关系）本文不讨论任何业务效率问题，仅软件开发或软件工程中的效率问题。虽然产品和业务效率的问题是根本，但因为这篇文章不是仇恨，我也不想混为一谈，所以请原谅我在这里说了开发团队，我会重新开一篇文章来谈谈关于未来的产品和业务。下面我将列举几种非常典型的开发方式——软件开发中的“锁”、指挥棒式软件开发、保姆式软件开发、WatchDog软件开发、故障驱动软件开发。软件开发中的“锁”如果你做过并发编程，你一定知道什么是“锁”。锁用于同步和互斥。我发现几个开发部门的各个开发团队之间存在很多锁。例如：技术能力的锁定。有一个项目需要异地开发。这些模块使用不同的技术，例如：Java、C/C++、Python、Javascript。但是，这个团队的每个开发人员只懂一种语言，所以，需要协调，需要任务调度，还有很多同步互斥量。因此，一份原本只需要2人3周的工作变成了8人2个月。负责模块上的锁。同理，不同的人负责不同的模块，所以一个项目要搬很多模块，那么就需要找到这些模块的人，同上。每个人都有自己的日程安排，人越多，锁越多。结果，原来只需要2个人工作2个星期才能来一次，变成了7、8个人工作一个多月。我不是在胡说八道，都是真的。我们可以看到，时间锁，进度锁。这帮不同技能或者负责不同模块的开发者有锁。如果你有锁，你必须等待。他们有自己的安排。因此，要协作，您需要安排和同步。参与的人越多，你拥有的锁就越多。协调他们的时间对你来说更复杂。通讯锁，利益锁。而且，最可怕的是，他们之间的沟通成本是巨大的。他们会花很多时间讨论一个功能是你这边实现还是我这边实现。每个人都有自己的利益和算计。无形中增加了很多搪塞、官僚、政治的东西。有时，我们认为分工和子模块是效率的前提，但现实并非如此。我们也可以看到，所谓的“分工”被滥用得一干二净。他们以“分工”为借口，总是只做一件事。【解决】一个程序员应该能够掌握多种语言，同时负责多个模块甚至不同的职责。如果一个程序员觉得多学一门语言，多掌握一个模块都很难，那么这个程序员本质上是不合格的。“棒式”软件开发在一个有着各种“岗位锁”的软件开发团队中，一般都免不了开发“棒式”。也就是说，底层的C程序员完成工作后，会交给上层的Java程序员，再交给上层的前端程序员，最后交给运维人员。这是指挥棒发展。而且，更糟糕的是，如果引入软件过程，这种“接力棒方式”真的会让你崩溃。比如下游团队开发一个月，提交QA测试一个月，再提交运维一个月逐步上线。然后，上游团队拿到下游开发的API进行一个月的开发，然后提交给自己的QA测试一个月。然后交给自己的运维上线一个月，就这样半年过去了。这是一个由小瀑布组成的大瀑布。哦，你会说，这个好办，上下游不会先约定好接口吧？然后做并行开发？是的，这是优化之一，但它需要良好的界面设计。但是，在实际过程中，你会发现（我此时不是在说，我是在说实话），如果上下游两个团队在一起，好办，如果不在一起，那么实际情况是，后面的团队会等到前面的团队提交测试后再开始开发，本质上是串行开发。如果有更多的团队怎么办？比如：TeamA->TeamB->TeamC->TeamD，接口变得非常关键。现实中，因为没有好的界面设计师，在开发过程中频繁修改界面，或者因为界面不好用，我们不得不忍。【解决】我之前写过一篇文章，叫做《IoC/DIP其实是一种管理思想》。对于这种接力棒的方法，应该反过来。如果业务应用团队是A团队，那么B/C/D团队应该自己做开发框架，不管是面向服务的还是面向服务的，让应用团队自己去接入。比如：前端要做一个前端开发框架，PE要做一个运维开发框架和各种工具，共享模块团队要做一个开发框架，让应用团队自己去访问为他做这件事。你会发现，那么多团队各自的P2P混出来的非常随意的接口，成本已经远远超过一个统一标准协议的成本。“保姆式”软件开发所谓“保姆式”软件开发就是——我就是吃饭，不管做饭洗碗，就像一个“小皇帝”，伸开衣裳，张开衣襟吃饭的时候嘴里，围着一帮太监或宫女，否则生活不能自理。这种情况在开发和测试、开发和运维的关系中经常看到。在许多公司中，测试和运营已成为开发的保姆。我看到很多开发者快速写好代码后，基本上没有太多测试就交给QA测试。QA一旦测试，我马虎，各种问题，而只会做黑盒的QA，不能立马解决问题。可以判断是代码问题还是环境问题，所以需要花很多时间排除不是环境问题，然后再报bug给开发。很多问题可能做CodeReview和单次测试就发现了，必须交给QA。运维也是如此。开发的软件根本不考虑任何运维，因为有运维人员，所以不考虑。这与我们抚养孩子的原因相同。对于孩子来说，父母为孩子做的越多，孩子越觉得自己应该做，就越不会做。“保姆式”开发一般演变为“保安式”开发。因为你团队开发人员能力不行，设计不行，CodeReivew/UT也不做，你只能找一堆QA看他。因为Dev/QA只关心功能，不关心运维，所以你得找一堆运维人员看着他们。因为你的技术人员不懂业务和需求，你需要再找一个BA和一个产品经理来指导他。因为你的技术人员不会管理项目，再找一个项目经理，找一个敏捷教练，SQA来管理他。就这样吧，你做不到，我找人看你，看你的人不行，我就找人看你……层层保姆，层层安全。结果，你会发现团队或部门的人越来越多，你们整天开会，互相解释，互相争论，胡说八道的人越来越多。那是效率的屁。网上很经典的一张图，出处不明，程序员在挖坑，其他人都站着当监工【解决】1）不要招只会写代码的“码农”，招“需要”》，关注《软件工程》《软件质量》《软件维护》《工程师》。2）管理***不是找人管别人，而是管自己。3）组织机构和尽量少支持人的团队，绝对不是。4）服务化。我为你服务，不是说我要帮你工作，而是——我想让你的工作更愉快。我在微博上说了下面的话，（你可以体验一下保姆和服务的区别）运维应该用“云服务”的思路来做。如果一个公司的运维团队开发了一堆工具，应用开发团队就可以轻松申请到资源例如机器、存储、网络、中间件、security等，管理、监控和部署应用程序，并提供运营维度的资本咨询。而不是帮助应用开发团队当保姆。然后，这家公司会不经意地做一个云计算平台。“看门狗风格”软件开发什么是看门狗？也就是说——为了解决某个系统的问题，我将用一个新系统来看待它。我的系统架构太复杂了，出了问题很难发现。该怎么办？然后设置专门的监控系统。。。我的系统配置太复杂了，容易出错。该怎么办？然后添加一个配置验证系统...我的系统配置和真实情况有时可能不一致。该怎么办？然后加个巡更系统。。。我的系统测试环境和线上环境有时会混淆。该怎么办？然后给线上环境加个权限控制系统。。。我的系统有单点，那就加个负载均衡吧。负载均衡器的单点呢？那就加一个等价的路由器吧……加法谁不会呢？不想简化同一个系统？不能拆东墙补西墙吗？这些系统越来越多，我看你以后怎么运维。一开始没有想清楚就上线了，后来失败了，没法重新设计，重新架构。只能修补了。这就好比一座有缺陷的大楼还没有盖好，你不可能去掉厚重的盖子，只能一直打补丁。人物是狗，越描越丑。【解决方案】1）想好了再做设计。评估多个设计没有坏处。简化，简化，再简化。2）狠狠还债，就算CEO来了，也拦不住我还债。“错误驱动”软件开发WatchDog式软件开发通常是“错误驱动”软件开发的产物。这种发展方式其实是智力和能力的不足。为了上线的目的，上线后再说，有问题再改。上面的老板或者业务方基本都会说，没关系，我们不需要一开始就完善的系统，你先走再说，先解业务渴，我们再重建完善等我们有空的时候。而一些技术人员会用“架构和设计逐渐进化”这句话来证明“故障驱动”开发是值得的。我认同渐进迭代和架构演化论，但我觉得“系统迭代论”和“架构演化论”已经被彻底当成能力有限甚至无知者的超级借口了。你弄错了吗？你知道什么是迭代，什么是进化吗？您知道定位线路故障需要付出多大的努力吗？（看看这篇文章就知道了）要知道，你随便应付一下，局部会快，但整体就慢了。虽然，我看到那些制度在一次又一次的失败后一点一点地改进，但我想说，为什么不一开始就认真一点、严谨一点呢？我从来没有见过一个优秀的系统是由故障和失败案例一个一个堆积起来的。即使是像Windows95/98这样史上最烂的操作系统，如果没有WindowsNT精心设计的补充，Windows也会失败。早就结束了（看看IE的末尾就知道了）。【解答】1）基础知识和理论知识很重要。关键是要使用更多现有的和成熟的解决方案。2）对技术有一颗严谨敬畏的心。做之前想清楚，坚持高标准，为失败而设计！有很多事情不能急于求成。其他开发方式其实这样的东西还有很多。例如：1）配置管理方面的问题。对于源码配置管理，并不是一件简单的事情。配置管理与软件的结构和团队的组织有很大关系。我见过两种非常低效的配置管理。一种是通过开设项目分支来做项目，同时开设多个分支。branch打开时间还是很长，导致合并回trunk的时间很多。各种冲突，另一种是N个以上的团队在同一个代码库中进行变更，这会导致很多复杂的问题，比如一个团队的变更出现了bug，或者团队的所有功能都得等待这个bug解决修复只能发布，或回滚到以前版本的所有更改，包括其他团队开发的功能。显然，软件模块结构、软件架构、团队组织等都会严重影响开发效率。2）人肉软件开发。大多数软件团队和主管会以“人手不足”为自己开发效率不足的借口，而当大多数故障发生时，他们会用更重的“人手流程”来弥补自己的能力不足。他们从来没想过用“技术”，用更“聪明”的方式解决问题。3）会议驱动的开发。人多了，团队多了，想法多了，沟通也多了，开会开会是很有必要的。综上所述，我有以下结论：1）软件工程师分工越细，团队效率越低，团队之间的服务是关键。无论是从语言还是从软件模块上的分工，越细越差。服务化不是我要帮你做事，而是我让你做事更容易。2）你总是需要认真对待一个环节。走得越远，效率越高，走得越远，效率越低。要么你更认真地设计和编码，要么你必须更认真地对待测试。如果你对设计、编码和测试都不认真，那么你就必须认真对待运维，你必须认真对待故障处理。你总是需要在一个地方认真。可以看另一篇文章——《多些时间少写些代码》3）“小而精的团队”+“有限的条件和资源”是效率的基础。只有团队小，内耗才会小。只有在条件或资源有限的情况下，才会逼着你用最经济的手段去做最有价值的事情，才会逼着你喜欢简单、简单。4）技术债不能欠，还债要狠。很多事情，一开始没有发生，永远不会发生。一件事一旦烂了，后面只能是烂的。东西越烂，越不敢还债。5）软件架构要松耦合，团队组织要紧耦合。6）工程师文化是关键，强调过程就是强调结果。只看结果的KPI等同于“沥水为鱼”、“饮鸩止渴”。（全文完）原文链接：http://coolshell.cn/articles/11656.html
