自从我开始使用 .NET 以来，我一直在创建 Helper 类或 Partial 类来将代码定位并包含在它们自己的小容器等中。
我想知道的是使代码尽可能干净和优美的最佳实践。
显然干净的代码是主观的，但我说的是何时使用事物（而不是如何使用它们），例如多态性、继承、接口、类以及如何更恰当地设计类（使它们更有用，而不仅仅是说' DatabaseHelper'，因为有些人认为代码中的这种不良做法有wiki 的味道）。
是否有任何资源可以帮助做出这种决策？
请记住，我什至没有开始学习计算机科学或软件工程课程，而且现实生活中的教学资源相当有限。
让我大开眼界的是重构：改进现有代码的设计：
通过适当的培训，熟练的系统设计人员可以采用糟糕的设计并将其改造成设计良好、健壮的代码。在本书中，Martin Fowler 向您展示了通常可以在哪里找到重构的机会，以及如何将糟糕的设计改造成好的设计。
它帮助我高效、系统地重构代码。在与其他开发人员讨论时，它也对我有很大帮助，当他们holy code必须改变时......
Jeff Atwood 发表了一篇关于重构和代码异味的精彩博客文章，您可能想查看一下。
在 .NET 中重构代码需要一些时间来理解。你需要了解一些面向对象的设计原则（或设计技巧）才能有效地、无情地进行重构。
简而言之，您重构代码是为了消除代码异味并使更改更容易进行。另外，不要过度。
这是对名为Clean Code的书的斜线点的评论。
这本书显然有点干，但非常好。
查看Martin Fowler 的评论和关于重构的书
我推荐领域驱动设计。我认为 YAGNI 和 AlwaysRefactor 原则都是两个简单化的原则。关于这个问题的古老问题是我是否将“if（someArgument == someValue）”重构为一个函数或将其保留为内联？
没有是或否的答案。如果测试代表业务规则，DDD 建议对其进行重构。重构不仅仅是（仅）关于重用，而是关于明确意图。
Working Effectively with Legacy Code是我看过的关于这个主题的最好的书之一。
不要拖延书名——这本书没有将重构视为一个正式的概念（它有它的位置），而是有很多很多简单的“我为什么没想到”的技巧。诸如“通过一个类并删除任何不直接与该类相关的方法并将它们放在不同的类中”之类的事情。
例如，您有一个网格和一些代码来将该网格的布局保存到文件中。您可能可以安全地将布局持久化代码移到不同的类。
我的经验法则是让代码的形状不会比你发现的更糟。
我们的想法是朝着更好的方向努力，而不是试图达到完美的结果，或者一路走下去。
个别重构有时有一个值得怀疑的好处，并且 - 作为一个极端的例子 - 确实可能会争论是否m_Pi是一个比m_PI. 然而，大多数情况下，一个选择更一致，即使不是明显“更好”，也不那么令人惊讶。
我经常发现自己自动重构的一种情况是在一段代码上实现功能之前。
经常有一些 TODO 等待提供，一些不一致或有时自定义功能最近获得了更好的库支持。在实现实际功能请求之前进行这些更改可以让我对代码有所了解，并验证“之前”功能。
另一点是在修复错误之后。之后，因此之前的重现不受影响，并且错误修复和重构是两个单独的提交。
我刚刚得到了一份 Code Complete 的副本，发现有一个关于这个的部分。
尽管我仍将阅读公认答案的书，但 Code Complete 教给我的内容极大地改善了我对设计课程的看法。
在今天之前，我不知道 ADT 是什么（抽象数据类型），现在我知道了如何开发遵循封装的类。
在http://www.refactoring.com/上有一个专门用于重构的网页。它提供了许多关于重构代码主题的更多资源的参考，以及一个讨论重构相关问题的邮件列表。
最后但并非最不重要的一点是，有一个很大的（并且还在增长的）可用的重构目录，它远远超出了 Martin Fowler 的（非常推荐的）重构书中所写的内容。
