修改一处代码引起了另一处Defect的经验

各位在开发过程中一定遇到过修改一处代码引起了另一处Defect的经验，很多同事可能刚到项目上，不清楚某一处代码可能引起的关联性和影响点，那么如何确保项目质量的呢？(大型项目)
AD的单元测试？ST的集成测试或回归测试？
目前我们项目上遇到了此类问题，被客户追问需要提出改善的方案，希望有这方面经验的同仁提出宝贵意见，也为以后新人或者加入新项目的老人们提供参考的依据。
客户邮件描述如下：
在对应CR或Defect的时候，如何针对影响范围和类似功能进行确认及修改的？
关注主要集中在.
1．对影响范围和相同功能的确认方法和工具

2．对有影响的部分，具体修改的方法

3．相关的质量保证手段

问题补充

这个在实际开发中确实很难，因为开发人员水平参差不齐。

如果你用模块化设计，每个功能都用自己的方法，公用方法设计的变量用克隆。这样系统效能低下。

个人认为，只能从提高编程水平和习惯，以及开发制度规范化方面来提高。

[quote="chenxiang105"]各位在开发过程中一定遇到过修改一处代码引起了另一处Defect的经验，很多同事可能刚到项目上，不清楚某一处代码可能引起的关联性和影响点，那么如何确保项目质量的呢？(大型项目)
AD的单元测试？ST的集成测试或回归测试？
目前我们项目上遇到了此类问题，被客户追问需要提出改善的方案，希望有这方面经验的同仁提出宝贵意见，也为以后新人或者加入新项目的老人们提供参考的依据。
客户邮件描述如下：
在对应CR或Defect的时候，如何针对影响范围和类似功能进行确认及修改的？
关注主要集中在.
1．对影响范围和相同功能的确认方法和工具

2．对有影响的部分，具体修改的方法

3．相关的质量保证手段
[/quote]
回归测试。

不修改,只添加

除非是开发新功能、新版本，否则都按照打补丁的方式处理。
打补丁的方式就是： 不修改只添加。

把有问题的代码单独拷贝出来，单独修改，只让要修改的功能依赖新修改的代码。

[quote="chenxiang105"][quote="NanguoCoffee"]除非是开发新功能、新版本，否则都按照打补丁的方式处理。
打补丁的方式就是： 不修改只添加。

把有问题的代码单独拷贝出来，单独修改，只让要修改的功能依赖新修改的代码。[/quote]

那样不是会新添加很多类？
这东西开发了10多年了,已经多达数不过来了.. :cry: [/quote]

那也是没办法的啦。没有重构好，前面的人欠的债要后面人来还......

如果不是做补丁开发。
那只能做重构，tdd开发，单元测试增加保障。风险与收益成正比。

挺好的帖子，还想着看下文呢，这么多人投了新手~

我也觉得挺好，投新手的高手们出来发表下观点？

[quote="chenxiang105"]各位在开发过程中一定遇到过修改一处代码引起了另一处Defect的经验，很多同事可能刚到项目上，不清楚某一处代码可能引起的关联性和影响点，那么如何确保项目质量的呢？(大型项目)
AD的单元测试？ST的集成测试或回归测试？
目前我们项目上遇到了此类问题，被客户追问需要提出改善的方案，希望有这方面经验的同仁提出宝贵意见，也为以后新人或者加入新项目的老人们提供参考的依据。
客户邮件描述如下：
在对应CR或Defect的时候，如何针对影响范围和类似功能进行确认及修改的？
关注主要集中在.
1．对影响范围和相同功能的确认方法和工具

2．对有影响的部分，具体修改的方法

3．相关的质量保证手段
[/quote]

根本的解决方案 是找清楚这个项目业务的人进行 开发修改设计

要是方法的单元测试 case 覆盖全面，应该可以减少 defect。

做一个功能矩阵表啊。把内在逻辑相关的功能都罗列出来，当修改一处地方的时候就可以看到可能涉及到的相关功能，当然这个表要经常维护的

整理出完整的技术文档、接口文档、业务关联文档，在修改前查看，再加上详细的回规测试

[quote="chenxiang105"][quote="devroller2"]做一个功能矩阵表啊。把内在逻辑相关的功能都罗列出来，当修改一处地方的时候就可以看到可能涉及到的相关功能，当然这个表要经常维护的[/quote]

这个想法可行度咋样？ 有试过没？？ :D [/quote]

还是别试了，偶试过，这玩意儿是三分钟热度的，没几人能坚持下来的。

还是测试脚本最靠谱

资深人员 review 代码。