InfoQ|反 996 有理:催程序员交代码,写不出好软件
本文最初发表在 iiSM.org 网站 , 经原作者 Gandalf Hudlow 授权 , InfoQ 中文站翻译并分享 。
许多组织都会用施加压力的办法让大家“完成”新软件项目 , 因此整个组织都面临着来自高层的压力 , 大家必须在高层划定的任意截止日期前完成 。 副总裁、项目经理、产品经理的奖金和聘用机制 , 都是要看他们在截止日期之前交付软件的能力如何而定 。 这一错误做法带来的结果就是 , 部署到客户手中的软件版本 1.0 , 充满了混乱 。 这种模式已经重复了一次又一次 , 以至于消费者都会说“用软件别用版本 1.0 的!”、“还是等等补丁包再说吧!”
这些组织没有意识到的是 , 所有的软件变更都可以划分成三个组成部分:价值、填充和混乱 。 混乱会破坏价值 , 而填充只是没人想要的功能 。 当对代码施加截止日期的压力时 , 消除混乱所需的工作首先会被砍掉 。 混乱会破坏价值 。 不信?请你扪心自问 , 上一次你手机上的一款新应用出现混乱时 , 你做了什么 。 那款你卸载后就忘掉的应用 , 就是刚刚被混乱破坏的新价值尝试 。
伦敦希斯路机场(Heathrow Airport)就曾有类似的教训 。 他们大张旗鼓地举办 T5 候机楼启用仪式时 , 连女王都莅临了!随着办理登记手续的延误 , 混乱的局面开始出现了 。 接着出现行李堆积和传动带堵塞的情况 , 局面更加混乱了 。 到了下午 , 英国航空(British Airways) 已经完全放弃托运行李的努力 , 乘客们被强行推上已经晚点的航班 , 并含糊其辞地承诺他们的行李将会一起抵达目的地 。 最后新闻报道里充斥着堆积如山的行李照片 。 没有人感到高兴 , 尤其是女王 。
由时间驱动的组织造成的 T5 候机楼混乱就是一个典型的灾难 。 上面下达的命令很清楚:只要完成它就行!要避开所有不利于按期交付的一切阻碍:所有的建议、所有的专业知识、所有的努力!
下面是由于时间压力而导致交付延迟的各种混乱的总结 。
- 负载和性能问题:一个需要每秒处理 100 个事务的系统 , 如果施加压力过大 , 则会将性能限制在每秒少于 2 个事务 。
- 间歇性问题:人工测试实验室中出现的低频率问题在生产负载下成为操作上的噩梦 。
- 竞争危害:许多公司使用的负载测试技术并不能在软件上产生典型负载 , 因此大多数竞争危害都需要在生产环境中才能发现 。
- 内存泄漏:在生产负载下 , 缓慢的内存泄漏会造成停机 , 因此需要采取一些变通措施 , 例如定期重新启动等 。
- 数据损坏:数据损坏通常表现为低频率的中断或出现奇怪的值 , 而在生产负载下则变成高频率的数据损坏 。
- 未处理的错误:时间压力越大 , 代码库的错误处理就越少 。 我们这些有经验的人都知道 , 要正确处理错误情况就需要进行大量的工作 , 而这些恰恰正是时间压力较大的组织没有列入日程表中的工作 。
汽车失控的加速 用一个更为糟糕的情况来举例:一辆汽车因为加速失控造成了 8 起伤亡 , 现场被发现有长达 100 米的紧急刹车的痕迹 , 一直通往混凝土护栏 。 怀疑可能是由于油门被卡所致 。
迫于时间压力下完成的代码
charbluetoothId[30];
intacceleratorAngle =0;
voidprocessAccelerator{
if(acceleratorAngle >0) {
engine.throttle(
acceleratorAngle);
}
}
voidprocessBlueToothOnline(
char*deviceId){
strcpy(bluetoothId, deviceId);
}
精心编写的代码//Fixed issue with blue tooth
推荐阅读
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- InfoQ|为什么我不再用Redux了
- InfoQ|一个经典的100%无服务器架构在AWS上是什么样?
- InfoQ|调查了近百位CXO:喊了这么久的数据中台建设成果如何?| Q推荐
- InfoQ|阿里淘系自研标准化协议库 XQUIC 首次公开:直播高峰期卡顿可降低 30%
- InfoQ|WebAssembly如何演进成为“浏览器第二编程语言”?
- InfoQ|重新思考日志:业务系统竟然是一个大数据库?
- 科学|盾牌座uy被拉下最大恒星宝座,新发现有颗恒星大到挑战了现有理论
- InfoQ|9.9元提前解锁30个大厂前沿实践案例分享!QCon+案例研习社福利来袭
- InfoQ|不再重复造轮子,DevRun开发者沙龙-用友·华为云杯专场,革新传统开发模式!
- 厕所|拼多多的厕所上了热搜 996 的大厂员工没有如厕自由