来自石器时代的困惑

本文是Uncle Bob对软件行业由来已久的三个颇具争议的问题的回应。其中有小部分与其它一些篇章太有相关性，不易阅读，译者未将其纳入本文之中。有兴趣的朋友可以参考Uncle Bob原文。

TDD

这个世上还有人还觉得TDD会导致开发速度减慢的话，就好像是活在石器时代的人一样。对不起，不过这可是事实。TDD不会令你变慢，它只会使你加快。

好吧， TDD 可不是我的信仰，它只是我的准则之一。就像会计师的复式簿记技术，或是手术台上的无菌操作。专业人士采纳这些准则是因为他们明白深层的原因，并且在运用这些的过程中也直接获益。

我本人就经历了TDD给我的工作所带来的极大效用，而且也看到它在别人身上的果效。我自身经历也 看到过TDD帮助程序员构想他们的设计;我自身经历也看到过它对各种方案的描述方式；我自身经历也看到过测试所带来的解耦；我自身经历也看到过TDD人修改、清理他们代码时候的有恃无恐。

客观的说，我不觉得TDD总是合适的。有些情形下我也会打破规则在测试之前先写代码。我会把这些情形写在另篇blog里。不过，相比之下这种情况很少。一般来说，对我对大家TDD都是让你更快、更好、更确信的方法。

总而言之是清晰的。TDD是种专业化的准则；TDD实际奏效；TDD让你更快；TDD不会过时。那些从没试过TDD的人，却声称TDD会减慢他们的速度，纯属有意忽视。我不在意你的名字是Don Knuth、Jamie Zawinski、Peter Seibel还是Peter Pan。实际的尝试尝试吧，然后你才有评判的权利。

让我换个方式。我现在直接针对那些声称 TDD 会令他们减慢的人，你真的是这么优秀的开发人员甚至于都不用从头到尾检查所写的代码吗？如果让你充分发挥才能，比起可执行的测试来说，你还能想出别的更好的办法来检查你的代码吗？比起测试优先来说，你能找到一个更好的方法来保证你一定会写出测试代码吗？

如果可以的话，我是愿闻其详。不过，不要告诉我你只是写了一点儿单元测试。别告诉我说你是人工检查代码的。别告诉我说你是做设计的,所以不用编写测试代码。那些都是石器时代的观念了。我知道，我也曾经经历过那个遥远的年代。

信奉设计模式

Tim Bray说过：

经验告诉我没有比信奉设计模式更能为大型软件项目带来灾难的了。

他当然是对的。信奉设计模式是一只危害团队的害群之马，而且会扼杀稚嫩的项目于摇篮之中。让我们先搞清楚这信奉的到底是什么。信奉设计模式就是秉着认为使用设计模式总是好的的满腔热情。

是这样的，这些设计模式不好，也不坏。它们就是它们。设定好某种特定的软件设计情形下，可能会有某个模式适合而且有益。某些模式可能会有害。很可能现在为止所编目的众多设计模式中没有一个是足够贴切以至于你可以合上书本，然后问题就迎刃而解了。

也有另一种认同--不要用设计模式。你不去使用模式。模式就是僵化的。如果某种模式恰好解决当下问题，那肯定会非常容易看出来。没错，一般来说，没完成代码你是不会认出这个模式来的。你回头看了看代码，然后认出来：“噢，这是个装饰模式！（Decorator）”

我是说设计模式无用吗？

绝不！我希望你们都读一读设计模式的相关书籍。我希望你们从里到外的理解这些模式。如果我点到“访问者(Visitor)”，我希望你能够不假思索的在白板上划出此种模式的所有不同形式。我期待你能正确的理解其中的名词和角色。我期待你理解模式。

不过我不想让你们使用模式，不想让你们相信模式，不想你把模式当成是种信仰。我期待当它们出现的时候你们能够认出它们来，而且在代码中做出规范化标示来，这样其他人也能认出它们。

设计模式有巨大的果效。他们有称谓。读代码的时候你就会发现“组合(Composite)”，如果作者也是按“组合”模式的规则来安排代码的名词和角色的话，你马上就能明白这部分代码的功能。非常强大！

线程同步最小化

头一篇Duct Tape的blog中我说了这样的话：

我发现自己很烦感Joel的观点。他说大多数程序员都不够聪明，他们用不来泛型、设计模式、多线程、COM、等等。我不认为是这样的。我觉得程序员不够聪明去使用这些工具很可能是因为他们在程序员学习期学的不够聪明。

Tim回应说：

...多线程是问题的一部分，但不是解决方案的一部分。基本上没有应用程序开发人员能很好的理解线程，以至于可以避免出现死锁、争用，还有发指的曾出不穷的bug。而COM则是我职业生涯惨遭的最滥的一坨垃圾之一。

线程同步真的是问题的一部分吗？是的！同步确实是问题的一大部分。没错，同步的第一准则是：不要。第二准则是：真的，不要。

问题是有时候你没有选择。这些情况下，你毫无疑问的必须要用同步，你应该从里到外的搞清楚它。

我完完全全的拒绝认同忽视是最佳的防护。我拒绝认同缺少技能会变成个优势。所以我希望你们明白线程同步。我希望我一喊出“哲学家就餐问题”你就能跑到白板上写出所有不同的解决方案。如果我大叫“死锁”，我希望你马上指出原因以及解决办法。

是这样的。如果你希望避免使用什么，先彻头彻尾的理解它吧。

（原文链接网址： http://blog.objectmentor.com/articles/2009/10/06/echoes-from-the-stone-age ; Robert C. Martin 的英文 blog 网址： http://www.butunclebob.com/ArticleS.UncleBob ）

本文作者Robert C. Martin

Robert C. Martin 是Object Mentor 公司总裁，面向对象设计、模式、UML 、敏捷方法学和极限编程领域内的资深顾问。他不仅是Jolt 获奖图书《敏捷软件开发：原则、模式与实践》（中文版）（《敏捷软件开发》（英文影印版））的作者，还是畅销书Designing Object-Oriented C++ Applications Using the Booch Method 的作者。Martin 是Pattern Languages of Program Design 3 和More C++ Gems 的主编，并与James Newkirk 合著了XP in Practice 。他是国际程序员大会上著名的发言人，并在C++ Report 杂志担任过4 年的编辑。