为毛你深陷故障驱动式开发
我坐在自己的工位上，盯着电脑荧屏，手抚键盘写代码，耳朵里不断回响着下面这些话：
- “张三，快，服务起不起来了”
- “李四，客户反馈说保存按钮连续点两次软件就会崩溃”
- “王五，新版本在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）。
为毛你深陷故障驱动式开发相关推荐
- Android项目驱动式开发教程 第2版,《Android项目驱动式开发教程》第一章开发入门.ppt...
<Android项目驱动式开发教程>第一章开发入门 1.4 项目框架分析 4 android:versionName="1.0" > 5 8 第9行代码andro ...
- 使用插件式开发称重仪表驱动，RS232串口对接各类地磅秤数据实现ERP管理
在ERP系统中,采集一线的生产数据是重要工作之一,而称重计量是企业的核心资产数据,人工计重费时费力,还容易出错,重量数据是否正确,直接影响企业的采购或销售额.基于此,由系统对接电子秤实现自动抓取数据是 ...
- 软件测试技术与项目实训pdf,软件测试技术任务驱动式教程pdf
软件测试技术任务驱动式教程 内容简介 <软件测试技术任务驱动式教程>分四个篇章介绍了软件测试的基本知识.方法.工具及流程.软件测试的基本理论阐述了软件测试的概念.模型和分类,软件质量管理与 ...
- C++11（及现代C++风格）和快速迭代式开发
过去的一年我在微软亚洲研究院做输入法,我们的产品叫"英库拼音输入法" (下载Beta版),如果你用过"英库词典"(现已更名为必应词典),应该知道"英库 ...
- 瀑布式开发、迭代式开发、螺旋开发、敏捷开发四种开发模式的区别
1.瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型,瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析.设计.编码.集成.测试.维护的步骤顺序进行. 步骤成果作为衡量进度的 ...
- @select注解_Mybatis基本知识十七：Mybatis注解式开发-单表注解式开发
上一篇文章:<Mybatis基本知识十六:查询缓存之第三方查询缓存> 若文中有纰漏,请多多指正!!! 1.前言 使用Mybatis进行开发,不仅可以使用mapper配置文件进行开发,也可以 ...
- springboot 使用webflux响应式开发教程（二）
本篇是对springboot 使用webflux响应式开发教程(一)的进一步学习. 分三个部分: 数据库操作 webservice websocket 创建项目,artifactId = tradin ...
- 视频教程-PS教程-【和东东一起学PS】Photoshop 2020小白到高手（任务驱动式基础+实战教学）-Photoshop
PS教程-[和东东一起学PS]Photoshop 2020小白到高手(任务驱动式基础+实战教学) Adobe平面设计与影视剪辑专家讲师.微软Office办公软件专家讲师.资深IT图书作者/策划人/出版 ...
- 下一代响应式Web设计：组件驱动式Web设计
自从著名设计师 Ethan Marcotte(@beep)在 A List Apart上发表了一篇名为< Responsive Web Design>的文章之后,响应式网页设计(RWD,即 ...
最新文章
- Ubuntu 17.4下如何安装和配置flash player
- Hibernate4继承映射
- linux命令head
- 00-深入学习cache
- wp comments post.php,通过修改wp-comments-post.php 防wordpress垃圾(spam)评论 | 沉默过客
- Node.js初接触（一）
- Java对象转出json并过滤指定属性
- 中文版Postman测试需要登陆才能访问的接口（基于Cookie）
- 大道至简第二章-‘是懒人造就了方法’读后感
- NeatUpload的使用方式
- 图像滤镜实现万能方法研究
- 豆腐锅巴--怀念娭毑_原水_新浪博客
- yaml配置Mybatis
- CUDA学习：Windows下的CUDA环境配置
- Excel表格无法重命名工作表
- 残疾人求职阿里巴巴等了八年！好辛苦！
- psp测试电池软件,PSP 电池使用时间测试
- 固定利率，会是下一个异军突起的DeFi热点吗？
- 机房在线搬迁的规划与实施
- 瞬变电磁数据读取显示，正演计算，及基础处理DLL文件调用
热门文章
- ADO.NET ORM数据库增删改查封装（工具一）
- 鸿翼档案，将非结构化数据治理能力应用于档案管理的先行者
- linux启动分区修复工具,Linux下的分区修复软件Testdisk（转载）
- sonar java_如何正确配置属性“sonar.java.binaries”？
- EasyPoi word导出 简易使用指南
- 想要做好软件测试，可以先了解AST、SCA和渗透测试
- dell服务器之开启虚拟化功能,dell服务器自带虚拟（dell服务器开启虚拟化技术）...
- discuz 对不起，当前站点已经关闭了用户多应用服务
- DW集训营算法基础梳理任务1：线性回归
- 分布式搜索引擎-ElasticSearch（上集）