|
|
1
27
第一步。将成员或类标记为[过时] 第二步。更新成员或类的所有内部使用,以使用替换过时方法的新方法,或将该成员或类本身标记为[过时] 第三步。如果您在第2步中将新内容标记为[过时],请根据需要重复此步骤。 第四步。删除所有既不是公共成员也不是由过时公共成员或类使用的过时成员和类。 第五步。更新文档,以更清楚地描述替换任何公共过时成员或类所建议的方法。
顺便说一句,如果有人发现很容易忽略编译器警告,那么问题不在于[过时]。但是,不在代码中保留此类调用很长时间的一个原因(即尽快执行步骤2)是为了确保人们最终不会习惯于编译器警告,因为它们是编译代码的习惯性响应的一部分。 |
|
2
7
我认为这是主观的。如果它是内部的并且是一个相当快的过程,那么我将执行更改。
|
|
|
3
6
问题是-你可以在一个程序中重构。如果API是公开的,并且您不能使用API重构代码,那么这就困难多了。这就是过时的东西。 如果API是代码内部的,那么重构就是一种方法。清理代码,不要留下乱七八糟的东西。 但是如果公共API发生了变化,就应该——如果可能的话——慢慢来。 其余的还是主观的。我不喜欢“过时”的内部API的。 |
|
|
4
4
最后 紧急 . 最常见的情况是,编写了一些新代码,使工作比以前做得更好,但团队中没有人有时间回去替换大量旧代码。显然,这意味着一种情况,在这种情况下,简单的drop-in替换是不可能立即实现的(有时新代码确实如此) 几乎 旧代码所做的一切,但还有一小部分功能尚未实现)。
不管这真的是好事还是坏事都是很主观的。它是一种工具,和其他工具一样。 |
|
5
2
|