程序员Bug考核利弊分析与现阶段代码质量把控方法
原创,转载请标明出处,谢谢~
一、目前开发工作现状:
1. 开发拿到模块后做配置、写基类、写业务实现方法、添加/修改表字段,其中做的新配置其他开发可共享,写的基类如果测试通过,其他开发可添加自己的业务逻辑方法、可继承写新类。做配置、写基类、添加类是公共开发任务,这占其中一半的开发时间,业务逻辑方法实现只占每个开发任务的一半时间。所以基础工作交互多,可参考**编写的编辑器、附件等。***的新配置。
2. 为了代码健壮、可维护性更强,开发过程中不断优化、重构类和方法。把这种类和方法推广到项目组,为项目后期维护、后期扩展绞尽脑汁写了可行的方法,详情可参考**写的增删改查基类等。
3. 开发收到bug修复请求后,除了修改bug还会对周边业务做修改、优化,同时会修改大量其他人的代码以修改潜藏bug。
二、如果用bug考核开发后可能的几种情况:
1. 测试人员现阶段可以实现业务逻辑测试、可用性测试等,测试过程中,发现的问题只是表面功能错误,大多bug并不确定是业务逻辑错误、或者调用基类错误还是配置错误,导致bug归属问题不清楚,如果测试要细分要做大量工作:包括与开发沟通、与需求沟通,并做大量的验证工作准确定位是那部分问题,这样测试工作无形中增加了,开发修复bug时间无形中增加了,进度被延误了。
2. 开发为了减少bug,只写简单的代码实现功能,至于高可靠性的代码理念会被搁置一边。
3. 开发为了减少bug,修复bug时只做此bug的修复,与此bug有交互的方法置之不理,怕再次引起其他bug;
4. 开发为了减少bug,修复bug时,周边有关联的业务逻辑隐藏问题,刻意再隐藏起来,让此bug暂时不会复现。
5. 开发为了减少bug,精力只放在减少、隐藏bug上,开发工作的创新、可维护性、健壮性被抛之脑后。
6. 开发为了减少自身bug数量,会抄袭相关的bug少的业务实现方法,代码冗余对项目质量无任何好处。
7. 开发为了bug减少,对项目质量理念产生变化,认为只有减少bug才是正确的工作方法,而忽略了开发技术人员对创新技术、提高高可靠性、可维护性、质量佳的追求理念。
8. 测试花费大量时间准确定位bug源头,但也有定位不准确的时候,导致开发bug数量多。开发与之引起冲突,开发之间相互推诿bug,长时间会影响团队关系,从而工作氛围不佳、人人自危。
9. 测试如果要准确定位,要做大量定位、统计工作,从而花费大量时间。但目前只有1个在编测试、7个开发人员、两个不同项目组,导致测试任务加重,两个项目后期统计bug工作量增大,后期招新人也会产生资源花费。
10. 测试人员对深层业务逻辑、数据、甚至配置测试执行时需要花费几天时间造数据、配置工具来测试深层次问题。为了多找bug,响应bug考核,测试人员就多找表面肤浅问题、因为深层次问题需要时间和大量工作,但不会发现大量bug,所以测试人员可能会多发现表面小问题来应付考核,但这些小问题有的不用修复,又浪费了开发时间。
三、Bug考核导致的几个后果:
1. 开发创新思维被限制,写部分代码会变成他们避免、隐藏bug的过程;
2. 部分公共基类编写、配置工作无人做,大家各做各的,生怕出问题算到自己头上,导致代码可维护性差、冗余代码多。
3. 测试工作量加大,但不一定发现对项目质量有帮助的问题;
4. 开发团队、测试团队、团队内部关系搞僵,开发任务不再是个创新、使用优化方法、有成就感的技术活,而是做好表面应付考核的活。
四、目前开发对代码质量的把控方法:
1. 写业务逻辑同时优化基类、方法,从而避免冗余、增强代码可维护性;
2. 相同业务逻辑尽量抽出来作为基类,其他相同业务继承此基类,规范开发逻辑;
3. 配置NUnit做单元测试,实现提交的业务逻辑底层数据的正确;
4. 发布版本前自测,自测避免基本业务逻辑、需求缺失、基本功能bug的产生。