Day3: 精益求精抠细节vs点到为止保交付
上个月我干了件蠢事，说出来给大家当反面教材。接到一个需求，打开老代码一看写得乱七八糟，变量名a/b/c、函数500行、逻辑绕来绕去，我手痒就顺手重构了，把命名改了、函数拆了、重复代码抽了，还加了点"优雅"的设计模式，重构完确实清爽多了。但我没算到重构引入了三个隐蔽的bug，测试的时候没测出来，上线后出了问题回滚，项目延期了三天被通报批评，绩效打了B。leader找我谈话我说"我是为了代码质量啊"，leader说的话我到现在还记得："代码质量是手段不是目的，我们的目的是交付业务价值，你为了手段忘了目的"。后来我反思了很久，我重构确实是出于私心：一方面是代码洁癖看不下去烂代码，另一方面是想在leader面前展示技术能力，但我忽略了项目的时间节点和业务优先级。从那以后我定了个规矩：第一，不主动重构非本次需求涉及的代码，除非它会导致本次需求出bug；第二，重构前必须跟leader说清楚要花多少时间、带来什么收益，获得批准再做；第三，重构和新功能分开提测，不能混在一起。想写好代码没错，但你得在正确的时间正确的地点做这件事，别用你的代码洁癖绑架项目进度，最后买单的是整个团队。
发布于 广东
分享
评论
2
未登录
友善发言
评论
加载中
