关于修改bug的思考
2016-09-30 23:27
190 查看
作者:朱金灿
来源:http://blog.csdn.net/clever101
有软件就有bug,这意味着软件研发不仅仅是新功能开发,更要拿出相当一部分精力去修改bug。但基本很多软件开发者并不喜欢修改bug,对这项工作的厌恶程度并不下于写文档。究其原因有以下几点:一是修改bug并不会带来像开发新功能那么大的成就感,甚至修改bug意味着承认自己开发的软件中存在缺陷,这毫无疑问会给人一种沮丧感;二是修改别人开发模块的bug意味着吃别人的狗粮,等于自己要去读懂别人写的代码,理解别人的思路,弥补别人犯下的错误,很多时候意味着要付出更多的辛劳。
但是bug又是不能不改的。需要认识到的是修改bug并不是低技术含量的工作。相反它是一项相当有技术含量的工作。随便将一个bug扔给一个新人来修改是一件不负责任的事情。首先需要有丰富开发经验的开发者划分bug的难易程度,制定bug修改技术方案,然后安排新手去修改才是比较可行的路线。bug修改不适宜长时间连续进行,应在开发新功能和修改bug交替进行,比如一周五天时间,有三天开发新功能,有两天修改bug。长时间连续修改bug容易造成对bug修改的厌倦,就好像经常吃方便面的人到最后是看见方便面就想吐。还有对于一些设计方面有严重缺陷的代码适宜采用代码重构的办法来修改,这也是偿还之前的技术债,否则到最后是积重难返,代码变得无法维护。
来源:http://blog.csdn.net/clever101
有软件就有bug,这意味着软件研发不仅仅是新功能开发,更要拿出相当一部分精力去修改bug。但基本很多软件开发者并不喜欢修改bug,对这项工作的厌恶程度并不下于写文档。究其原因有以下几点:一是修改bug并不会带来像开发新功能那么大的成就感,甚至修改bug意味着承认自己开发的软件中存在缺陷,这毫无疑问会给人一种沮丧感;二是修改别人开发模块的bug意味着吃别人的狗粮,等于自己要去读懂别人写的代码,理解别人的思路,弥补别人犯下的错误,很多时候意味着要付出更多的辛劳。
但是bug又是不能不改的。需要认识到的是修改bug并不是低技术含量的工作。相反它是一项相当有技术含量的工作。随便将一个bug扔给一个新人来修改是一件不负责任的事情。首先需要有丰富开发经验的开发者划分bug的难易程度,制定bug修改技术方案,然后安排新手去修改才是比较可行的路线。bug修改不适宜长时间连续进行,应在开发新功能和修改bug交替进行,比如一周五天时间,有三天开发新功能,有两天修改bug。长时间连续修改bug容易造成对bug修改的厌倦,就好像经常吃方便面的人到最后是看见方便面就想吐。还有对于一些设计方面有严重缺陷的代码适宜采用代码重构的办法来修改,这也是偿还之前的技术债,否则到最后是积重难返,代码变得无法维护。
相关文章推荐
- 关于修改bug的思考
- asp.net动态加载用户控件,关于后台添加、修改的思考
- "getline" bug fix for Microsoft Visual C++ 6.0 关于VC6的getline输入需要两个回车才结束的BUG修改方法
- 关于客户端和服务器端live555的一点bug修改
- 关于线上的bug什么时候修复的思考
- zf-关于表单不能提交的bug修改
- 同事给我发的邮件,关于一个程序员如何面对修改Bug和需求变更的感想
- 修改两个关于RCU锁的bug
- 关于产品的一些思考——(四十)腾讯微信之修改备注和标签
- 关于bug分析与异常处理的一些思考
- 关于修改nginx中的cahce的key的生成规则的思考
- 关于UCenter 1.5.2 版以下的一个修改用户密码bug
- 关于bug分析与异常处理的一些思考
- 关于程序维护、修改的一点迷惑和思考
- 一次关于使用status作为变量引发的bug及思考
- 关于减少BUG的思考
- 关于Call to static DateFormat 的Findbug警告思考
- 一个Tahoma字体bug引发的思考—关于样式bug的分析流程
- 关于bug分析与异常处理的一些思考
- 关于C# XML序列化的一个BUG的修改