重构代码之前你会考虑什么？
我有一个刚刚发布的应用程序。 自从我写它以来，我了解了 amfphp 和 propel。 在应用程序中使用两者都“很好”，但我不能说此时需要它。
在重构代码之前您会考虑哪些类型的事情？
I've got an application that just shipped. Since I wrote it, I've learned about amfphp and propel. Both would be 'nice' to be used in the application but I can't say that it would be required at this point.
What types of things do you consider before you refactor code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
进行单元测试来检查重构后的代码。
Have unit tests to check the code after refactoring.
所需的努力与收到的收益以及与其他工作的优先顺序。
Effort required versus benefit received and where it fits prioritywise with other work.
我是不是该？
仅仅因为我可以重构代码并不意味着我应该重构代码。 在很多很多情况下，还有更重要的事情需要完成。 就像修复缺陷一样。
现在，如果我们谈论重构代码，因为我已经在该特定的代码块中，并将其作为缺陷解决或代码维护的一部分进行处理，那就完全是另一回事了。 但重构只是为了重构？ 这听起来像是出于无聊而产生的忙碌。 您肯定没有空的缺陷列表。
Should I?
Just be cause I can refactor the code does not mean that I should refactor the code. In many, many cases, there are far more important things that need to be done. Like fixing defects.
Now, if we're talking about refactoring the code because I am already in that particular block of code and working on it as a part of defect resolution or code maintenance, that's a different story altogether. But refactoring just for the sake of refactoring? That sounds like busywork born out of boredom. Surely you don't have an empty defect list.
重构后的代码的可维护性如何。 事后看来是 20/20，但对于已发货的产品，优雅但神秘的设计维护起来可能是一场噩梦。 此外，重构设计的灵活性以允许功能增强也非常重要。
How maintainable the refactored code will be. Hindsight is 20/20 but with a shipped product, elegant but cryptic design can be a nightmare to maintain. Also, flexibility in the refactored design to allow for feature enhancements is very important.
我破坏现有功能的可能性有多大？ 单元测试是一个很好的安全网，自动重构工具也是如此。
之后代码真的会更容易理解和维护吗？ 这可能是一个很难回答的问题，需要经验才能更好地回答它。
How likely am I to break existing functionality? Unit Tests are a great safety net here as are automated refactoring tools.
Will the code really be easier to understand and maintain afterwards? This can be a difficult question to answer and it takes experience to get better at answering it.
在源代码管理中为当前生产代码库创建一个分支，并在源代码管理的实验分支中进行所有重构。
Create a fork for the current production code base in your source control and do all the refactoring in the experimental branch of the source control.
单元测试会非常好，但如果单元测试未覆盖代码，您应该采用其他方法来确保不会破坏代码。 如果您可以获得生产数据库的副本，甚至可能是一些实时产品输入，那么您应该有公平的机会。
在一个私人项目中，我们实际上记录了 14 天的所有传入数据，并在这 14 天的开始和结束时保存了生产数据库的快照，然后我们能够使用旧代码和新代码来比较数据库的状态。 但单元测试肯定会消除一些恐惧:-)
Unit test would be very nice, but if the code is not covered by unit tests you should have some other means to ensure that you don't break the code. If you can your hands on a copy of production databases, perhaps even some live prod input, you should have a fair chance.
In a privious project we actually recorded all ingoing data for 14 days and saved a snapshot of the prod db at the start and end of those 14 days and we were then able to compare the state of the db using the old code and the new code. But Unit tests sure would remove some of the fear :-)
我嗅探代码。 如果我不喜欢这种气味（换句话说，它闻起来不像我），那么我就会在上面撒尿，直到我喜欢为止。
由于软件技术需要像敏捷或设计模式这样很酷的名字，我称之为犬类重构。
重写代码后，我自己使用了一段时间，Eating My Own Dogfood。
I sniff the code. If I don't like the smell (in other words, it doesn't smell like me) then I pee all over it until I like it.
Since software techniques need cool names like Agile or Design Patterns, I call this Canine Refactoring.
After rewriting the code I use it for a while myself, Eating My Own Dogfood.
我必须给 Drejc +1。 不重构的最主要原因是没有单元测试。 但即便如此也不意味着你不应该重构。 我应该说，我的做法首先是代码功能，然后总是重构以处理设计债务。 重复令人作呕的事情。
“足够好”模式可能是地球上最常用的编程方法，这也是我们的软件充满缺陷和混乱的原因之一。 我们总是选择能量最少的“步骤”，而不是选择能量最少的“路径”。
但是，要小心！ 如果没有合适的工具（这取决于语言和 IDE），重构就像敲螺丝一样：你可以到达那里，但它不会有效（并且你可能会遇到麻烦）。
I have to give a +1 to Drejc. The single most reason why not to refactor is if you don't have unit tests. But even that doesn't mean you should not refactor. I should say that my modus operandus is code functionality first and then always refactor to deal with design-debt. Repeat ad-nauseaum.
The "good enough" pattern is probably the most used programming methodology on earth, and that's one reason why our software is buggy and messy. Instead of chosing the least energy "path", we always choose the least energy "step".
But, beware! Refactoring without the proper tools (and this will depend on the language and IDE) is like hammering a screw: you can get there, but it won't be effective (and you can get in trouble).