Category: 一家之言

谈到写作，大家都公认“文笔”很重要。写出好文章，离不开好的文笔。大家也认为，文笔是种天赋。如果自觉没有这种天赋，也就和写作没什么机缘了。

在过去很长的时间里，我也是这么认为的。上学时每次老师夸奖“文笔好”的同学，我都很羡慕，也惋惜自己沾不上写作的边。然而这些年来根据自己写作、学习的经验和思考，我逐渐发现，文笔对写作确实很重要，但好文章要求的“文笔”，却不等于天赋的“文笔”。

按照传统的理解，“文笔”侧重于对文字、语词自身的优美的感知和运用能力。从小到大我们受到的语文教育中，“好的文笔”大概就是气势的排比、形象的比喻、优美的搭配……，总而言之，就是能让文章“漂亮”起来的手段。所以很多老师会鼓励学生用一个小本子记录“好词好句”，写作文的时候才有资料可用，才能体现好的“文笔”。好的段落之所以被挑出来，也是让大家学习这种“文笔”。目前许多中文写手所擅长的，也正是这个方面，甚至可以说“语感超强”，阅读他们的作品，常常可以被层出不穷的好词好句弄到眼花缭乱。这样漂亮的“文笔”可以通过积累背诵得到，但非原创的“文笔”常常不够新鲜、生动，好的“文笔”多是灵光闪现、语感爆发的结果。大家认为文笔离不开天赋，或许就是这个道理。

但是我们仔细思考就会发现，写作是将作者所想的内容表达出来的过程，所以“文笔”就是将这些内容具象为文字的本事，其实并不稀奇。传统上说的天赋的“文笔”（词句优美），其实不等于文笔的全部——好词好句或许能解决“漂亮”的方面，但表达不是只有“美”的部分，还包括“对”的部分，即规范性的成分。

写作的历史悠久，经过历代作者的贡献和积累，已经形成了相当多的规范性知识。如词语是否准确，句意是否流畅，段落衔接是否自然等等。它们好像刚性的骨架，深埋在文字里，虽然没有“天赋文笔”的美丽光环，却深深影响着作者意思的传达和读者的阅读情绪，保证整篇文字不会误入歧途，不会成为畸形。如果忽略了对这些规范性知识的学习和训练，写作时很难单纯依靠优美的文字“一俊遮百丑”。道理很简单——词句再优美，缺乏了“对”的基础，都不算“好”的写作。

不幸的是，我们总是强调文笔中的天赋部分，太看重“优美”，而忽略了“对”的部分。基础语文教育中很少认真讲到准确用词、严格造句、段落衔接方面的内容，更不要说专门的训练了。在成人写作的世界里，又缺乏足够有分量的批评，即便有 这种文笔方面的建议或讨论，也会被视为“吹毛求疵”、“不上正板”，显得“不入流”。所以即便已经成名的写手，也不愿意时间来锻炼和改善，因为这“不是问题”。结果，天赋的“文笔”再好，华美的盖头之下，总是可见糟糕的质料、粗糙的针线。不少所谓“文笔不错”的文章，读过之后只能留下几缕空洞的感觉，完全经不起推敲。

在词语的准确方面，不少知名写手也常犯错误，用“甚嚣尘上”描述好消息的传播，用“狼奔豕突”形容车流的繁华（用成语没错，但要用对，即便作者不理解原成语的意思，基本的“语感”也应该足够判断出“嚣”、“狼”、“突”不是褒义）；在句意流畅方面，我随手摘录一段：“老白带着我在山林里行走，天色阴暗，草木茂盛，几下就晕头转向了，简直跟不上他的步伐”，因为主语错位，读者要想想才能明白，“晕头转向”的不是“老白”而是“我”，所以应该改为“我跟着老白在山林里行走……”。段落衔接的问题也相当常见，许多作品里都可以读到“石头里蹦出来”的生硬段落，或者毫无征兆的转折表述。限于篇幅，我在这里无法摘录，但我相信仔细阅读的人对这种现象不会陌生。

