为毛你深陷故障驱动式开发

我坐在自己的工位上,盯着电脑荧屏,手抚键盘写代码,耳朵里不断回响着下面这些话:

  • “张三,快,服务起不起来了”
  • “李四,客户反馈说保存按钮连续点两次软件就会崩溃”
  • “王五,新版本在VPN下连不上服务器了”
  • “赵六,你提交代码后应用开发组的客户端一运行就Crash”
  • “秦八,客户说他一看别人分享的视频盒子就黑屏”
  • “黄九,1.3.9版本的共享桌面功能没法用了”

我觉得我应该带上耳塞式耳机,边听Katie Melua边写代码,这样才能屏蔽掉这些嘈杂的有关故障的申诉和对话。然而我不能,有时我也是被呼唤的那位程序员。

这种被Bug和故障抽着被迫火急火燎地旋转的开发过程,我称之为“故障驱动开发”。是的,故障驱动开发。和那个注著名的“测试驱动开发(TDD)”类似,然而却具有明显的无奈和消极。

对于故障驱动开发,我有两个问题:

  1. 我们是怎样陷入故障驱动开发窘境的?
  2. 怎么走出故障驱动开发的泥沼?

你喜欢故障驱动开发这种工作模式吗?要是你感到只有这样自己才被需要才能彰显自己的价值和重要性,那就此打住,别往下看了,你可以继续去享受它带给你的快感了,霍霍,让快感来得更猛烈些吧。

我打算从三个方面来谈谈我们是怎样陷入故障驱动开发的:

  • 开发能力失配
  • 绩效导向
  • 有问题再说的思想

一边谈原因一边给出应对策略,不一定对,抛砖引玉吧。

开发能力失配

很早之前我在另一篇文章“无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)。

时间: 2024-10-23 18:34:36

为毛你深陷故障驱动式开发的相关文章

C语言零基础项目驱动式学习第一天

引言: 智能手机(Smart Phone)是一种运算能力及功能比传统手机更强的手机.目前的操作系统基本上有以下几种: 1. Symbian Os 众所周知塞班隶属于NOKIA,Symbian开发之初的目标是保证在较低资源的设备上能长时间的运行,这导致了塞班的应用程序开发有着较为陡峭的学习路线,开发成本高,但是程序的运行的效率很高> 2.Android 开源, 联盟,Android凝聚了几乎遍布全球的力量,这是Android形象及声音能够被传到全球移动互联网市场每一个角落的根本原因.不过, 1).

迭代式开发中的禁忌:跨版本修改

最近在做一个项目,这个项目一开始采用的是迭代式的开发模式.但是现在已经乱成一团,乱着乱着开发就变成了测试驱动的开发. 说好的1.0版,改着改着都不知道这是什么版.数据库的结构变化很大.接口规范变化很大.需求变化很多.你可能会想,就算搞个很厉害的架构师,也不见得系统就稳定不变. 是的,确实如此.但是问题是每一次的大改动,根本就是十分随意却没有任何记录的行为.仅靠一个svn(也没用上分支),谁能弄明白到底改了什么鬼? 为什么迭代式的开发,最终变成了依靠测试人员的测试驱动开发?后来我想了一下,发现根本

敏捷开发的26条至理名言 快速迭代式开发使用方法总结

敏捷开发真正的问题是什么?其实敏捷主要还是一种观念,一种意识,通过人来推动. 本文总结了26条有关敏捷开发的关键原则,如何快速迭代式开发,供读者参考借鉴,以指引敏捷软件开发团队. 1.完整地干完一件事后在开始另一件事:用厨房比喻来说就是:"先上这道菜,再开始做下一道".软件开发的最大问题就是同时开始几件事情,这将不可避免的造成某些工作被废弃,从而造成浪费.专注于一件事:完整地实现其功能:运行测试:编写文档:签入所有,把这当做一项工作完成,然后再开始下一件事. 2.不要破坏构建:非常明显

springboot 使用webflux响应式开发教程(二)

本篇是对springboot 使用webflux响应式开发教程(一)的进一步学习. 分三个部分: 数据库操作webservicewebsocket 创建项目,artifactId = trading-service,groupId=io.spring.workshop.选择Reactive Web , Devtools, Thymeleaf , Reactive Mongo.WEB容器spring-boot-starter-webflux 附带了 spring-boot-starter-reac

瀑布模型,渐增式开发,原型化开发

瀑布模型:设计在开发阶段 瀑布模型有以下优点 1)为项目提供了按阶段划分的检查点. 2)当前一阶段完成后,您只需要去关注后续阶段. 3)可在迭代模型中应用瀑布模型. 增量迭代应用于瀑布模型.迭代1解决最大的问题.每次迭代产生一个可运行的版本,同时增加更多的功能.每次迭代必须经过质量和集成测试. 4)它提供了一个模板,这个模板使得分析.设计.编码.测试和支持的方法可以在该模板下有一个共同的指导. 瀑布模型有以下缺点 1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量. 2)由于

使用js命名空间进行模块式开发

在java中,为了防止命名冲突和模块式开发,会有个一个import 关键字来进行导包. 在js中为了达到同样的效果,我们也通过给其自定义一个“包”的概念. 直接上代码: 首先有个LC.js文件: //LC.js var LC = LC || {}; LC.namespace = function(namespace) { var nsparts = namespace.split("."); var parent = window; if (nsparts[0] === "L

基于TypeScript的FineUIMvc组件式开发(简介)

不熟悉FineUI的可以访问其官方网站(http://www.fineui.com),在这里我从我的个人角度说一下FineUI,FineUI有多个版本,但主要基于2种架构,一种是基于Asp.net WebForm,别一种是基于Asp.net Mvc. 在WebForm版本下,虽然FineUI是一个前端构架,但在一些常规简单项目中几乎不用写JS代码,除了首次请求页面,后续的操作都是基于Ajax的,而JS代码都是由服务器端动态生成,并放到客户端执行,这也是FineUI的一大特点.了解WebForm的

也来学学插件式开发

上一家公司有用到插件式开发来做一个工具箱,类似于QQ电脑管家,有很多工具列表,点一下工具下载后就可以开始使用了.可惜在那家公司待的时候有点短,没有好好研究一下.现在有空,自己在网上找了些资料,也来试试. 主要思路:公开一个插件接口,如果.DLL或.EXE的代码中有继承这个接口就将其示为插件,并将这些插件放在同一目录.运行程序的时候扫描目录并通过反射判断.DLL或.EXE中是否存在该接口,若存在,则当作插件加载进来. 我们来做一个示例看看.例子也是在园子里找的,自己改了一下,详见:http://w

udp套接字使用信号驱动式I/O

信号驱动式I/O的本质就是:进程预先告知内核当某个描写叙述符发生事件时,内核会向该进程发送SIGIO信号通知进程,进程可在信号处理函数中进行处理 进程能够通过fcntl打开O_ASYNC标志或ioctl打开FIOASYNC标志来通知内核,二者的差别是一些系统不支持fcntl,所以应尽量使用ioctl 对于TCP套接字产生SIGIO信号的条件: 1.监听套接字上有新连接请求完毕 2.某个断连请求发起 3.某个断连请求完毕 4.数据到达套接字 5.数据已从套接字发送走(输出缓冲区有空暇空间) 6.发