|
索然无味、毫无观点的书永远引不起人们的阅读兴趣。放心，《代码之道》绝对不是！
形式上，本书中的每一篇文章都通过讲故事等方式提出问题，然后分析问题根源，最后给出改善建议。其中，问题的提出往往极具戏剧效果（作者也坦承“为了达到效果，我又一次夸大了问题”），这样一来，凸显了问题的巨大负面影响，且使阅读过程变得有趣。于是，当捧书在手时，产生欲罢不能的感觉，也就并不奇怪了。
¨ 不必说“我认识一些架构师，他们的生活都是失控的”、“回到现实世界来吧，到别的经理手下干活也未必解决问题”这些亦庄亦谐的话点到了人的痛处——现实就是这样的！
¨ 也不必说“你总是在伤害你爱的人”、“了解并接受你所选择的生活方式”这些富有哲理的话让人顿生错觉——本书的上架建议真的是“软件工程”？
¨ 单是“管理层不切实际”、“如今，大家都在跨部门合作上空口说白话”这些你想说又不敢说的话就足以“抓”住你——此书我得好好读读！
定位上，本书不仅是实用建议录，也是深入思考集。书的字里行间，透着作者的良苦用心：不仅“推”给你体现其多年经验精华的实用建议、医“病”良方，更要“拉”你就一线开发中的关键问题进行深入思考、对比分析。这是十分值得赞赏的。即使在我并不认同作者阐述的某个观点之时，我对作者“引发思考”良苦用心的赞赏也未减一分。
内容上，都是和一线的“软件工程师和工程经理”息息相关的话题。首先，是软件开发流程。第1章，谈了项目管理方面的经验。第2章，核心观点是“敏捷，但应理性”。第3章的真正含义不是“停止写规范书”，而是“为了提高协作效率，建议采用非正式文档”。第4章，阐述开发者和测试等其他角色之间的关系。第5章谈质量，质量＝业务上有价值＋工程上无Bug。第6章讲前期设计。……是的，过程管理、项目管理、沟通管理、角色设置、质量管理、前期设计，这些正是软件开发流程关心的。
除此之外，本书有30%的内容覆盖一线开发者和经理成长的话题。例如，我很喜欢第9章。作者为经理们提供了实用建议：如何识才、如何面试、如何帮助平庸员工、如何避免团队“内斗”……。很中肯的良方。
有趣的是，这本书的很大一部分我是在外出讲课的火车上读的，而读此书的感觉恰似坐在晃动的火车上——它不容你的大脑懈怠，因为让你“为之一振”的观点会以极高的频率不断“跳”出来，冲击力十足。
¨ “有没有一种方法在大产品和小团队之间的缺口上架起一座桥梁呢？答案是肯定的，有！那就是架构。架构最重要的一点，就是它能把难以处理的大问题分解成便于管理的小问题。”非常到位的总结。我在架构培训中也常讲：架构要设计到什么程度呢？第一要支持并行的详细设计，第二可根据团队和项目情况灵活调整，第三业务层和通用机制应更深入设计。
¨ “工程的本质就是要真实地知道，而不是靠猜测。”言简意赅，却切中肯綮。
¨ 别的公司，团队里有交互设计师、文档专员、过程经理等角色，你的公司要怎么做的？“如果那是一款很熟悉的产品，目标也很明确，那么你可能不需要很多的专员。如果那是一款不常见的产品，目标也很模糊（至少对于工程师来说是这样），那么你需要较多的专员。”这就是《代码之道》给出的回答。
¨ ……
经验，对软件从业者的重要性，怎么强调都不过分。而在本书中，作者无私地分享了他过去在软件行业6个不同的公司、28年的职业生涯中提炼出来的经验。相信大家都能从中找到自己需要的。
| 
转播