作为反面的例子，不妨看看美国文学的情况。20世纪30年代以来，美国文学在世界上的影响力迅速增加。其中一个重要的原因，就是美国普遍开展了创意写作的课程，让更多普通人学会了写作，提高了大众的写作水平。翻阅美国创意写作的教材就会发现，它们强调的是“写作是一种工作而不是天赋”，要想写好，应当如此这般遵照规范进行，甚至详细到哪个场合用多少什么性质的词语才合适，都有讲解。写出《浪潮之颠》的吴军先生，也要特别感谢美国的导师对他写作的专门训练——如果“文笔”仅仅与天赋有关，那么遇到有文笔天赋的理科教授几乎是不可能的事情，遇见这样的教授就开了文笔“天眼”的更加不可能。但大家都认为《浪潮之颠》的文笔不错，可见依照规范训练的重要性。有意思的是，中文写作里常见的用词错误、句意混淆之类问题，同等水平的英文作品里确实较少出现，这或许可以从另一个侧面印证写作规范和训练的重要性。

在我看来，对写作水平不满意，而强调“文笔优美”，实在是缘木求鱼。对当前的广大作者来说，写对比写好更重要。如果大部分文章都能遵循写作的规范，都能够写“对”，哪怕词句不那么漂亮，也已经是广大读者的福音了。

Continue reading 电子阅读之我见

大概六年前，我在一家名为“抓虾”的在线RSS阅读网站工作（如果你不清楚RSS阅读网站是什么，可以参考Google Reader）。阅读器都需要显示当前用户的未读数，抓虾的做法是给出精确的数字，明确告诉用户“你还有2456篇文章没读过”，Google Reader则显示为10+、100+等形式，告诉用户“我还有十多篇/一千多篇文章没读过”。初看看来，这只是一种普通的差异，但产品人员提出10+、100+的形式更好，原因我如今记不太清楚了，似乎是说这样给用户的心理压力更小，因为如果数字比较大，用户就不需要知道具体的数值，所以阅读体验更好。虽然程序员都并不认同这种理论，但因为分工不同，最终做开发的大伙还是完成了这个功能。“可想而知”的是，这个功能上线之后并没有带来明显的正面反馈。更好玩的是，过了一周，Google Reader的未读数竟然改成了准确数字！

前几周，我在twitter上说起这个故事，本来只是凑兴当个玩笑，收到的反应却出乎我的意料，因为反馈大都是对产品经理一边倒的负面评价。我又想到自己的一个朋友，他在某家以产品经理文化著名的大公司做开发，谈到理想的工作，他的要求是“找个产品经理少的地方就好了”。这样看来，程序员和产品经理的矛盾是普遍而且深刻的。

Continue reading 做个懂产品的程序员

前些年互联网上有篇叫《降级论》，建议广大IT从业者不要削减了脑袋挤移动互联网等等热门方向，换种思路，在“不起眼”的传统行业中寻找IT技术应用的广阔天地。这篇文章一登出来吸引了大量关注，按照作者的说法，降级论俨然是条通往幸福的康庄大道：

“这些原始而纯粹的行业，正在等待IT精英们的降级，如同蒲公英一般的伞兵，在黑夜里从天而降，长驱直入，用最智慧的产品、最优质的服务拯救这些早就该死的行业，屌丝的生命将会绽放出银色的羽翼，无比丰满，无比性感”

不幸的是，我见到的现象却非常奇怪：许多尚未投身的读者谈起“降级论”却满怀憧憬，真正敢于“降级下凡”并成功的却寥寥无几。仔细想想，无论从逻辑上分析，还是从自身经验来看，“降级”之路都不算坦途。根据我的归纳总结，IT从业者（“精英”这个说法略带刺激性，我觉得“从业者”更合适）走上降级之路，有几大困难是必然要经历的。

Continue reading 漫漫降级路

