当前位置:  开发笔记 > 编程语言 > 正文

跟踪Bug数据库中的重构

如何解决《跟踪Bug数据库中的重构》经验,为你挑选了1个好方法。

假设您在某个地方工作,其中源代码的每个更改都必须与错误报告或功能请求相关联,并且无法对该策略进行重组.在这样的环境中,处理代码重构的最佳方法是什么(即改进代码但不修复错误或添加功能的更改)?

编写错误报告并将重构与之关联起来.

编写功能请求并将重构与其关联.

在处理与错误报告/功能请求相关联的代码时,在重构中潜行.

只是不要做任何重构.

其他

请注意,经理和客户都可以看到所有错误报告和功能描述.



1> Outlaw Progr..:

我投票支持"偷偷摸摸的重构"方法,我相信,重构的方式首先应该完成.为了"清理代码"而重构可能是一个坏主意.这意味着你没有真正的理由进行更改.根据定义,重构是在不修复错误或添加功能的情况下修改它.如果你遵循KISS原则,任何新功能都需要至少一些重构,因为你并没有真正考虑如何在第一次使最可扩展的系统成为可能.

推荐阅读
吻过彩虹的脸_378
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有