如何修改代码?

我同意其他人的回答,但这也取决于你为什么要写代码。如果这是一个特定的项目的最后期限,你可能没有太多的机会。如果它可能被其他人重复使用,请确保重构不会破坏他们正在使用的任何东西。如果这是一个长期项目,特别是一个公共项目,那么几乎可以肯定它将需要大量的重构。

我已经写了大约13年的公共图书馆,并且经过了5.5次修订(我正在经历的修订)。在许多情况下,这是因为技术已经改进了,我自己做的事情现在可以用标准库来做了。这些年来,我学到了很多更好的策略。

一般来说,好的重构通常意味着丢弃旧代码。

更新 现代工具使自动执行许多操作变得容易(例如更改名称、包)。专家们建议方法很短,所以当你发现你的方法延伸到两页时,把它重构成更短的一页。但有时这些工具不起作用,您必须创建暂时中断的代码。在这种情况下,请确保(a)在工作版本上运行单元测试(b)提交它。很容易进入一个复杂的重构操作,并意识到您已经严重破坏了它,需要回溯。 如果有依赖于代码的用户,请确保继续提供他们知道的API。例如,假设您有一个名为

Date date = getLastUpdate();

你(像我和其他许多人一样)决定 java.util.Date 是极度破碎的。你决定换成佐达 DateTime 但在这个过程中会很困难。你可能需要留出一段时间来完成它。不要将API更改为

DateTime date = getLastUpdate();

创建新接口,如

DateTime date = getLastDateTimeUpdate();

然后将原来的标记为 @Deprecated

在决定发布新版本之前,不应删除早期版本(动态更改API会失去朋友)

我想说你没什么好担心的,检查你的代码是正常的,有助于提高你的理解。您唯一需要担心的是,如果您要一遍又一遍地检查相同的代码位并更改实现。

即使你没有经验弄脏你的手,编写和测试代码,你也会变得更好。

检查代码很好…只要确保您测试它,如果您改变它(设置自动回归测试将是一个好主意)。

另外,如果您在许多地方使用相同的代码位,请将它放在类库中,这样您就只能在一个地方使用它(因此,任何改进都只需要执行一次)。

这是正常的吗?-是的(只要它不会占用其他项目太多时间)

您多久重新访问一次代码?-每当我再次使用该代码并有时间查看它时

优秀的程序员只写一次,不需要改变吗?-剥猫皮的方法不止一种,所以这是主观的。

我会说这是健康的,而且会认为这是很好的练习。重构对于一个好的代码库是至关重要的,只要您的测试是好的。

在TDD中,循环为:

• 红色
• 绿色
• 重构