人和人之间各种错综复杂的关系，归结起来，可以粗略分为两类：强关系，弱关系。典型的强关系有终日厮混的死党，还有无话不说的密友；而典型的弱关系，有远房亲戚，“知名但未谋面”的朋友等等。这么举例，大家都比较容易理解。在现实生活中，可能很难清楚地界定强关系和弱关系的标准。但如果把关系搬到虚拟世界里，或者说在（互联网上的）“社交网络”中，因为方便量化，两者的分别就要明确许多。用我的话说，能留出专属时间且保持比较密切频度联系的关系，都可归类为强关系。除此之外，又不同于“纯粹的陌生人”的关系，都属于弱关系。按照这种分类，QQ好友、MSN联系人，就属于强关系，而论坛版友、微博关注对象等，属于弱关系。我相信，这也符合大部分人的实际情况。

如果我们仔细观察就会发现，上面说的强弱关系是就关系本身而言，但最终体现出来是落实在具体工具上的。一般人与QQ好友、MSN联系人之间的联系，天然就比论坛版友、微博关注对象要密切很多；而且，无论用QQ、MSN来保持相对松散的联系，还是用论坛、微博持续高密度地联系，都会显得很别扭。所以大家会用合适的工具来保持合适的关系。经常看到的例子有，如果在论坛上聊得比较投缘，就加QQ或者MSN好友。再比如，“陌生人交友”应用中的好友往往很少加QQ好友，因为大家不愿意成为相对私密信任的强关系。

Continue reading 强关系，弱关系

前几天在Twitter上有朋友问：ln的参数顺序要怎么记忆比较好，因为总是搞错。这个问题我也遇到过，以前每次都记不住两个参数的先后顺序，最终办法是花了点时间背诵命令模板，每次用到时心里默念就好了：

ln option target linkname

我没想到的是，搞混顺序竟然是个普遍问题，我本来以为哪怕有疑问，背背模板也好了，大家都应该是如此。仔细了解才发现，有疑问的朋友确实背下了OS X中的man，但这份文档写的是：

ln source_file target_file

看起来区别不大，用起来差别不小。因为做链接时，target既可以指“被链接的对象”，又可以指“生成的链接名”，和source_file之后就更容易混淆了。参与讨论的几位推友都认为我背的模板更好用（其实是我的运气更好，背诵时遇到了写得清楚的文档），因为另一个参数名是linkname，意义非常明确，所以哪怕target的意义和OS X中的完全不同，也不影响理解和使用。

Continue reading 闲话命名

托图灵诞生100年的福，去年出版了许多关于图灵的书籍。《图灵的秘密：他的生平、思想及论文解读》是其中的一本，前几周看完了，收获不小。说起来也惭愧，虽然自己学的是计算机专业，也知道图灵这个人，却不清楚他究竟做过什么，印象深一点的只有关于人工智能的“图灵检验”。看过《图灵的秘密》才弄清楚，图灵在计算机发展史上究竟作出了什么贡献，比如可计算性判定，比如通用图灵机，配合书中对他的论文的解读，又了解了他所处的时代和环境，以及他局限和所犯的错误。不过我最高兴的，还是通过阅读填补了自己知识结构中的若干鸿沟：原始的计算机都是专用于“计算”的，后来如何转变为能做任何事情的机器？大千世界的众多信息是怎样一步步进入计算机世界里，被表现和构建出来的？这些问题之前一直困扰着我，也找不到答案，看过这本书算是终于地摸到了答案，这本身就值得高兴；而且，填补断层有利于把所学的知识联接为统一的有机体，以后记忆和运用起来也更自如。

不过合上书本，也有遗憾：如果早能弄清楚这些问题该多好，在计算机科学中这些都应当是相当基本的常识，却需要花费这么多的周折，这么长的时间才弄明白。以前有位读中文的朋友说，老师在课堂上讲，《理想国》这样的书还有是什么好想的，直接买回来啃就对了。每每想起这句话，我都非常感慨：这位老师不一定有特别高水准，但至少在向学生推荐读本这一点上，他还算称职。相比之下，计算机专业在这方面实在差的太远了。一方面许多老师的知识水平不敢恭维，不过如果有好的教材供学生自学，这问题倒不算特别严重，偏偏在国内的计算机教育界既缺乏高水准的原创教材，也缺乏对国外经典教材的认知和推荐的气魄。情况真是再糟也没有了。

