重构代码：什么时候做？自从我开始使用.NET以来，我一直在创建Helper类或Partial类以将代码定位并包含在它自己的小容器中等。我想知道的是使代码尽可能干净和完美的最佳实践.显然干净的代码是主观的，但我说的是什么时候使用东西（而不是如何使用它们），比如多态、继承、接口、类以及如何更恰当地设计类（使它们更有用，不仅仅是说'DatabaseHelper'，因为有些人认为代码中的这种不良做法有wiki的味道）。是否有任何资源可以帮助做出此类决定？请记住，我什至没有教过CS或软件工程课程，而且现实生活中的教学资源相当有限。真正让我大开眼界的是重构：改进现有代码的设计：通过适当的培训，熟练的系统设计师可以将糟糕的设计重新设计成设计良好的强大代码。在本书中，MartinFowler向您展示了您可以多久找到一次重构的机会，以及如何将一个糟糕的设计变成一个好的设计。重构http://ecx.images-amazon.com/images/I/519XT0DER6L._SL160_PIlitb-dp-arrow,TopRight,21,-23_SH30_OU01_AA115_.jpg它帮助我有效且系统地重构了代码。当他们的神圣代码必须更改时，它也对我与其他开发人员的讨论有很大帮助……JeffAtwood写了一篇关于重构和代码味道的很棒的博客文章，您可能想查看一下。在.NET中重构代码需要一些时间才能完成。你需要了解一些面向对象的设计原则（或设计技巧）才能有效和无情地进行重构。简而言之，您重构代码以消除代码异味并使更改更容易。另外，不要过度。这是对一本名为CleanCode的书的斜线评论。这本书显然有点枯燥，但非常好。查看MartinFowler对重构的评论和我推荐的领域驱动设计这本书。我认为YAGNI和AlwaysRefactor原则都是两种简化。关于这个主题的老问题是我将“if(someArgument==someValue)”重构为一个函数还是保持内联？没有是或否的答案。如果测试代表业务规则，DDD建议重构它。重构不是（仅）关于重用，而是关于使意图明确。UsingLegacyCodeEffectively是我所见过的关于该主题的最好的书籍之一。不要把这本书的标题放在一边——本书并没有把重构当作一个正式的概念（它有它的位置），而是充满了非常简单的“我为什么没想到它”的提示。诸如“通过一个类并删除该类中未直接实现的任何方法并将它们放入另一个类中”之类的东西。例如，您有一个网格和一些代码来维护该网格的布局文件。您可以安全地将布局持久性代码移到另一个类中。我的经验法则是保持代码的状态不比你发现时更糟。这个想法是要努力变得更好，而不是试图达到完美的结果，或者一路走下去。个别重构有时会产生可疑的好处，并且-作为一个极端的例子-m_Pi是否优于m_PI确实可能存在争议。然而，大多数时候，一种选择更为一致，即使不是明显“更好”也不足为奇。我经常发现自己重构的一种情况是在实现一段代码之前。通常有一些TODO等待提供，一些不一致或有时自定义功能最近获得了更好的库支持。在实现实际功能请求之前进行这些更改让我对代码有一个感觉并验证“之前”的功能。还有一点就是修复bug。之后，所以before-repro不受影响，错误修复和重构是两个单独的提交。我刚收到一份CodeComplete的副本，并找到了这方面的部分。虽然我仍在阅读已接受的答案书，但CodeComplete教给我的内容极大地改善了我对设计课程的思考方式。今天之前不知道什么是ADT（AbstractDataType），现在知道了类是如何封装后开发的。在http://www.refactoring.com/有一个专门用于重构的网页。它提供了对关于重构代码主题的更多资源的引用，以及用于讨论重构相关问题的邮件列表。最后但并非最不重要的一点是，有大量（而且还在不断增加）的重构目录，远远超出了MartinFowler在他（非常推荐的）关于重构的书中所写的内容。以上就是C#学习教程：重构代码：什么时候做？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
