重构:你什么时候知道它的时间和时间？

你什么时候知道重构/审查一些代码的时候了？更好的是,你什么时候做的？

可能和其他人一样,我发现自己知道某些事情需要重构/审查,但截止日期和管理层都没有时间.我还想听听您如何在一般开发过程中包含代码审查.

最近我发现自己在处理新功能/代码之前就已经这样做了.例如,如果我必须在应用程序的模块X中开发新内容或更改某些内容,我会对该模块进行代码审查.我发现它也有助于我更好地理解模块,因此我可以更轻松地进行更改.

所以你什么时候知道它的时间和时间呢？最重要的是,您如何将其纳入项目规划中？

重构不是我留出时间单独做的事情.我在开发新代码时,或者在维护旧代码时不断地这样做.按照正常的惯例进行操作,并始终寻找可以在代码中改进的内容.

为了回答您在自己对这个问题的回答中添加的具体案例:我认为您的情况是一个完美的例子,说明何时重构而不是完全重写是个好主意.在更改一行代码之前,请确保为相关代码编写了一组良好的测试用例.如果代码未通过某些测试,则会有三个目的.首先,它将为您提供专注的工作重点.其次,它会给你一个充分的理由(对你的老板)来处理代码.第三是您在重构代码时希望使用的标准单元测试安全网.

标准的TDD方式是Red-Green-Refactor:使测试失败,编写代码以通过测试,然后在仍然通过测试的同时重构现有代码.在测试通过后以及当您发现代码太复杂或使用错误模式时,会发生重构.重构应该是正常的日常开发过程的一部分,而不是开发周期结束时的附加组件.我认为,它更好地保持重构很小.将其作为常规活动的一部分,可以防止糟糕的代码在重构发生之前变得过大 - 至少在理想情况下如此.