Continue reading 从《图灵的秘密》想到的

2011年前我写过《事关“工程师思维”》，在那篇文章里所谈的“工程师思维”，指的是“一种可以把想法实现出来，一步步的变成现实的思维和实践训练”。两年过去了，工作和生活中的许多经历让我认识到，“工程师思维”不仅仅是一种思维和实践的训练，更是从多个方面体现出来的习惯，以下简单说说我的两点理解。

工程师思维的体现之一，是对于工具的执着。工程师不是赤膊上阵的莽夫，要完成自己的任务，必然离不开工具的支持，所以，优秀的工程师，必然从思想上重视工具。
我刚刚接触Linux下的开发时，是在一家当时国内有名的互联网公司。当时自己学了点vi，开始编写php程序。有天，一位同事从旁边走过，他忽然说：你的vim怎么没有颜色呢？然后不由分说，抢过我的键盘噼啪一顿敲，瞬间编辑器就有了格式和颜色（其实就是加上了syntax语法文件）。当时我只是觉得新奇好玩，过了几天，随着程序不断变复杂，才发现开发效率相比之前已经大大提高；后来让我惊奇的是，原来那天帮我弄出颜色来的同事，正是公司的首席科学家；更让我惊奇的是，他负责的项目，基本是不用加班的，而且交付质量都相当出色。
这件事情我印象一直很深，一方面是因为身为首席科学家，愿意“屈尊”为新入门的同事配置工具（后来我才意识到，他所负责的项目之所以都能高质量的准时交付，离不开一个又一个的细节，对工具的执着就是其中之一）；另一方面，我也发现很多“工程师”并不那么在乎工具，更愿意坚守一些原始粗糙的工具（“粗糙”与“简单”不同，精心配置的vim当然不算粗糙的工具），你建议他们去换用新工具时，他们往往说“没事，我习惯了，再说也查不了多少”为理由拒绝（我认为这更多是思维上的懒惰）。更不幸的是，我见过的有这样习惯的人，基本都算不上优秀的工程师。两厢对比，我越发深刻地认为，“工程师思维”的一个重要方面就是对工具的执着，甚至既要对自己的工具精益求精，更容不下团队里其他人使用粗糙的工具。

工程师思维的体现之二，是对于流程的执着。工程不同于艺术，不需要天马行空的自如，工程的完成离不开严谨周密的步骤，只有执著于流程的工程师，才能够各种工程中贯彻严谨周密的步骤，从而减少变数，保证工程顺利完成。
许多开发人员都遇到过这样的情况：经常需要解决各种重复或者类似的问题，但是每次都需要花不少力气翻找之前的资料。我也曾遇到过这样的问题，直到有一天，发现某位同事有一个巨大的“脚本库”：无论我问他什么问题，他都可以迅速找出一个脚本，我只需要修改几个参数，就一定可以解决这个问题。
回头去想，这些脚本描述的就是解决某类问题的流程，它标明了具体的操作和步骤，保证任何人都可以照章解决某类问题，这种看似“与人无关、缺乏灵气”的方案，其实正是“工程思维”的体现，最大限度地减少了工程中的不可控因素。于是，我也逐渐积累自己的流程文档，更重要的是，在解决一个个问题的“个案”中，尝试从“流程”的角度观察和思考：这个问题是怎么解决的？前后分为几步？哪些步骤是和其它问题相通的？时间久了，既积累丰富了自己的流程文档，又强化了自己的思考能力。如果因为某些任务看似简单，就不去思考背后的流程，想凭“巧劲”手动解决，遇到真正复杂的问题，就没有化繁为简、系统解决的能力，如果问题重复出现，每次仍然需要手动处理，速度只能停在某个很低的水平。这样的表现，当然和“工程师”不挨边了。

如今流行的某种说法认为，中国人的理工科培训，造就了许多人的“工程师思维”。听起来，“工程师思维”似乎是某种不好的习惯，只知做事，不会思考；但在我看来，事实全然不是这样：“工程”是一门讲究实践、思考、经验总结的学问，而我国现行体制里教育出来的人，往往只擅长照章执行，根本谈不上“工程师”；无论是谁，想要具备真正的工程师思维，都离不开持续、专门的学习、思考和训练。

