Programming languages 如何以及多久重构一次代码？

我的问题模糊地与你有关。但是，它没有涉及技术或实践

---

我正在阅读《实用程序员》一书，它强烈主张尽可能多地重构代码。然而，它并没有详细说明如何做到这一点以及多久做一次。你们是如何重构代码的？多久重构一次？

一般来说，我在增强系统的一部分时重构代码，我知道重构的代码部分将要进行测试

---

如果我看到一些我知道需要改进的东西，而它不是当前版本的一部分，我暂时不去管它，让它在下一个版本中运行。这对我们来说没什么大不了的，因为我们确实每个月发布一次，所以我们发现的糟糕代码可以稍等一下（前提是它不会在生产中造成问题），直到我们有时间彻底检查需要做什么

这有点像打扫房子，你应该每天收拾东西，做一些需要做的小事情来保持干净。然后（大约一周一次）你花几个小时把房子从上到下彻底打扫干净。最后（大约一年一次）你做了一次很好的春季大扫除，把所有的垃圾运走，重新开始

---

重构是关于保持干净的代码库，这是一项永远不会完成的任务。

每当我不开发新代码时，我都会进行重构。我还可以在发现瓶颈的任何时候进行重构

• 展开慢循环
• 将变量定义移动到函数的头部
• 将较慢的“原型”算法替换为经过验证的较快算法

---

除了非常-非常紧张的情况，你必须现在就完成一些事情，然后我总是在写下一些东西后立即关注重构。有时我有空闲时间，我会尝试重新重构旧代码，以防遗漏一些东西。

当我编写第一段代码时，我通常不会因为对未来可能的重用场景考虑太多而陷入困境。然后，随着更多的重用场景出现，我越是深入开发，我就越是重构我的旧代码以提高其抽象和重用级别

所以这实际上是一个迭代过程；我越是仔细阅读并使用我已经为新目的编写的代码，就越有必要在需要的时候和地点进行重构。

重构本身没有意义，它是一种简化进一步开发的工具。只有当你能从中获得优势时才进行重构。一个永远不会进化并经过测试的小型库是不进行重构的最佳候选库，在重构上投入的任何时间都不会有回报。系统/程序中需要改进、需要维护且难以阅读的部分显然是重构的候选者

---

始终考虑ROI（投资回报），如果你开始重构你现在认为可能更好的一切，那么明天你将再次重构，也许有一段时间你会有时间真正执行一些真正的改进。

每当我添加新功能或特别是更改现有功能时，我都会寻找重构机会。经典的情况是，当我结束编写大型方法时，我喜欢将它们分解成更小的部分。还有许多其他的，它们以一定的频率发生。重构可以帮助我在快速编码和尽可能保持代码整洁之间保持平衡。

只有当测试用例涵盖了代码时，我才会重构。

我认为重构代码有多种决定因素。其中一些可以是美观、通用功能或业务流程

例如，我目前正在从几个实用程序（JavaSwing）中重构公共功能。每个实用程序的顶部都有相同的菜单栏。但是如果我需要添加菜单项，我需要为所有实用程序（复制/粘贴）添加菜单项。所以我创建了一个菜单栏对象，让每个实用程序都使用这个对象。现在，如果我添加一个菜单项，它们都会立即更新

上述公用事业的开发现在将在世界各地进行，而不仅仅是由我来完成。所以我想做的是打破更多的共性，这样当一个新的开发人员开发一个实用程序时，他们可以只关注肉和土豆，现在关注它的摇摆方面

---

我还将几个数据验证和数据插入过程重构为更小的过程。这有助于打破应用程序中的业务逻辑，并有助于“进入”到您需要去的地方。例如，应用程序中有一个步骤确定是否可以将行插入数据库。我没有做这一步，而是做了大约10步，其中包括读取数据、验证正确的大小和数据类型、在标签中显示什么等。现在更容易更改特定部分的业务逻辑。

每当我看到重复的代码时

每当我看到一个更简单的算法/启发式的机会

离发布越来越近：）

我喜欢帮助您分析代码库的工具，可以告诉您未使用的成员、不必要的可见性（公共与受保护、内部与私有等）

我主要在.NET中工作，ReSharper在实现这一点以及自动化许多类型的重构操作方面非常出色。我认为在许多其他语言中都有类似的工具。

每次我推动时——否则我的同事也会支持我的观点，他们也应该这样做

---

（这是DVCS的另一个好处：我可以提交正确但系数不正确的代码，而无需推送。）

始终。每当我看到一个更好的方法或变量名称，每当我看到一些应该内联或提取的东西，等等，我都非常依赖Eclipse的