重构代码：什么时候做？
自从我开始使用.NET以来，我一直在创建Helper类或Partial类，以保持代码位于并包含在自己的小容器中等。
我想知道的是使代码尽可能干净和完美的最佳实践。
显然干净的代码是主观的，但我在谈论什么时候使用东西（不是如何使用它们），如多态，inheritance，接口，类以及如何更恰当地设计类（使它们更有用，而不仅仅是说’ DatabaseHelper’，正如一些人认为代码中的这种不良做法闻起来wiki ）。
是否有任何资源可能有助于这种决策？
请记住，我甚至没有开设过CS或软件工程课程，而且教学资源在现实生活中相当有限。
对我来说真正令人大开眼界的是重构：改进现有代码的设计 ：
通过适当的培训，熟练的系统设计人员可以采用糟糕的设计，并将其重新设计为精心设计的强大代码。 在本书中，Martin Fowler向您展示了通常可以找到重构的机会，以及如何将糟糕的设计重新设计成一个好的设计。
重构http://ecx.images-amazon.com/images/I/519XT0DER6L._SL160_PIlitb-dp-arrow,TopRight,21,-23_SH30_OU01_AA115_.jpg
它帮助我有效和系统地重构代码。 当他们的holy code必须改变时，它也帮助我与其他开发人员进行了很多讨论……
杰夫阿特伍德撰写了一篇关于重构和代码味道的精彩博文 ，你可能想要检查一下。
在.NET中重构代码需要一些时间来解决。 您需要了解一些面向对象的设计原则 （或设计技术 ）才能有效和无情地 重构 。
简而言之，您重构代码以消除代码气味并使更改更容易。 另外，不要过度。
这是一本名为Clean Code的书的斜线点评。
这本书显然有点干，但非常好。
查看Martin Fowler对Refactoring 的评论和书籍
- 在代码导致问题时重新考虑代码。 任何问题都会出现：性能，scallabillity，集成，维护 – 任何让你在应该花费更多时间的事情。 即使您不相信它是干净的或符合现代标准，它也不会破坏它。
- 不要花太多时间使代码完美。 你永远不会达到完美，但你可以花很多时间尝试这样做。 记住收益递减规律。
- 在实际处理依赖于它的function时，项目内部只会重新考虑代码。 即如果您有用于迭代的用户故事调用“更改上载机制”或“修复文件上载中的错误”，您可以重新考虑文件上载代码。 但是，如果您的用户故事是关于“整理文件上传UI设计”，请不要进入业务逻辑。
我推荐Domain Driven Design 。 我认为YAGNI和AlwaysRefactor原则都是两个简单化的。 关于这个问题的古老问题是我将“if（someArgument == someValue）”重构为函数还是将其保留为内联？
没有是或否答案。 如果测试代表商业规则，DDD建议重构它。 重构不仅（仅）关于重用，而是关于使意图明确。
有效地使用遗留代码是我在这个主题上看到的最好的书籍之一。
不要把这本书的标题放在一边 – 这本书不是将重构作为一种正式的概念（有它的位置），而是有很多很简单的“为什么我没有想到”的提示。 诸如“通过一个类并删除任何不直接在该类中实现并将它们放在另一个类中的方法”之类的事情。
例如，您有一个网格和一些代码来保持该网格的布局文件。 您可以安全地将布局持久代码移出到另一个类。
我的经验法则是让代码保持不比你发现的更糟糕的形状 。
我们的想法是努力做到更好 ，而不是试图取得完美的结果，或者一路走下去。
个别重构有时会带来一些可疑的好处，并且 – 作为一个极端的例子 – 如果m_Pi比m_PI更好，那么确实可能会有争议。 然而，大多数情况下，一种选择更加一致，即使没有明显“更好”也不会令人惊讶。
我经常发现自己重构的一种情况是在实现一段代码之前。
通常有一些TODO等待提供，一些不一致或有时自定义function最近获得了更好的库支持。 在实现实际function请求之前进行这些更改可以让我对代码有所了解，并validation“之前”function。
另一点是修复错误。 之后，所以before-repro不受影响，错误修复和重构是两个单独的提交。
我刚收到Code Complete的副本，发现有一节关于此。
虽然我仍然会阅读已接受的答案书，但Code Complete教给我的内容大大改善了我对设计课程的思考方式。
在今天之前，我不知道ADT是什么（抽象数据类型），现在我知道如何开发遵循封装的类。
在http://www.refactoring.com/上有一个专门用于重构的网页 。 它提供了许多关于重构代码主题的更多资源的参考，以及讨论重构相关问题的邮件列表。
最后但并非最不重要的是，有一个很大（并且仍在增长）的重构目录，它远远超出了Martin Fowler在（非常推荐的）重构书中所写的内容。