为毛你深陷故障驱动式开发
我坐在自己的工位上，盯着电脑荧屏，手抚键盘写代码，耳朵里不断回响着下面这些话：
- “张三，快，服务起不起来了”
- “李四，客户反馈说保存按钮连续点两次软件就会崩溃”
- “王五，新版本在VPN下连不上服务器了”
- “赵六，你提交代码后应用开发组的客户端一运行就Crash”
- “秦八，客户说他一看别人分享的视频盒子就黑屏”
- “黄九，1.3.9版本的共享桌面功能没法用了”
我觉得我应该带上耳塞式耳机，边听Katie Melua边写代码，这样才能屏蔽掉这些嘈杂的有关故障的申诉和对话。然而我不能，有时我也是被呼唤的那位程序员。
这种被Bug和故障抽着被迫火急火燎地旋转的开发过程，我称之为“故障驱动开发”。是的，故障驱动开发。和那个注著名的“测试驱动开发（TDD）”类似，然而却具有明显的无奈和消极。
对于故障驱动开发，我有两个问题：
- 我们是怎样陷入故障驱动开发窘境的？
- 怎么走出故障驱动开发的泥沼？
你喜欢故障驱动开发这种工作模式吗？要是你感到只有这样自己才被需要才能彰显自己的价值和重要性，那就此打住，别往下看了，你可以继续去享受它带给你的快感了，霍霍，让快感来得更猛烈些吧。
我打算从三个方面来谈谈我们是怎样陷入故障驱动开发的：
- 开发能力失配
- 绩效导向
- 有问题再说的思想
一边谈原因一边给出应对策略，不一定对，抛砖引玉吧。
开发能力失配
很早之前我在另一篇文章“无Bug不生活”（点击阅读原文可以查看）中说过一句话：“程序员在生产软件，也在生产BUG”。这是程序员的宿命，再牛X的程序员，也注定终生与Bug共患难，不死不休。
然而这个残酷的定律并不一定会导致故障驱动开发，导致故障驱动开发的，是另一个残酷的真相：
大部分程序员的能力都配不上他所做的工作
举个简单的例子吧。假如公司的软件是用CEF（The Chromium Embedded Framework）+ Web的形式开发的，开发团队里就会有这样的基础分工：
- 搞JS的程序员
- 搞C++的程序员
搞JS的程序员用HTML、CSS、JS等写前端界面。
搞C++的程序员基于CEF做框架开发，还用C++实现一些核心的业务，比如私有数据传输协议、音视频编解码等。
那JS代码一定会调用底层的C++代码，C++代码里的有些状态也一定会需要反馈到JS中再展示给用户。
那么问题来了，6个写JS的，5个写C++的，这其中有几个能融会贯通CEF、JS、C++的？一个？两个？三个？还是只有半个？
Ok，假如有10个能贯通JS、CEF、C++，那这个团队的技术能力钢钢的啊！JS调用C++出的问题，JS程序员可以搞定；C++调用JS出的问题，C++程序员可以搞定；万一两者各自搞不定，交流一下也搞定了——那种你不会JS我不会C++鸡同鸭讲的事儿根本就不会发生。
上面的情况有点儿极端和理想化，但我觉得这样的团队，起码有2到3个人能打通JS、CEF、C++这三层，才能保障项目的顺利进行。实际情况呢……就一个，尼玛还是半吊子！现状呢……
大部分JS程序员觉得自己无需了解CEF是怎么回事儿，也没必要知道C++怎么暴露接口给他，那都是C++程序员的事儿。大部分的C++程序员觉得上面有JS，我把接口做好导出到V8 Context里就好了。所以，到后来，大部分的Bug将会聚集在JS和C++交互这一块或间接由这一块引起。
于是，因为我们的能力不够，接下来就会发生很多有趣的事情：
- JS遇到解决不了的问题就说是C++的接口不好
- C++接到问题就会说JS根本就不理解接口，调都调错了
- JS说C++代码不稳定，有新版本也不能上
- C++说JS老抱着陈旧的版本不愿意更新，Bug迟迟无法解决，新特性也没办法应用
- 技术经理说JS和C++之间的分层不清晰，需要不断开会讨论制定更清晰的接口
- 高层领导说整个团队的能力不行，得找个牛逼的项目经理来盯着
- 牛逼的项目经理来了，发布的产品还是问题多多，高层领导说得找个牛逼的测试经理来把关
- 牛逼的测试经理来了，发布给用户的软件还是Bug多多，高层领导说得找个牛逼的运维经理来盯着
- 牛逼的运维经理来了，被线上系统弄得焦头烂额，说以后测试测过的软件要给我们先内部试用，试用后发布出去还是问题多多……
- 于是，高层领导、运维经理、项目经理、测试经理、技术经理、质量管理经理统统都过来盯了，两天一小会三天一大会，尼玛，就不信这个邪，这么多人盯着你还能把活给干日踏了！
于是，壮观的景象出现了：一堆做支持性工作的人员盯着几个能力不匹配的开发人挖坑。下图是非常形象的说明：
然而这并没什么卵用！程序员照样可以在你眼皮底下搞出Bug来，原因很简单——臣妾做不到啊！
- 【应对策略】
说起来比较简单，找几个牛逼的程序员，把那些做支持性工作的人都赶走（留一个搞搞服务，需要设备给设备需要安慰给安慰），这样基本就OK了。
假如招人很难，那管理者就要注意创造宽松、积极的环境，让我们的程序猿们愿意抛开不合理的基于技能的分工，把自己培养成一专多能的猿中之王。
3个能力与需求匹配的程序员的生产率，超过错配的10个人。
绩效导向
你知道技术经理、项目经理、部门经理的绩效是怎么评估的？你知道程序员的绩效是怎么评估的？里面都有什么问题？建议看看我之前在微信订阅号“程序视界”发布的文章——“绩效/加薪/年终奖，虐你如初恋”。
对于技术管理、项目管理类的一线管理者，他们所带的队伍干的活越多，并行的工作越多，发布的版本越多，交付得越快，他们的绩效就越好。
由于这样的绩效导向，很多团队的技术经理、项目经理实际上就容易重视数量和速度，忽视质量和可维护性，最终就会导致只管拉屎不管擦屁股的管理作风。尼玛，先上了再说，先满足领导的时间要求再说。
所以，技术方案选择，快定快定快快定，差不多就行了。架构设计，快定快定快快定，赶紧开始写代码吧。开发进度，今天20%明天50%后天就90%了。当一个程序员忧心忡忡地表示技术方案不合理、架构设计存在缺陷、代码写得太快又脏又乱深海潜雷又多时，得到的答案往往是“来不及了，后面有时间再重构再完善吧”。
这要不出问题，就真日了鬼了。
所以，后面你就看吧，拆东墙补西墙，这边贴膏药，那边打补丁，服务不稳定就再写个监控服务管着它，内存泄露经常把服务器搞死就定期重启，今天Hotfix，明天紧急修复……作为程序员，你要不被折腾操折腾走那就是有人烧香保佑你了。
God Bless You！
- 【解决方案】
要从管理层就贯彻下面的原则：
在一段时间内，做好做精一件事。
要用数据让管理层明白：
匆匆上马的软件产品的维护成本远远大于（通常数倍于）开发成本，求快反慢，求廉反贵！
调整绩效指标，引导绩效指向：
要把软件发布后的运行情况作为绩效考核的一个重要参考因素。
有问题再说的思想
你有没有过这样的经历：
- 明知道代码有潜在问题也懒花时间得改
- 明知道贴块膏药打个补丁只能暂时规避问题可还是那么做了
- 明知道张三的代码逻辑上有个漏洞还是睁一只眼闭一只眼算了
- 明明有时间把某个模块的代码梳理一下重构一下想想没什么外在回报就放弃了
- 明明看着需求莫名其妙还是接受了
- 明明某个界面的UI设计反人类还是从了
- 写完代码编译通过就扔给测试去测
这都是很常见的现象，很多程序员都遇到过，都想想算了，先这样吧，有问题再说，反正有的是理由：
- 时间紧任务急，考虑不了那么细
- 别人定的，我管不了那么多，干好我自己的就成了
- 出力不讨好，不定还被谁不待见
- 反正回头还会Bug回归，先往前赶进度要紧
- 对得起老板给我的这么点钱就行了
一件事你不想做不想做好，总是找得到理由的。然而，在软件开发这件事上，你总得有一个环节需要认真，而且这个环节越靠前越好，越往后付出的代价越大效率越差效果也差。
要么你在需求分析时认真，要么你在设计和编码时认真，要么你在测试时认真，要么你在运维时认证，要么你在处理故障时认真……你总需要在一个地方认真，假如你什么地方都不认真，那就只好认真找工作了……
然而《无间道2》里的倪永孝早看穿了这一切：
然而混日子的还是很多，当一天和尚不撞一天钟的还是很多……要知道，你现在怎么做，代表着你以后怎么活，你的将来，是你现在的选择造就的。
虽然环境拖人下坠的惯性很强，虽然选择很难，虽然改变自己万般不易，然而《英雄本色2》里的龙四还是回头了：
我想要说的是，对技术要有一颗严谨和敬畏的心，想清楚了再干，干好了再给别人用。对技术负责，对产品负责，就是对你自己负责。
相关阅读：
- 大龄程序员的未来在何方
- 月薪3万的程序员都避开了哪些坑
- 这10个问题去哪儿啦
- 每周一书：致加西亚的信
更多精彩文章，参看“漫谈程序员”专栏或关注微信订阅号“程序视界”(programmer_sight）。