自从我在软件公司获得经验以来，我发现很难容忍编码不整齐的代码，没有任何形式的架构或美观或清晰，无论它是否有效，即它应该做什么。
我发现我总是陷入这样的重构代码中，有时“自费”是我的舒适与生产力两难的地方。
处理您在经验中继承的糟糕编写代码的最快方法是什么？写你的或封装/重构什么，耗时？
答案 0 :(得分：10)
有时候最好的答案就是不管它在边界，除了它与更高质量的代码接口。界面清洁后，您可以随时清理内部的丑陋，或者只是更换它。但是如果没有这些界面墙，任何修复部分混乱的尝试都会像在毛衣上拉松线并看着它全部解开一样。
答案 1 :(得分：10)
我在前一天talking with Michael Feathers听到有关此主题的关于Hanselminutes的播客，其中有一本书：Working Effectively with Legacy Code。我鼓励阅读。我自己过去曾经处理过很多糟糕的遗留代码，并且通常认为你应该逐步重构/重写坏的部分，小心你不要造成太多的破坏，并对重构/重写的内容保持战略性。我也鼓励从Joel那里读到这篇文章：Things you Should Never Do, Part I
答案 2 :(得分：5)
如果有效，请不要管它。我们没有付出代价使代码看起来很漂亮，我们付出的代价是让它变得有用。我不是在提倡编写丑陋的代码，无论如何都要让你自己的代码变得如你所想的那样漂亮（当然，美丽是主观的）。请注意，更改有效的代码并不会带来任何商业利益，无论您认为它是多么丑陋。
向我展示一个客户关心代码的美感而不是其功能，我会向您展示一个将在五年内停业的客户。
如果该代码中存在错误，您可以考虑重构，但即便如此，这也应该是修复错误的第二步。
答案 3 :(得分：4)
根据您拥有的时间以及代码的真实程度，该方案的范围从抛弃所有内容并从头开始重写所有内容并保持原样，并从丑陋中解脱出来。
如果代码实际有效，即使它可能非常难看，重写一切也很可能不是一个选项。但是，如果没有重构，用新功能扩展代码可能是不可能的。花点时间做些小改动。经常编译和测试！
如果代码既错误又丑陋和，您还需要引入新功能。那么考虑重写整个事情可能真的值得。代码中只能有这么多的意大利面条，直到变得无法控制。
坚持下去。如果你在编码时感觉很糟糕和杂乱，因为代码是丑陋和令人讨厌的。只要开始逐一改变它，很快代码“将是你的”，你将知道代码的作用，你将它变成你的领地：）
干杯！
答案 4 :(得分：3)
最重要的经验法则：如果没有破坏，请不要修复它（即使它很难看）。
因此，除非代码中存在错误，或者您需要更新它以添加新功能，否则请勿触摸它。
第二条规则：如果可能，请确保在之前进行单元测试，即可开始重构。针对当前损坏的部件以及当前工作的部件的测试用例。
第三条规则：不要一次重写/重构所有内容。尝试将其分解为小型工作单元，并确保在开始下一个工作单元之前它们都能正常工作。
另外，我发现重写和替换（逐件）通常比重构更有效率。
答案 5 :(得分：3)
我会假设当你说你“继承它”时，你的意思是你被雇用到现有代码库乱七八糟的位置。另一种解释是它留在遗嘱中 - 这将非常酷，但不太可能......
我认为您可以做的最重要的事情是审核代码，识别风险并计划解决这些问题。这是解决问题的一种非常专业和有计划的方法，应该受到管理层的青睐。您需要非常清楚地沟通的是，您将通过重构工作为业务增加价值，因为它不一定会在短期内添加转化为销售（或任何业务）的功能。
好处包括：
您需要找到与业务驱动因素直接相关的重构原因。如果您不知道什么是潜水业务，那么请讨论一个可以提供帮助的适当管理类型。
我的建议非常简单 - 只要有充分的理由，重构就是好的。像“代码没有整齐的结构，没有任何形式的架构或美丽或清晰度”这样的原因并不足够。参与管理并让他们对改进的代码库给他们的可能性感到兴奋！
......然后交付它。如果你不这样做，你会看起来像个小丑。
答案 6 :(得分：1)
你的问题显然没有正确答案。在某些情况下，你重构。在其他人中，你从头开始。
答案 7 :(得分：1)
答案 8 :(得分：1)
尽你所能，但永远记住：这是他们的代码，而不是你的代码。
答案 9 :(得分：0)