第100篇博客：你最应该关注的5点开发实践。

 
   这是个很小的数字但是我很高兴达到这个数量，尤其是我每次都花几个小时去写每一篇博客。从2007年6月以来我一直努力保持每周一篇的博客速度。
我是NDepend（.net 开发者的工具）的主要开发者。这个博客通常用来告知读者工具的用途和新版本。NDepend的功能都围绕创新的软件开发观念构建。代码基础都围绕今天最复杂和昂贵的工程对象观念。像NDepend这样的工具在帮助工程师理解和控制开发过程中显得越来越必要。5年前在我利用业余时间开发NDepend时，一些开发伙伴甚至还不能理解这种工作的要点。如今，我相信围绕着NDepend的一些观念正在成为主流： 如果你还不能信服，你只需看一下visual studio 2010 的架构特点。
 
 在这篇博客，我尽量解释为什么有这些开发者观念还有这些观念都是什么样的。如果我要选择5个NDepend能起到帮助的重要的实践观念，那么我选择：
避免命名空间依赖循环。这将帮助你维持代码基础处于持续的干净的设计，这将对代码演化和维护有极大帮助。持续的干净设计拥抱演化设计在所有的敏捷方法中都很流行。

减少程序集的数量增加命名空间的数量。命名空间已经成为你的组件单元。利用命名空间而不是程序集去定义组件最大的优势在于命名空间是个逻辑的而程序集是物理上的。单个组件不能太小（能形成干净的大图而不需要太多的组件）也不能太大（对个体单元维护来说），每个命名空间包含1000到2000行代码看起来是合理的。采纳这个建议将极大的有助于敏捷需要的更出色的，逻辑的和可控制的组件化，更少的编译时间和更少的部署负担。

经常性的发布并且把你的精力集中在测试版本，最后一次发布版和新版本之间。

这些包括确保在每次发布之前添加和重构代码都能维持一个高质量。更具体的就是你要确保新代码在测试中代码覆盖率达到80%以上，并且做好增加的和重构的代码的复查。这将帮助你一步一步的弥补你技术上的缺陷。
4000
而且那些未被修改过的代码包含未知的bug(你将会关闭它们靠复查代码，是么？)，而且很可能在下一版本工作得很好。
严格的通过活动惯例在代码中强调意图。

一种活动惯例就是一种规则-如果初始的意图违反就应该被警告，多亏了代码查询语言（CQL）的支持，Ndepend覆盖了那些能够被声明包括控制的广泛的一序列活动惯例。
 
代码怎样构建（比如ui层不应该依赖于数据层或者循环依赖是不允许的）。

代码应该怎样被测试覆盖（比如，class A 应该维护100%的代码覆盖率，甚至是在它被重构以后）。

副作用如何发生和怎样发生（比如class A 应该保持不变而且方法M 应该保持单纯性）。

代码元素应该怎样被命名（比如接口名字应该以I开头）。

代码能怎样演化或不能怎样演化(比如这个特殊的算法不能够被改变)。

质量标准怎样被保证（比如我们不需要大而复杂的方法）。

怎样的代码异味是被禁止的（比如我们不想要写死的代码或者没有注释的代码）。

结点代码（tier code）怎样使用（比如像 Thread.Sleep(...)根本不应该被调用）

了解类型恒久性并且运用该强大观念。并行化你的代码将比序列化读取你的对象更加容易。

      坦率地说，我们严格的把这些观念运用到开发Ndepend中并且真的得到了回报。
      一些我写的其它博客谈到了如何在真实世界场景中利用Ndepend去分析流行的.NET 代码库，包括  CruiseControl.Net, NHibernate, NUnit, Silverlight 或者 .NET Framework.
 
     这篇博客同样是去分享我们面对的开发难题和我们发现的解决方案的机会。这些都可以从下面一些文章得到体现：GDI+ bugs,Windows Forms bugs, RichTextBox tips, usability issues, framework we are using like Cecil, LINQ details或者 performance tips.
     我同样对一些书做了一些书评包括 C# in Depth, LINQ in Action 和 WPF Unleashed。
我怀疑你将会看到我习惯性的去抨击一本书，当我决定去读一本软件书籍时我都试图去找一些符合我期望的内容。对我们大多数人来说，更经常的是存在大量我不喜欢的事情并且想去到处抱怨。但三思一下，我相信消极的谈话将给一些跛脚的主题更多的偏向，而这并不会取悦大量的读者。而且这样做将会给谈论积极的事情留下极小的空间。
我计划以这种方式继续我的博客。欢迎你的反馈和建议。
     翻译自：codebetter.com