自从我开始使用.NET以来，我一直在创建Helper类或Partial类，以保持代码位于并包含在自己的小容器中等。
我想知道的是使代码尽可能干净和完美的最佳实践。
显然干净的代码是主观的，但我在谈论什么时候使用东西（不是如何使用它们），比如多态，继承，接口，类以及如何更恰当地设计类（使它们更有用，而不是只是说'DatabaseHelper'，因为有人认为这是code smells wiki中的不良做法。
那里有没有可能有助于这种决策的资源？
请记住，我甚至没有开设过CS或软件工程课程，而且教学资源在现实生活中相当有限。
答案 0 :(得分：23)
让我大开眼界的是Refactoring: Improving the Design of Existing Code：
通过适当的培训，熟练的系统 设计师可以采取糟糕的设计和 将其重新设计为精心设计，坚固耐用 码。在这本书中，马丁福勒 告诉你哪里有机会 通常可以找到重构， 以及如何重新处理坏事 设计成一个好的。
它帮助我高效，系统地重构代码。当他们的holy code必须改变时，它也帮助我与其他开发人员进行了很多讨论......
答案 1 :(得分：11)
杰夫阿特伍德做了一个nice blog post on refactoring and code smells，你可能想要检查一下。
在.NET中重构代码需要一些时间来解决。您需要了解一些面向对象的design principles（或design techniques）才能refactor effectively和mercilessly。
简而言之，您重构代码以删除代码气味并使更改更容易。另外，不要过度。
答案 2 :(得分：5)
以下是对一本名为Clean Code的书的斜线点的评论。
这本书显然有点干，但非常好。
答案 3 :(得分：2)
查看Martin Fowler's条评论并预订Refactoring
答案 4 :(得分：1)
答案 5 :(得分：1)
我建议Domain Driven Design。我认为YAGNI和AlwaysRefactor原则都是两个简单化的。关于这个问题的古老问题是我将“if（someArgument == someValue）”重构为函数还是将其保留为内联？
没有是或否答案。如果测试代表商业规则，DDD建议重构它。重构不仅（仅）关于重用，而是关于使意图明确。
答案 6 :(得分：1)
Working Effectively with Legacy Code是我在这个主题上看过的最好的书之一。
不要把这本书的标题推迟 - 这本书不是将重构作为一个正式的概念（有它的位置），而是有很多很简单的“为什么我没有想到”的提示。诸如“通过一个类并删除任何不直接在该类中实现的方法并将它们放在另一个类中”之类的事情。
e.g。您有一个网格和一些代码来保持该网格的布局文件。您可以安全地将布局持久代码移出到另一个类。
答案 7 :(得分：1)
我的经验法则是让代码保持不比你发现的更糟糕。
我们的想法是朝着更好的工作，而不是试图获得完美的结果，或者一直走下去。
个人重构有时会带来可疑的好处，并且 - 作为一个极端的例子 - 如果m_Pi比m_PI更好，那么确实可能会有争议。然而，大多数情况下，一种选择更加一致，即使没有明显“更好”也不会令人惊讶。
我经常发现自己重构的一种情况是之前在一段代码中实现一个功能。
通常有一些TODO等待进食，一些不一致或有时候自定义功能最近获得了更好的库支持。在实现实际功能请求之前执行这些更改可以让我对代码有所了解，并验证“之前”功能。
另一点是在修复错误之后。之后，所以之前的repro不受影响，错误修复和重构是两个单独的提交。
答案 8 :(得分：0)
我刚收到Code Complete的副本，发现有一节关于此。
虽然我仍然会阅读已接受的答案书，但Code Complete教给我的内容大大改善了我对设计课程的看法。
在今天之前，我不知道什么是ADT（抽象数据类型），现在我知道如何开发坚持封装的类。
答案 9 :(得分：0)
有一个专门用于http://www.refactoring.com/重构的网页。它提供了许多关于重构代码主题的更多资源的参考，以及一个讨论重构相关问题的邮件列表。
最后但并非最不重要的是，有一个很大（并且仍在增长）的重构目录，它远远超出了Martin Fowler在（非常推荐的）重构书中所写的内容。
