【发布时间】：2010-10-06 10:09:18
【问题描述】：
我知道这是一个广泛的话题，但我对 .NET 的任何所谓的最佳实践都感兴趣，尽管我正在寻找不太明显的那些，不像“使用 as 而不是强制转换”。
让我们看看我可以从 Stack Overflow 用户那里学到什么有趣的东西。
【问题讨论】：
标签： .net
【发布时间】：2010-10-06 10:09:18
【问题描述】：
首先，查看patterns & practices - “使用 Microsoft 的成熟实践进行软件工程。”。
接下来查看 IDesign：.NET 设计和流程解决方案。
在您深入了解这些以获得一些想法后，请确保在您的代码库上启用代码分析/FxCop。开始彻底检查每个警告。
最后但并非最不重要的一点是，查看JetBrains'软件并获取ReSharper。如果您想要 100% 的效率并确保您的代码达到高标准且头痛程度最低，那么 ReSharper（或类似的工具，其中一些可用）是必不可少的！ :)
这将使您了解 99% 的标准和最佳实践。
【讨论】：
-
我实际上会使用 CodeRush，但是嘿，每个人都有自己的偏好吧！ :)
-
所有中肯的建议，阿德隆。我还会为 Resharper 添加 StyleCop (code.msdn.microsoft.com/sourceanalysis) 和 StyleCop (codeplex.com/StyleCopForReSharper)。还有一些不错的 ReSharper 插件，例如 Agent Smith (jetbrains.com/resharper/plugins/#Agent_Smith_11.8)。
一个有趣的练习是通过FxCop 等静态分析工具运行您的代码。 它将带来许多提示。有些可能适合您的应用程序，有些则不适合。例如。国际化。
【讨论】：
-
你也可以自己写规则！
【讨论】：
-
同意；瓦格纳有很多很好的建议！
了解如何使用Reflector。它会教给你比你想象的更多的东西。
【讨论】：
-
它会教什么？您多久使用一次？
-
例如，我查看了 Professional Ajax.NET 程序集的内部并试图了解 Michael 是如何编写它的。在查看该程序集之前，我不知道资源嵌入。每当我看到一个新组件时，我都会使用它。
-
请注意，在方法内部，代码可能会被优化破坏。
对于 OO 代码，您可能需要查看 SOLID principles。但是some argue 他们妨碍了成品。
【讨论】：
-
但这些是我在主题中提到的显而易见的，不是吗？
-
我不了解您的背景或经验。对某些人来说，这当然不是显而易见的。此外，最好的“最佳实践”是简单的。
我发现这个提示非常有用：在 web.config 的 system.web 标签中设置部署零售=“true”将强制调试标志为“false”。它还将强制用户使用自定义错误消息页面并禁用页面输出跟踪。这在应用程序进入生产环境时很有用。
Test Driven .Net 是在 Visual Studio 中运行 NUnit 测试的出色工具。
【讨论】：
让我们看看我有什么有趣的事情 可以向 Stack Overflow 用户学习。
这可能并不完全符合“最佳实践”的目标，但您肯定会感兴趣。看起来 Stack Overflow 已经记录了一些实践、提示和技巧。
对于 .NET：
对于 C#：
【讨论】：
Framework Design Guidelines：Cwalina 和 Abrams 的可重用 .NET 库的约定、惯用语和模式（第 2 版）解释了 FxCop 规则背后的原因等等。并非所有这些都适用于您的项目，但是通过阅读本书，您将学习到许多最佳实践。我经常提到它。
【讨论】：
这些并不是 .NET 特定的，而是更通用的设计：
一个立即浮现在脑海中的（因为我今天已经看到这个并且一直在抱怨它，并且之前已经看过太多次了）是使用条件检查来包装代码以检查损坏的不变量，以避免异常。
因此，您最终会得到一个系统，其中某些功能无法正常工作，并且您不知道为什么会出现这种情况，并且对原始原因的信息为零。
我本周看到的一个很好的例子是，我们的一位工程师对 UI 框架 (WPF) 负责分配的成员变量进行了空引用检查。然后，这些检查避免了执行会导致 null ref 异常的操作。因此，如果发生这种（灾难性错误），我们会禁用功能，让用户感到困惑，并让支持团队感到愤怒。
所以，快速失败，明显失败（如果可能的话）并记录尽可能多的信息。
我最喜欢的另一个指导原则是尽量减少可变性。在可能的情况下，我更喜欢设计不可变的类。由于多核问题和并发设计的需要，不变性现在变得越来越流行。我开始使用它虽然很久以前需要用复杂的共享状态图来简化系统。我根据与 .NET 的 String 和 StringBuilder 类似的想法对系统进行建模（有时使用构建器类来构建不可变对象很方便，特别是在它相当复杂的情况下）。
这实际上是我对这个特定组件的第二个版本。我发现设计以最小化可变性并实现不可变类大大简化了代码库。
我发现，即使在设计并发系统时，也很少有工程师会考虑这个因素，而且往往最终会得到大量极其复杂的脆弱代码。我通常对他们可以让它发挥作用的方式印象深刻！但是，就我个人而言，真正好的代码应该看起来很简单。
问候， 菲尔
【讨论】：
我发现有人询问 X 的最佳实践是什么，他们通常需要停下来学习思考，而不仅仅是从某人那里得到一份神奇的清单。没有 5 或 6 个项目的神奇清单，但很多时候很多是常识。想想你想要实现什么，以及这段代码是如何在你的环境中执行的。
个人问这种问题对我来说是一个即时停止信号，因为它表明这个人没有尝试过自己思考，而且很可能永远不会。开发工作中最重要的属性是解决问题和逻辑思考任务的能力。学习语法，图书馆只是一个练习，它不是全部。任何开发人员都可以查看一个新的 API，并通过一些试验和错误来提供其不完全垃圾的理解。
开发不是一项仅仅遵循列表的机器人任务，这里的每个类/组件/插入构建块都是不同的，需要思考和理智。
【讨论】：
这不是 .NET 特定的，但我认为最重要的是 SOLID 原则。 Robert Martin（又名 UncleBob）有一个很好的参考 here。 我将引用最重要的部分：
- SRP 单一职责原则 一个类应该有一个并且只有一个改变的理由。
- OCP 开放封闭原则 您应该能够扩展类行为， 无需修改。
- LSP Liskov 替换原则 派生类必须可以替换它们的基类。
- DIP 依赖倒置原则依赖于抽象，而不是具体。
- ISP 接口隔离原则 制作特定于客户端的细粒度接口。
Steven Bohlen 在dimecasts.net 上制作了一系列关于他们的简短网络广播。
【讨论】：