认识达内从这里开始

对于软件开发工程师来说，如果能够在进行软件开发的过程中，能够最大程度的优化代码的话，对于精简代码是有非常大的帮助的。所以我们今天就一起来了解一下，编程开发工程师是如何进行代码优化的。下面就开始今天的主要内容吧。

重构到底应不应该被当做软件开发生命周期的一个阶段，如果应该，那么要在一个迭代中给重构这个阶段分配多大比例呢?我们又该确定哪些人去做重构任务呢?虽然重构工作可以这样规划，，但我还是倾向于重构作为机会主义的活动来开展，就是无论何时何地都需要清理代码，不管是谁。

这意味着，在任何时候，有人看到一些不那么清晰工整的代码，他们都应该抓住机会立即修复，或者至少在几分钟之内。这个机会主义重构由UncleBob提出，遵循童子军(boy-scoutrule)规则–总是让代码保持着比你当初发现这个代码时更好的状态。如果团队中的每个人都在这样做，他们每天都会对代码库健康做出小的定期贡献。

这个机会可能来自于各个方面，比如实现一些新功能或修复一个bug的时候。一个机会是“准备阶段的重构”，在你开始实现任务之前，你发现如果这个现有类的API稍微改变的一点的话，这个任务实现起来可能会更加的容易。这时候，你可以先将它重构为应该有的样子，然后再开始添加你的功能。

另一个重构机会是，当你添加功能时，你会发现你添加的一些代码和一些现有代码是重复的，这时候你就可以重构现有代码以使得代码更整洁。这种对代码的持续关注是重要的-但是请记住，你应该只重构那些被测试为绿色ok的代码。

你可能会得到一些任务，但是意识到如果与现有类的交互改变了的话，那么会更好。在考虑自己实现之前，请抓住机会去做这样的重构。

有时你会看到一个机会，当你在做别的东西的时候。这时候，为了不打断你目前的做事的思路，你可以把这个问题记录下来，等有时间后再回来做重构。但不要隔得太久，最好是当天，在你完成了正在进行的任务以后就可以回来重构了。

有些人反对这样的重构，因为你把时间花在重构上而不是去研究一个有价值的功能。但是，重构的重点在于使代码更易于使用，从而使得团队更快地增加价值。如果你不花时间去重构，那么代码基础质量会逐渐降低。

但说了这么多，重构还是有一个真正的风险，你可能会掉进一个兔子洞，你修复一件事然后你又发现另一个，再修复，然后又发现另外一个，就这样一直下去，你就深陷一团乱麻了。巧妙的机会主义重构需要很好的判断力，你决定在什么时候哪些地方重构，这个需要很好的判断力。你想让代码比你发现的时候更好，但是它也可以等待作者去重构，使之成为你真正想要看到的方式。如果你总是让事情变得更好一些，那些经常被光顾的地方最后就会产生一个很大的影响-这正是清洁代码最有价值的领域。像编程的大多数方面，这个决定和判断力需要深思熟虑。

机会主义重构的一个作用就是它可以触碰到你正在负责的代码的任何一部分。你可能会在一个class里做大部分的工作，但是发现这个类中的问题是出在其他地方的代码中。缺乏本地化，并不应该是阻止你现在做出改变的障碍。这样的情况，常常使得你产生一种侥幸就是改天再改吧-但这个“改天”往往不会来。

重构确实取决于你是否有一个好的回归测试套件，如果你认为你将要接触的应用程序的那部分的测试比较薄弱的话，那么请谨慎重构。

在这种情况下，如果你能做到不会在兔子洞里偏离太远，那么投入一两次额外的测试是可以接受的。而且我发现，制造一个故意的错误，看看测试是否能抓住它。通过这样的方式也可以衡量我们的安全网到底是一个什么水平。

作者：贺卓凡译Martin著

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。