我们都知道重构是好的,我和下一个人一样喜欢它,但是你有真正的案例,最好不要重构吗？
像时间关键的东西或同步？技术或人为原因同样受到欢迎.真实案例场景和经验加分.
编辑:从目前为止的答案来看,看起来不重构的唯一理由就是金钱.我的问题主要与这样的事情有关:假设您想要执行"提取方法",但是如果添加额外的函数调用,则会使代码稍微快一点并阻碍非常严格的同步.只是为了让你知道我的意思.
我有时听到的另一个原因是"用于当前代码布局的其他人会因你的更改而烦恼".当然,我怀疑这是一个很好的理由.
Jim*_*ans 15
我非常喜欢重构以保持代码清洁和可维护.但是,您通常希望回避重构生产模块,这些模块工作正常并且不需要更改.但是,当您确实需要处理模块来修复错误或引入新功能时,一些重构通常是值得的,并且不会花费太多,因为您已经承诺执行一整套测试并完成发布处理.(单元测试非常有用,但只是完整测试套件的一部分,正如其他海报所述.)
更重要的重构可能会让其他人更难找到新代码,然后他们可能会对重构做出不利的反应.为了最大限度地减少这种情况,请使用对编程等方法将其他团队成员引入流程.
更新(8/10):不重构的另一个原因是当你没有以适当的谦逊和尊重接近现有的代码库时.有了这些品质,你会倾向于保守,只做重构才真正有所作为.如果你过于傲慢地接近代码,你最终可能只是做出改变而不是重构.这个新方法名称是否更清晰,或旧的方法名称在您的应用程序域中具有非常特定的含义？当现有风格符合项目指南时,您是否真的需要将源文件机械地重新格式化为您的个人风格？再次结对编程可以帮助.
Ale*_*lli 12
为了强化另一个答案(并触及你提到的问题):在所有相关类型的测试都能很好地覆盖代码之前,不要重构代码的一部分.这并不意味着"不重构它" - 重点是"添加必要的测试"(正确地进行单元测试可能需要一些重构,特别是引入工厂DP和/或依赖注入DP)现在已经完全固定到具体依赖项的代码).
请注意,这确实涵盖了第二段的问题:如果代码的某一部分是时间关键的,那么"负载测试"应该很好地覆盖它(这类似于更常见的类型,正确性测试,应该覆盖两个特定的单元[尽管如此]性能方面 - 正确性检查是其他测试的业务! - )]和端到端操作 - 相当于单元测试和集成测试,如果一个人在谈论正确性而不是性能).
具有微妙同步问题的多任务代码可能是一场噩梦,因为没有任何测试可以让你对它完全有信心 - 没有其他重构(可能以任何方式影响任何现在似乎正在运行的脆弱同步)应该被认为是之前的一个旨在使同步更多,更强大和更健全(通过保证线程安全队列的消息传递是我最喜欢的设计模式在这方面;-).
cmd*_*com 10
嗯 - 我不同意上述(第一反应).给定没有测试的代码,您可以重构它以使其更易于测试.
如果无法及时测试生成的代码以便对代码进行交付,那么您不会重构代码.
当您的重构不会提高代码质量时,您不会重构代码.质量不是主观的,尽管有时可能是设计.
当没有商业理由进行更改时,您不会重构代码.
可能还有更多,但希望你能得到这个想法......