译者 | 布加迪

我的一位同事在大型项目代码重构方面有丰富的经验，他真诚地与我分享了他如何处理这些繁杂的任务。虽然他做的大部分事情只是坚持不懈地努力，就像在健身房锻炼那样，但这对我来说很有意义。本文分享他的秘诀。

1、组织目录

当你试图为大型项目重构代码时，很快就会碰壁，因为你不知道一开始该做什么，于是你转而开始阅读O'Reilly的技术类图书，或者对软件开发流程或方法（比如TDD和DDD等）产生兴趣。如果是这样，你的策略将以失败告终。

无论如何，你应该实际做起来，而不是寻找所谓的银弹。首先何不组织项目目录？你可以从了解几个风险入手，因为这么做几乎不会导致错误（bug）。

由于大型项目目录通常很凌乱，所以你一开始会发现很难掌握类的范围、类在何处使用。因此，组织目录可以帮助你在修改类之前了解类在项目中有哪种角色和作用域。

有时，你很难理解某些类的作用。在这种情况下，可以创建一些临时目录，比如“legacy”、“garbage”或之类的目录，并将类文件放入其中。如果你逐渐了解了类的含义，可以将它们移到其他适当的目录。

2、多写注释和文档

即使你已经不得不做代码重构，如果仍认为不需要任何注释以获得干净的代码，那么是时候意识到你的代码不再干净了；你要做的就是写大量注释，即使它们看起来冗长多余。

你应该在读代码时可能会产生疑问的代码旁边留下注释。如果你找到了答案，就应该趁还没有忘记，把它们作为注释写下来。

如果代码与你执行的当前任务无关，你可能不想留下注释。不过请仔细想想。如果你不摆脱一种自我强加的约束，你就无法花时间去注释，也看不到未来开始注释的任何迹象。请注意，它们只是注释而已。

接下来，不妨写你不喜欢写的文档。写文档对于代码重构来说也必不可少，尽管这项工作总是让人感到厌烦，有时甚至让人筋疲力尽。

你可能过去或现在参与几个基于“代码即文档”这一规则的项目。如果把一项特性换成新特性，你将需要阅读所有代码才能理解这项特性的功能。另一方面，如果你有无可挑剔的文档，完全可以使用理想的编程来实现这些特性。

“好奇怪。既然代码最终会被重构，我为什么还要写注释和文档呢？”

这种想法是错误的。代码重构是一项持久的工作。你不确定什么时候可以开始，也不确定是否可以凭一己之力开始。有许多注释和文档在将来供你和同事阅读。

3、编写更多的代码

这听起来似乎很简单，但不是开玩笑。

为了评估工作效率，确认提交和修改了几行代码怎么样？比如说，假设你无法在头一个月完成100次提交和10000次添加或删除，那么你可能需要重新审查计划。

不管怎样，不妨尽可能关注编程。你不必事先考虑架构、测试、编程规则或之类的事情，因为你可以边编程边考虑这些事情。如果你首先正视代码编写，就会找到与项目兼容的度量指标。

“你的意思是，我必须一开始就要重写我写的所有代码，是吗？”

是的，你说得对。如果你犯了错误，就重写代码。没有人能够在不遇到失败的情况下完成代码重构。

“话虽如此，还是很难挤出时间写这么多的代码。”

你可能会遇到一些问题，比如办公室会议太多、项目前期时间太长，或者你自身的技能不足。然而，没有什么是一蹴而就的。同样，你没必要寻找银弹，只需不断地努力。

有志者，事竟成。

原文链接：https://medium.com/@
cafedeichi/massive-project-code-refactoring-tips-4a973c3bcc7f

来源： 51CTO技术栈