最近我不得不修复从现场报告的错误.虽然测试团队正试图重现这个问题,但客户却喘不过气来,我们必须在一周的时间内完成生产就绪代码.当我们能够重现问题的时候,还剩3天了.我和我的同事不得不花费近30个小时的不间断努力找到原因,并在我们未编写的代码中进行修复.幸运的是我们做到了.但是,我担心的是测试团队没有足够的时间来完成他们通常的测试用例.我们不得不忽略代码中的其他微不足道的错误来限制代码更改.
我想向社会了解在这些时间紧迫的条件下应遵循的最佳做法.是否可以忽略其他问题(这不是导致您正在处理的错误的原因)？如何在遗留代码中尽可能地限制代码更改,以便我不必担心只能进行最少的测试.没有任何足够休息的连续工作也会增加其问题.请分享您的想法和经验.
这里已经有了一些很好的建议,但我想补充一些其他内容:
如果你只是在极端时间压力下发现错误修复,记得在压力消失时再回过头来看看那个修复,以确保它不仅仅是一个可怕的黑客,而是一个真正的问题.
早在20世纪80年代后期,我修复了一个在一个非常古老的程序中深陷的错误.但它曾经在一个过去工作的案件下工作.当我进一步调查时,我发现已经实施了"临时"工作.评论说:
C TEMPORARY WORK-AROUND UNTIL I FIND THE REAL CAUSE. I CHARNY, SUMMER STUDENT, AUG 1971
当我发现这个15岁以上的"临时解决方案"时,Irv Charny是我的老板.
一个最好的做法是显而易见的是 "没有足够休息时继续工作"
另一个是让你商业化,并使用一些常识,你引入另一个严重或更严重的错误的风险是什么？客户将如何应对？如果您解释需要更多时间,客户将如何反应？权衡答案并做出商业/行政决定.
无论你做什么,你的软件都会包含bug.
在老板/公司指定的时间限制内,您所能做的就是最好的.
这个问题引起了我的一些担忧.
我已经"在那里,做到了"就工作全力以赴试图解决问题而言.我可以免费告诉你你可能已经知道的事情 - 凌晨3点你没有想太清楚,你的修复可能会造成比他们解决的问题更多的问题.
不仅如此,而且在促进这种疯狂的工作文化中,通常会在第二天早上8点出现,准备继续给予100%.当你年轻的时候,你的身体会应付一定量的这个,但是在你20岁左右,你会产生严重的副作用.哎呀,即使在你年轻的时候,你也只能睡不着这么久.如果您在睡眠不足的状态下驾驶,最终可能会让您失去生命.
我希望您能为公司的管理层提供一个良好的商业案例,以获得更明智的实践.几乎任何一个客户(无论多么咄咄逼人)都可以确信,等待一周比在软件中冒险使用showstopper bug更好.对于罕见的情况,通宵编码马拉松可能是好的,但是当它变得司空见惯时,每个人都会受苦.
京公网安备 11010802040832号 | 京ICP备19059560号-6 