我在这里有一个奇怪的问题。
我是唯一一个不断感觉我必须重写/重构自己代码的程序员吗？
有时我这样做只是因为我认为速度可能会提高，或仅仅因为我相信 代码可以在以后的项目中轻松导入。
嘿，有时候只是因为我的眼睛看起来更干净。我生病了吗？我是完美主义吗？我是唯一一个遇到这个问题的人吗？
答案 0 :(得分：12)
看看TDD。基本前提是：
作为一般原则，我认为积极的重构是一个好主意 - 为什么还有更多的代码而不是你真正需要的代码。困难分为两部分，第一部分，为什么重构没有目的;第二部分，如果你没有一套可以测试重构版本的测试，你怎么知道你没有在功能上改变重构代码？ TDD是对这两方面的回答。
我鼓励你养成重构的习惯，但我也鼓励像TDD这样的练习，这样你就不会破坏你的代码。
HTH
答案 1 :(得分：7)
您可能正在体验对问题的迭代理解。你为它做了一个刺，然后当你完成后，你已经获得了一些新的见解。您应用的这种新见解，只是为了了解您再次获得新见解，因此您将部分代码丢弃并重写。
如果认为，您不应该更快地更改代码。您应该通过分析或挂钟运行测量。你应该知道你需要什么级别的代码改进。有些代码需要很少的速度改进就足够了。
答案 2 :(得分：7)
不，你并不孤单。我说这正是一个优秀的程序员 - 从不满足于你正在做的事情，渴望提高自己，而不是一遍又一遍地重复同样的事情。
答案 3 :(得分：3)
有时我会重构以使其更容易阅读或运行更快，或更容易扩展。然而，在具有最后期限并为自己工作的现实世界中，如果您有理由这样做，您只能负担得起！
答案 4 :(得分：3)
我发现这个经验法则很有用： “我不应该花费更多的时间来重构，而不是实现用户请求的功能。”
关于如何改进代码，我可能还有很多其他的想法，但我觉得每次使用它都会有所改进，而不是试图用所有代码同时实现“完美”
这就像童子军的座右铭：保持比你发现它更好。
答案 5 :(得分：3)
在项目的早期阶段，您应该不断进行重构。您可能不会直接找到最佳解决方案，而且需求变更可以使以前完美的解决方案不是最理想的。
然而，一旦你经历了几次集成和UAT测试周期，我就会开始对重构持谨慎态度。毕竟，您已投入时间和精力来验证您拥有的代码;重构将浪费这项测试工作，并要求重复整个测试周期。
答案 6 :(得分：2)
就我个人而言，我更倾向于使用上述代码/某人而不是代码，而不是第一次尝试后离开它的人。请务必不要进入gold plating。
答案 7 :(得分：2)
这一切都取决于，如果你能负担得起重构，这意味着你的队列中没有其他更重要的任务，那么重构成“更容易阅读”的代码总是好事;）
这也取决于具体情况。如果您是更大团队的一员，那么重构可能意味着其他开发人员可以更快地学习您的代码。
虽然重构有时会发现QA或文字夹具无法看到的问题/案例，但也有可能产生其他可能看不到的问题......需要注意的事项。
如果您：
，我会说继续重构一段代码凌乱的代码=在整个地方声明变量，不使用面向对象的原则，不封装代码片段并多次重写相同的代码，遍布各处！恶意加入，没有评论等......等等......
有人有更多病例吗？
答案 8 :(得分：2)
你问的是重写和重构，我担心答案会有所不同。如果你经常重构，你基本上不需要重写。重构完成后，将代码置于理想状态以满足其当前需求，无需重写。那是件好事。
您列出了许多原因：
其中，我会说丢弃＃1和＃2，并坚持只＃3。这就是原因。重构不应该改变行为，因此重构的代码应该与原始代码完全相同（对此有一些边缘情况警告，但从不将重构视为优化方法）。优化规则是：
优化通常更多的是重写而不是重构。重构可以让你进入更好的优化位置（想象一下Extract Method），但它通常不会使你的代码本身更具性能。因此，不要重构“使代码更快;”在使代码更快的过程中重构，因为你正在优化 - 而不是一时兴起。
关于可重用性 - YAGNI。当“后期项目”出现时 - 如果有的话 - 并且你知道你可以从之前的项目中借用一些东西，如果它只是有点不同 - 那就是重新设计的时候，以满足新的需求。在该项目存在之前，您已经重构了第一个项目的代码，以便理想地满足其（单项目）需求;只有当新需求出现时，另一种设计才更令人满意。不要期待。等待驱动你的设计的需要。
底线：重构以使代码更好地满足其直接需求。使其可读，使其可维护。使用重构来支持其他操作 - 但不是预期它们。并且不要一直对重构感到害怕。如果您的代码出现问题，最好修复它。
答案 9 :(得分：1)
我也这样做。从长远来看，我希望它能让我立即编写代码更清晰，更快，更可重复等等。我相信，它已经发生了。在我入侵之前，我会越来越多地考虑新的代码行。所以我希望将来可以减少重构。但相信我只能通过重构来实现目标。