今天收到了人民邮电出版社图灵出版公司的快递，是章显洲和我翻译的《程序员的职业素养》（Clean Coder）的样书，前段时间的努力终于见到了结果。说起来，我与这本书很有些机缘。

在Clean Coder之前，Uncle Bob曾写过Clean Code，这同样是一本好书，更凑巧的是，它的中文版（《代码整洁之道》）是我的挚友韩磊翻译的，此其一；2009年，在翻译完两本技术图书之后，因为感觉到翻译实在太累，我打算就此收手，最多做做译稿的审校，未料到Clean Coder审校到一半，自己竟阴差阳错地成了合译者，炒股炒成股东是悲剧，审校审成译者也算离奇，此其二；Clean Coder中的Clean，最后确定为我偏爱的“职业素养”，之前众人曾为这个词大伤脑筋，我曾提议为“拎得清的程序员”，被认为类似方言，不够普遍，最终想到的“职业素养”乃是某天妙手偶得，也非常满意，此其三。

不过，我更在乎的奇妙机缘是，因为由翻译这本书，有了意想不到的发现。

2009年，我已经翻译完《精通正则表达式》和《技术领导之路》，共计一百万字，深感翻译是苦差事，殚精竭虑，冥思苦想，所得（尤其是物质的）却往往非常有限；所以决定不再做翻译这类费力不讨好的事情，最多只帮忙做做审校。

然而“破例”翻译《程序员的职业素养》，本来以为又要暗无天日地苦干一段时间，其实不然。我最后发现，翻译并不全是苦差，而是个相当健康的爱好，而且更深刻感觉，生活应当具有健康的爱好。

所谓爱好，应当是有趣味、能引发兴趣的活动，你必然愿意为它去做一点牺牲。这样看来，“无聊”显然不算一种爱好，因为它没有趣味；无所事事打发时间，显然也不算爱好，因为这只是一种无奈的选择，打发时间并没有什么牺牲；相反，打牌、看电视却可以算一种爱好，因为喜欢打牌、看电视，你必须付出某些代价，比如工作开小差，比如偷懒不做家务。付出这些代价换来的，是兴趣或趣味的满足。

不过，打牌、看电视之类，并不能算健康的爱好。我以为，健康的爱好，不但可以提供持续的趣味，而且在追求趣味的过程中，是能够收获积累与提高的。譬如看电影，若只是一部部走马观花地看过去，多半算不上健康的爱好，但如果能花一些时间去研究和思考，电影看得越多，能看出来的门道就更多，感受也更多，这便可以算是健康的爱好了。同样的道理也适用于摄影——摄影本身可以算所以一种爱好，但不花时间去学习，“镜头后的那个头”永远不变，拍出来的永远是糖水片，其实算不得健康的爱好。

时隔三年，重操旧业来做翻译，我发现它天然就是健康的爱好：翻译本身是一种锻炼脑力的活动，并没有墨守不变的规矩，经常需要反复推敲琢磨，完成之后自然乐在其中；而且，随着翻译经验的增多，逐渐可以领略到不同语言之间的奇妙联系，会恍然大悟“噢，原来这个意思，用英语该这么表达，而汉语该那么表达”，之后阅读各种文本时又有了更深切的感受。

更重要的是，无论工作有多忙，生活有多么不顺心，晚间往电脑前一坐，气定神闲，专心致志地做上半小时到一小时，就可以忘记各种烦恼，看看自己终于又做了一点有意义的事情，心情也好了很多。这样看来，拥有了健康的爱好，就可以把生活分成几部分，从某一部分（健康的爱好）中提炼出乐观的心态，去面对不顺心的部分。如果人人都能找到或者培养出自己的健康的爱好，生活中的长吁短叹，应该是会大大减少的。

