C# 重构代码：什么时候做什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/161975/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Refactoring Code: When to do what?
提问by RodgerB
Ever since I started using .NET, I've just been creating Helper classes or Partial classes to keep code located and contained in their own little containers, etc.
自从我开始使用 .NET 以来，我一直在创建 Helper 类或 Partial 类，以将代码定位并包含在它们自己的小容器等中。
What I'm looking to know is the best practices for making ones code as clean and polished as it possibly could be.
我想知道的是使代码尽可能干净和优美的最佳实践。
Obviously clean code is subjective, but I'm talking about when to use things (not how to use them) such as polymorphism, inheritance, interfaces, classes and how to design classes more appropriately (to make them more useful, not just say 'DatabaseHelper', as some considered this bad practice in the code smells wiki).
显然，干净的代码是主观的，但我谈论的是何时使用（而不是如何使用它们），例如多态性、继承、接口、类以及如何更恰当地设计类（使它们更有用，而不仅仅是说“ DatabaseHelper'，因为有些人认为代码气味 wiki中的这种不好的做法）。
Are there any resources out there that could possibly help with this kind of decision making?
是否有任何资源可能有助于此类决策？
Bare in mind that I haven't even started a CS or software engineering course, and that a teaching resource is fairly limited in real-life.
请记住，我什至还没有开始 CS 或软件工程课程，而且现实生活中的教学资源相当有限。
采纳答案by Andre Bossard
A real eye-opener to me was Refactoring: Improving the Design of Existing Code:
让我大开眼界的是重构：改进现有代码的设计：
With proper training a skilled system designer can take a bad design and rework it into well-designed, robust code. In this book, Martin Fowler shows you where opportunities for refactoring typically can be found, and how to go about reworking a bad design into a good one.
通过适当的培训，熟练的系统设计人员可以将糟糕的设计改造成设计良好、健壮的代码。在这本书中，Martin Fowler 向您展示了通常可以找到重构机会的地方，以及如何将糟糕的设计改造成好的设计。
It helped me to efficiently and systematically refactor code. Also it helped me a lot in discussions with other developers, when their holy codehas to be changed ...
它帮助我高效且系统地重构代码。在与其他开发人员的讨论中，当他们holy code必须改变时，它也帮助了我很多......
回答by SmacL
Check out Martin Fowler'scomments and book on Refactoring
查看Martin Fowler关于重构的评论和书籍
回答by Omar Kooheji
Here is a review on slash dot of a book called Clean Code.
这是对名为Clean Code的书的斜线点的评论。
The book is apparently a little dry but very good.
这本书显然有点枯燥，但非常好。
回答by Spoike
Jeff Atwood made a nice blog post on refactoring and code smells, you might want to check that out.
Jeff Atwood 发表了一篇关于重构和代码异味的不错的博客文章，您可能想查看一下。
Refactoring code in .NET takes some time to grok. You need to know some object-oriented design principles(or design techniques) in order to refactor effectivelyand mercilessly.
在 .NET 中重构代码需要一些时间来理解。您需要了解一些面向对象的设计原则（或设计技术），以便有效且无情地进行重构。
In short, you refactor code in order to remove code smells and make changes easier to do. Also, don't overdo it.
简而言之，您重构代码以消除代码异味并使更改更容易进行。另外，不要过度。
回答by Ilya Kochetov
- Re-factor you code when it is causing problems. Any problems will do: performance, scallabillity, integration, maintainance - anything which makes you spend more time on it when you should. It it is not broken do not fix it even if you do not believe it is clean or is up to the modern standards.
- Don't spend too much time making the code perfect. You will never achieve perfection but you could spend lots of time trying to do so. Remember the law of diminishing returns.
- Inside a project only re-factor the code when you are actually working on the functionality which depends on it. I.e. if you have a user story for the iteration calls for a "change the upload mechanism" or "fixing the bug in the file upload" you could re-factor the file uploading code. However if your user story is about "facelifting the file upload UI design" do not go into the business logic.
- 当代码出现问题时，重新考虑你的代码。任何问题都可以解决：性能、可扩展性、集成、维护——任何让你在应该的时候花更多时间在上面的东西。即使您认为它不干净或不符合现代标准，也不要修理它。
- 不要花太多时间使代码完美。你永远不会达到完美，但你可以花很多时间去尝试做到这一点。记住收益递减规律。
- 在项目中，只有在您实际处理依赖于它的功能时才重构代码。即，如果您有一个迭代的用户故事需要“更改上传机制”或“修复文件上传中的错误”，您可以重构文件上传代码。但是，如果您的用户故事是关于“整容文件上传 UI 设计”，请不要进入业务逻辑。
回答by Goran
I'd recommend Domain Driven Design. I think both YAGNI and AlwaysRefactor principles are two simplistic. The age old question on the issue is do i refactor "if(someArgument == someValue)" into a function or leave it inline?
我会推荐领域驱动设计。我认为 YAGNI 和 AlwaysRefactor 原则都是两个简单化的原则。关于这个问题的古老问题是我是将“if(someArgument == someValue)”重构为一个函数还是让它内联？
There is no yes or no answer. DDD advises to refactor it if the test represents a buisiness rule. The refactoring is not (only) about reuse but about making the intentions clear.
没有是或否的答案。如果测试代表商业规则，DDD 建议重构它。重构不仅仅是（仅）关于重用，而是关于明确意图。
回答by Gus Paul
Working Effectively with Legacy Codeis one of the best books I have seen on this subject.
《有效地使用遗留代码》是我看过的关于这个主题的最好的书之一。
Don't be put off the title of the book - Rather than treating Refactoring as a formal concept (which has its place), this book has lots and lots of simple "why didn't I think of that" tips. Things like "go through a class and remove any methods not directly realted to that class and put them in a different one".
不要被书名所拖延——本书没有将重构视为一个正式的概念（它有它的位置），而是有很多简单的“我为什么没想到”的提示。诸如“遍历一个类并删除与该类没有直接关联的任何方法并将它们放在不同的方法中”之类的事情。
e.g. You have a grid and some code to persist the layout of that grid to file. You can probably safely move the layout persisting code out to a different class.
例如，您有一个网格和一些代码来将该网格的布局保存到文件中。您可能可以安全地将布局持久化代码移出到不同的类。
回答by RodgerB
I just got a copy of Code Complete, and found that there was a section on this.
我刚刚拿到了 Code Complete 的副本，发现有一节是关于这个的。
Although I will still be reading the accepted answer's book, what Code Complete has taught me has dramatically improved the way I think about designing classes.
尽管我仍会阅读已接受答案的书，但 Code Complete 教给我的内容极大地改善了我对课程设计的思考方式。
Before today, I didn't know what an ADT was (abstract data type), and now I know how to develop classes adhering to the encapsulation.
在今天之前，我不知道 ADT 是什么（抽象数据类型），现在我知道如何开发遵循封装的类。
回答by Frerich Raabe
There's a web page dedicated to refactoring at http://www.refactoring.com/. It features many references to further resources on the topic of refactoring code as well as a mailing list to discuss refactoring-related issues.
http://www.refactoring.com/ 上有一个专门用于重构的网页。它提供了许多关于重构代码主题的更多资源的参考，以及一个讨论重构相关问题的邮件列表。
Last but not least, there's a big (and still growing) catalog of refactorings available which extends well beyond what's written in the (very much recommended) Refactoring book by Martin Fowler.
最后但并非最不重要的是，有一个很大的（并且还在不断增长）可用的重构目录，远远超出了 Martin Fowler 的（非常推荐的）Refactoring 书中所写的内容。
回答by peterchen
My rule of thumb is to leave the code in no worse shape than you found it.
我的经验法则是不要让代码比你发现的更糟糕。
The idea is to work towards the better, without trying to achieve the perfect result, or go all the way.
这个想法是朝着更好的方向努力，而不是试图达到完美的结果，或者一路走下去。
Individual refactorings sometimes have a questionable benefit, and - as an extreme example - it might indeed be argued if m_Piis a better name than m_PI. However, most often one choice is more consistent, and less surprising even if not obviously "better".
个别重构有时会带来值得怀疑的好处，并且——作为一个极端的例子——确实可能会争论是否m_Pi是一个比m_PI. 然而，大多数情况下，一种选择更加一致，即使不是明显“更好”，也不那么令人惊讶。
One situation where I regulary find myself refactoring automatically is beforeimplementing a featureon a piece of code.
我经常发现自己自动重构的一种情况是在对一段代码实现功能之前。
There are often a few TODO's waiting to be fed, some inconsistencies or sometimes custom functionality that has lately acquired better library support. Doing these changes before I implement the actual feature request gives me some understanding of the code, and I verify the "before" functionality.
通常有一些 TODO 等待提供，一些不一致或有时自定义功能最近获得了更好的库支持。在我实现实际功能请求之前进行这些更改让我对代码有了一些了解，并且我验证了“之前”的功能。
Another point is afterfixing bugs. After, so the before-repro isn't affected, and the bug fix and the refactoring are two separate commits.
另一点是在修复错误之后。之后，所以 before-repro 不受影响，并且错误修复和重构是两个单独的提交。
