软件开发沉思录--ThoughtWorks文集(china-pub首发)（来自软件界思想领袖们的经验心得）。看试读的两章：第五章充斥着狗屎，第十三章却瑕不掩瑜。
第五章的一个问题在于讨论的大多数问题都是虚的：比如在Java与Ruby的比较中提到的落单方法。这样的话题根本没有真理可言，而作者却毫无顾忌地认为它（没错，“它”）的观点就是对的。但这还不是伤害性的；下面就这个例子说一下狗屎从何而来。
仔细看Java版的isBlank函数，其中对null的判断，对length的判断，对每个元素（这里是字符）是否是某一特殊形态（在这里是空格）的判断；实际上isBlank这个函数的逻辑，完全可以看作是某通用逻辑的特化版本，所以这个函数按照这个视角，则不应该出现在String身上（尤其考虑前半部分逻辑）。
虽然他给出的Java版本并未体现某种通用性（这是他自己的问题），这并不成为Ruby版本中那种所谓“一切皆对象”方式“更好”的理由【1】。这类似于someList.length还是len(someList)的争辩；一个人稍微有一点点泛型经验或者真正明白什么叫做抽象（丫的居然好意思在后面讲函数式时提到数学），就不会像作者那般轻易下结论。
（要强调的是，本帖不是在继续到底哪种方式更正确、更“真谛”。如果谁要是认为someList.length就是唯一正确的抽象方式，咱们改天再做探讨。）
我在这里反对的不是面向对象或者任何什么具体的东西。每一种可以流行很久的方法必然有其特色、适用场景和一套无论几流的哲学。而且，我也坚决捍卫每个人说话的权利。
但是鉴于某些人对自己公司和自己员工的包装，我严重的鄙视为了自我肯定（实质是一种麻醉）、挣钱（有名才有利）而信口开河的行为。因为他是在装模作样的在公众场合瞎忽悠。一个存疑的讨论不应该被当作确切的知识通过某些人的口吻以不恰当的方式灌输给嗷嗷待哺照单全收的初学者，仅仅因为这些人认为它对。【2】
本身就这章的多语言编程这个话题并没有什么对错；但是，站在自认为可以指导他人的角度，就某一个话题，重复着一些自己根本不真正懂行的话（因为这是自己仅存的“知识”了），并将这些似是而非的观点广而告之，这就和排污器官没有什么区别。
让我们看看这章开头：其作者在某公司的职位叫做“意见领袖”（再看看china-pub给的这标题，WTF），我看不妨把这个职位叫做“狗屁眼”来的恰当。然后引用了一句某二的彻头彻尾的胡话“X年之后所有人都用SmallTalk编程无论他们把它叫什么”云云。这些卖狗皮膏药的真应该尝尝城管的滋味。
第十三章却做到了脚踏实地、言之有物，并进行了真正有用的讨论。在测试的不可避免（这里不展开讨论这个话题）这个前提下，此文在不长的篇幅中全面完整的介绍了一种测试体系，并点到了作者认为读者应该知道的内容（相比之下第一篇文章却偏离主旨的狂放屁）。虽然我个人不赞成（某些具体的）测试对正确性能有很大的保障，但仍然学习了很多；另一方面，作者也没有就“谁更对”这种问题进行宣示。
同样一个包装下、同一个公司不同的作者，差异如此之大，那么在我们的学习过程中，就要注意去芜存菁了。当一个人、一本书、一套观点被拿到我们面前时，作为弱势群体，很容易被很多不相干的字眼加上先入为主的枷锁，而就我个人这些年犯过的蠢事来看，这些枷锁摆脱起来却相对困难。
现在的我是怎么做的？凡是过分推销的，都把它们放上了黑名单；那些没有开发过“真正难”产品的，别想上我的白名单。至于什么是真正难的这就要靠自己的判断了。但凡我们睁开眼睛，不要因为生存环境所限一辈子只能写某种程序，就倾向于肯定同样写这种程序但地位比我们高的家伙，我们就会知道。
注意一个误区：由于这个地位更高的家伙和自己从事的是相同领域，于是既然我也是干这个领域的，那么他的经验比另一个其它领域的家伙更值得参考，即便那个领域需要更高的技巧。这种想法是有害的在于，一个认知水平较低的人在任何领域都更可能采取错误的认识；而在一个较容易的领域，由于错误的认识危害性不高，可能并未被识别【3】。
在这里再举个我自己的例子：Michael Feathers。他是我一个转折点；对各种包装出来的技术明星的不满在他身上爆发了。不但《修改代码的艺术》【4】让他荣幸地上了鄙人的黑名单，而且我也意识到建立评价体系的是必须的了；这个社会逼得我们不得不靠自己。
一个方法是在对某人、某书、某方法的第一阵狂热过后（这有时不可避免，而且在一定程度上增加学习效率）通过强行降温快速的给出一个真实的评价，并且带着明显的怀疑态度去审视它：鉴于学习者在学习目标上的水平，如果不带有找碴的态度就很难对似是而非的东西免疫。
这温如何降？真正好的作者会全面、公正的顾及正反两个方面，但对于很多“大师”我们就必须自己找出那些负面要素。
一个遗憾是，无论寻找负面要素这个具体措施、还是建立评价体系的能力，在不同的人身上确实存在巨大差别【5】；限于我们每个人的具体情况，也很难短时间提高。广泛（但不见得是大规模）阅读是一个差强人意【6】的办法，比如SICP上关于类型系统的一段短短的注释就帮助我对面向对象类型系统建立起自己的看法（并不与SICP相同）起了一个头。
但值得庆幸的是，通过一次次的求实过程，我们的眼光就会越来越高，眼界也会越来越宽。我相信每个人都可以在职业生涯的前半段提高到适当的水平。
在对自己的评价体系存疑时，白名单就是一个相当重要的拐棍了；就我的经验，白名单上作者误导人的时候确实很少。在我刚开始听说Linus炮轰面向对象时，我已经开始了反思但还不够；那时的我仅仅持一个保留态度。但自从那以后，我越来越多的体会到了他的言论背后的内容；逐渐，我就学会了如何看待比如现在似乎又有点过气的DDD之类东西的方法。
有时候做出了一个判断以后，我们甚至能通过各种各样的形式得到远超过这一判断的好处。
比如，自从我认定Feathers“水平不高”，就顺便降低了Bob大叔的评分；甚至有一个更无厘头的：我降低了Richard Gabriel及其著名作品的评分，就因为让我不屑的Feathers推荐了此文！当我带着新的评分（原来的评分是被灌输的）重新回顾我曾经喜欢的东西，虽然不太可能全盘否定，我仍然找了新的收获。
这是第一条防线；但这不意味着我们要被反感的情绪或者谨慎所左右：那些真正对的道理，即便从一个“狗屁眼”里拉出来，我们也应该接受。 只是我们要学着去判断它们。
注1：即便采用纯粹的面向对象观点，这个作者的思路也不是最佳的：但这在原文中被Ruby的一些细节给掩盖了。假设使用一个具有Ruby扩展方式的Java而采用他的逻辑划分，我们就会发现对String的扩展使得应该属于更基础类别的共性变成了特性。
注2：营造权威氛围、单方向发布信息，这和社区里有很大区别。社区发布的特点是平等、双向甚至多向；所以无论作者的视野如何，有益的可能性较大。但这并不是说社区中完全不存在不健康的情况（尤其是对于初学者来说）。
注3：有时候这说明在这些地方过多关注类似的“认识”是没有太大价值的事情；我的经验是，在这些地方从业务本身的特性入手可以掌握更多的东西甚至创造更多的价值。另一方面，在某方面认识的局限性很可能就来自于领域是否真的需要这方面认识。
注4：不是说这本书一无是处，但是按我个人观点，有价值的地方还不如他的偏见和错误观念来得多；这在我过去的帖子中似乎提到过一部分。但你不必听我说什么，每个人都应该试着自己判断。
注5：所以我说要建立你自己的评价体系；不要在意比如我这样的人对某人某事某物的评价。我完全不能排除我是一个菜鸟加2B、且拥有狭隘的偏见的可能性。
注6：之所以这么说是因为从社区角度来看倡导这个方式未必特别有效：一方面是因为大多数人不愿意或者没条件这么做；另一方面，阅读太广的另一问题是，鉴于信息劣势我们有很大概率被不同的喷子洗脑，这就可能造成我们心里一波一波的长不同品种的草，要结束这种状况需要很久的时间。