回想起来，我对翻译一直是有兴趣的，但之前为什么会把它当成苦差事，而很少体验“乐在其中”呢？我仔细思考这个问题，相比之前翻译《精通正则表达式》和《技术领导之路》时的起伏心情、痛苦煎熬，现在翻译《程序员的职业素养》时，可以更好地把握翻译的节奏，这便是最大的区别所在。

翻译《程序员的职业素养》时，我先评估了自己平均状态的翻译速度，再估算了每天大概可以抽出多少时间来翻译，与编辑确认计划之后，剩下的就是按部就班，每天“不以物喜、不以己悲”地执行计划，并为看到当天的工作结果而欣慰；最终，可以按时按质交出自己的译稿。翻译完成之后，我猛然发现，自己翻译这本书时，确定合理计划并持续执行的做法，与书里提到的职业素养，竟然有许多重合的地方，真是“万变不离其宗”，要做好做成一些事情，总有些共通的规律。

这件事也给了我足够的信心：随着岁数的增长，我们不再有年轻时天马行空的乐观想象，认为自己可以这样那样生活，可以不顾现实、不计成本地做这样那样的事情，而是变得现实起来；但是另一方面，没有期望、不值得争取的生活，其实是不值得过的。把握节奏感，就是清楚自己的节奏，可以预估出出来，按照可行的速度，到某个时候，自己大概能到达怎样的状态或程度。然后要做的，便是依靠毅力，持之以恒地坚持推进，直到达成自己设定的目标。

前几天在深圳，与一个毕业不久的小伙子谈起，没有目标的生活是不值得过的。以我的经验，如果你想象的生活里有健康的爱好，有节奏感的准确把握，无论具体形态如何，只要去做了，都可以算是幸福的生活。

按：前段时间与章显洲共同参与了图灵出版公司Clean Coder中文版的翻译，这是我的译者序。

我在招聘时常问的一个问题是：在你过去的工作中，遭遇过哪些印象深刻的困难，最后是怎么解决的？依我的经验，简历写得再漂亮的人，如果这个问题答不好，大都可以直接忽略。为什么会有这种结论？因为我们需要招聘的不是“经历丰富”的人，而是“有职业素养的人”。你遇到的问题可能很容易也可能很难，但我看重的并不是问题的难度，而是解决问题的方式、步骤，以及反思的深度。拿恢复误删数据来说，这可能算非常简单的任务，我更感兴趣的是怎样分析问题，找了怎样的资料，采取了怎样的步骤，此后做了哪些措施来避免这种错误再次出现。在我看来，相比问题本身的难度，解决问题的方式和步骤，以及反思的深度，都体现出一个人的职业素养。

是的，上面我两次提到了“职业素养“。相比起“专业主义”、“职业化”等说法，我更喜欢用它来翻译Professionalism，因为素养强调的并不是天赋的神秘，也不是技艺的高深，而是持续积淀的结晶：一方面，它体现了能力和素质，另一方面，它又强调了持续的积累和养成。甚为职业开发人员，基本技能不够熟练，当然谈不上职业素养；但是能迅速地编写代码，却不关心代码背后的意义，不能迅速判断、解决程序运行中的各种问题，自信满满地为自己交付的程序承担责任，同样是与职业素养绝缘的——许多所谓的”高手“，其实正是缺乏职业素养的典型。

当然，这只是我对于“职业素养”的理解。由个体经验总结的“职业素养”，多有一鳞半爪的嫌疑，所以即便你觉得上面说的有道理，难免感觉只见树木，不见森林。其实真正的”职业素养“绝不限于上述几方面，而是要广阔得多，深刻得多。要想一窥技术人员“职业素养”的全貌，已经有很多现成的资料可以参考，Bob大叔的Clean Coder就是其中的佼佼者。

作为一本技术类书籍，Clean Coder中有相当的内容，是介绍纯技艺的方面，比如测试驱动开发等等，自认已经算“职业开发人员”的人，大概对此并不感冒（不过，我仍然建议你认真看看）。但其它的内容，绝对值得你感冒，比如：什么情况下应该对业务部门说“是”，说“是”意味着什么。如果你没有想过这些问题，或者没有明确的答案，不妨看看Bob大叔是怎么说的：

