最臭的臭弹（Biggest Stinkers）
[原文链接]
在 SDTConf 2009 论坛上，Corey Haines 和我共同主持了一个叫做“最臭的臭弹”的研讨会。会议上，我们试图去寻找下面两个（不同的）问题的答案：
- 作为一个经验丰富的开发人员，回顾往事，最臭的让你最受折磨的代码是什么样的？也就是说，请指出一种代码，如果你能根除掉这种很臭的代码，那么在你的程序中的大部分设计问题都会迎刃而解
- 我们有如此多的不同的原则和指导来帮助我们去实现好的设计。对于一个新手来说，他应该从哪里开始？哪种代码风味（code smell）或原则，对于一个新手来说，可以最大程度的帮助他们做出好的设计（节省好几年去总结经验）？
尽管字面上这两个问题很相似，但我认为这第二个问题更具有广泛的意义，跟第一个有很大的不同。
不管怎样，这次研讨会都能称得上是一个热闹的会议。我们有不少很厉害的辩手来批判所谓的最臭的代码的味道（最臭的臭弹）：
- Corey Haines 的观点： 重复的代码
- 我的观点： Primitive Obsession (总是使用底层的数据结构/原始的数据类型，而使用经过更高层抽象过的数据机构或其它可以n倍的减少复杂性。这并不只针对面向对象的编程。这指的是缺乏在应该进行抽象的数据层面上进行抽象)
- Matt Van Vleet 的观点：单一功能原则
- Venkat Subramaniam 的观点：避免写代码
- Jim Weirich (他并没有出席这次会议) 的观点： 共生性
我们都认为避免写代码（只有在没有其它办法的时候才去写新代码）是最重要的需要让每个开发人员都认识到的问题。大量的重复的代码，劣质的代码（存在于各种项目中）积累到今天已经无法统计了。在很多情况中程序员根本不喜欢去搜寻一下可以利用的程序，他们只知道自己去写。这就是为什么我们要去以代码行数(LoC)来作为评审代码效率和性能的原因。一般来讲，好的程序员的开发速度会比一般的程序员的速度快20倍以上，因为他们对重复利用现有代码的认识完全不在一个层次上。很多人对 “Not Invented Here Syndrome（简单解释为开发团队不喜欢使用不是自己写的程序，缩写为NIHS）“ 这个说法感到困惑。我个人认为NIHS对于我们这个领域里的进步有很重要的意义。NIHS体现在设计和解决方案层面。Joel 写了一篇很有趣的博客，题为 In Defense of Not-Invented-Here Syndrome，大家可以参考看看。
然而，如果当大家都认为项目里我们必须自己写点自己的代码时候，那么我们最应该提防的一件事情是什么呢？SRP 和 Connascence 真的可以帮你实现高内敛的设计。如果程序不是高内敛的，我们应该很容易可以在里面发现重复的代码（至少是概念上的重复），你也会发现只要在设计上选择正确的方式进行抽象提取就能很好的解决这种问题。所以代码重复和Primitive Obsession实际是相互因果的关系。
据我的经验，我要补充一下，我曾看到过有程序并没有多少的重复，但却非常让人难以理解，这是为什么？所以我要提出，“只要是代码进行了较好的抽象，它就会很容易让人理解和易于推理出其功能”。同样，如果你试图去消除重复的代码，在某一程度上，这里并没有字面上的重复，但是这里却存在一个概念上的重复，那么只有对它进行更高一级的抽象就能有效的解决这个问题。因此我的结论是：回顾往日经历， Primitive Obsession 才是针对低质量设计最大的难题，也就是所说的最臭的臭蛋。
原文英文地址： Biggest Stinkers