（说“是”时）你对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限(do with a clean end time)。那不是指别人，而是说的自己。你谈的是自己会去(will)做的一项行动(action)，而且，你不是“可能(possibly)”去做，或是“可能做到(might get to it)”，而是“会(will)”做到。

就我所见，技术人员往往太容易说”是“，往往在没有明确目标和期限的情况下，就草率给出了确认的答复，而且并不将其视为自己的一种承诺。屡见不鲜的项目延期，有相当原因就是在这种不负责任的情况下说“是”所致。但是我们想想，似乎没有哪一个正经行业，会把不能完成任务的人视为“有职业素养的人”，软件行业也不能例外。

如果你觉得自己已经足够负责，懂得“是”背后所蕴含的意义和责任，也不过如此，我们不妨更进一步，看看关于说“否”。在第2章，Bob大叔介绍了两个项目搞砸的经过，他并没有像常见的所谓专家那样故作聪明地指出实施过程中出现了哪些问题，导致了失败，而是一针见血地指出：这两个项目之所以会搞砸，因为开发人员没有坚决抵制各种不专业的需求（比如一些无关紧要但成本巨大的需求），抵制各种不专业的行为（比如为了赶工期而降低对程序质量的要求），最终只好喝下自己酿出的苦酒。对此，Bob大叔总结道：

有时候，获取正确决策的唯一途径，便是勇敢无畏地说出“不”字……我们要明白，委屈专业原则以求全，并非问题的解决之道。舍弃这些原则，只会制造出更多的麻烦……

对我来说，这真是振聋发聩的号角。而且，这种思维，这种视角，其实是许多技术人员所不屑或者不愿面对的——最初我也这么认为，但尝试在工作中主动说了几次“不”之后，我逐渐发现：花三分的力气去抵制无理的需求，可以节省十分甚至二十分的开发时间；相反，自欺欺人地说服自己凑合接受了无理需求，往往会非常被动乃至无法脱身，到最后，项目就落得著名的IBM
OS/360操作系统的下场，越挣扎，巨兽就越深地陷入泥潭。

要学习这样的道理，当然也可以参加培训班，听取授课或者阅读讲义，但那未免太显正经而缺乏亲和力。Bob大叔的特别之处在于，他总是可以通过浅显易懂的故事，清晰而敏锐地揭示了问题的核心所在。其中许多故事正是他自己亲身经历的，阅读过程中常会会心一笑，因为遇到了开发人员都懂的妙趣，比如费尽全力也是徒劳，无法让其他人理解“编辑程序的程序”；笑过之后，又会认识到许多道理——无法让其他人理解“编辑程序的程序”并不是真正的原因，真正的原因是：“客户……对功能的设想，其实经不起电脑前真刀真枪的考验……问题在于，东西画在纸上与真正做出来，是不一样的。业务方看到真正的运行情况时就会意识到，自己想要的根本不是这样。一看到已经满足的需求，关于到底要什么，他们就会冒出更好的想法——通常并不是他们当时看到的样子……真正的解决办法，是约定共同认可的验收测试标准，并在开发过程中保持沟通”。至少就我的经验，这一点是说的非常之对的。我曾经尝试在与业务部门确定目标原型之后，要求对方指派一个负责人，在IT部坐班，负责协商、跟进整个开发流程，确认每一点修改，这样既保证最终结果符合业务部门的需求，又提高了开发人员的工作效率，综合来看，成效相当可观。

类似的例子还有很多，在阅读这本书时，我经常会惋惜：如果早一点读到这本书，或许我之前就不会犯这样那样的错误，就能更早更好地积累自己的职业素养，另一方面，能有妙趣横生的书讲述看似枯燥的“职业素养”，对读者来说，又是一种幸运。德国作家托玛斯·曼曾经津津乐道于“斜躺在沙发上整天阅读叔本华”的美妙感觉，那是因为叔本华的文笔优美、流畅，可以把哲学变为惬意的享受。作为同时读过叔本华和Bob大叔的人，我想说，斜躺在沙发上整天阅读Clean Coder，认识和了解开发人员的职业素养，同样是相当惬意的享受。