《构建之法》书评

构建之法——一本不可多得的软件工程教材或辅助参考书

从阅读《移山之道》开始，我就热情关注本书作者邹欣老师，包括他的博客和微博，并在教学会议或其它场合相互交流《软件工程》各自的教学经验。我在《软件工程》教学工程中，也极力向学生推荐邹老师在博客园的系列博客《现代软件工程讲义》，甚至针对一些精彩内容和学生一起讨论、共同学习。如今，邹老师在《现代软件工程讲义》系列博文基础上进行整理加工、补充完善，形成了本书——《构建之法》，这是软件工程教学的一大幸事！ 本书在结构上突破传统软件工程教材的框架，不是按软开发周期（概论、需求、设计、编程、测试、维护等）来叙述，而是先从软件开发个人技能开始，逐步进入两人结对编程、代码互为评审直至团队开发模式之中，更容易让学生感觉软件工作具有实实在在的内涵，教师能够由浅入深开展教学实验活动，也符合作者提倡的“做中学”的教学理念。让我更欣赏的是本书开头“致任课老师和助教的建议”，不仅对内容安排很到位，而且详细讨论了师生关系和极具价值的八条教学建议。本书简洁性、实用性很突出，摒弃空洞的理论讲解，没有无关紧要的文字，而是在清楚交待完概念之后，撅起袖子就干，手把手辅导学生如何完成软件开发工作。本书内容精炼，文字幽默、轻松，印象最深的是： 1) 设定不同人物角色或用户角色（如大牛、小飞、阿超、芸芸等），结合所讨论的研发场景（如日常管理、持续集成、代码评审等），让这些人物活起来，如临其境，感受到真实的研发环境。通过大量人物对话形式来展现不同角色的冲突、暴露问题的细节，从而更好指导学生如何处理这些问题，处理的方法也可能通过对话表现出来。 2) 用一些生活中的事情（如系鞋带）来点化软件工作中抽象的工作（如写需求规格说明书），帮助读者理解所讨论的内容。 3) 案例丰富，对实践环境描述很细，如按小时（时间段）来介绍具体开发流程。而且，提供了足够的练习，营造了一个良好的教与学环境，能够极大地提高学生学习软件工程的兴趣，从而有效改善软件工程教学效果。 本书也存在一些小的问题，如： 1) “软件设计”内容偏少，代码覆盖率测试不够全面，没有谈到分支、条件、MCDC等； 2) 有些术语不符合业界习惯，如黑箱、白箱（虽然作者说明通过搜索引擎，认为“黑箱、白箱”比“黑盒、白盒”提法多）、效能测试（习惯称：性能测试）；ad hoc test 和 exploratory test 混淆起来。 3) 第9章 项目经理、第12章 用户体验 在本书结构中感觉不是特别合理和自然。 4) 技术文档，最好把示例代码写好，还把单元测试写好估计比较困难；典型用户还需要了解“收入”，感觉涉及个人隐私，哈哈。 这些问题（可能不是问题）的存在，并不影响全书的质量。

创新的时机——学习《构建之法》

昨晚（3/12）给团队做了一个分享，叫《创新的迷思》。题目不是我起的，连PPT也不是我写的，是周筠老师发给我的邹欣老师的讲稿。要是换作以前（一个月之前），我是绝对不这么做的，我会添油加醋一些自己的东西，或者从自己的角度去讲。要是换作以前的以前（五六年之前），我连这样的分享都不会做，我会觉得这不是我的东西，没有成就感。当时是OReilly CEO的一句话敲醒了我，他说我们不是在卖书，我们是在传播创新者的思想，这让我认识到传播本身也是有价值的。关于创新的问题，困扰了我很久，直到年前看到邹欣老师的博客文章[1]才敲醒了我，我要把一些认识传播给团队。言归正传，昨晚讲了2个多小时，72页的PPT，应该分成两次比较合适。内容太丰富了，我这里不重复了，有兴趣的可以直接看邹欣老师的博客文章，或者买一本《构建之法》，在这本书里有专门的一章，比博客文章要系统和完善的多。我这里只分享其中的一个点，就是创新的时机。其中有个G-number的小游戏：每个成员写下名字和一个(0, 100)开区间的有理数。最接近G点者获胜，最远者输。G点的计算方法：G = 0.618 * average (all numbers)。共有20个人参加了游戏（不包括我），我给大家两分钟的时间，对于结果会是多少，我心里是没谱的。你现在心里猜一个数字（记住不要更改）。你可能会想，大家随机报的话，平均数会是50，50 * 0.618 = 31，那么我选31低一点。但其他人也不是傻子，那大家都选31附近的数的话，我得选31 * 0.618 = 19。那么还得继续往下迭代，我就干脆选0.0001好了！0.0001是正确答案吗？我公布昨晚我们游戏的结果：G点值是19.28，一位出了21的获胜，一位出了70的输。邹欣老师在书上还做了总结，第一次游戏获胜数字一般离17不远，也就是平均进行了两次迭代。在我公布题目后，就有同学冒出来说接近0，被我制止了呼喊。如果大家脑子转的都足够快，可能最后真的接近0。但某些想的快的同学，并不能决定整个团体的思考阶段。即使写了0.00001，也不能赢得比赛。在创新的道路上，需要的是领先一步，且只领先一步。我在大三的时候（2003年），上一门人机交互课程。老师剖析苹果公司的Newton产品的例子，就是苹果的产品总是领先市场两步，以至于失败。但从我的分析来看，从2001年苹果发布iPod之后，就懂得只领先一步的道理了，不管是iPhone、iPad，还是刚发布的Apple Watch。（请在百度搜索Apple Newton）为什么领先两步不行，我们看下面一张图：（请在百度搜索跨越鸿沟）这张图来自于《跨越鸿沟》，描述的是大众对新技术接受的曲线，曲线的面积大致对应人数。大众平均值再往前一步就是早期采用者区间，这里存在一个鸿沟。推出的太早，就跨越不了这个鸿沟。再换一种角度，Gartner给出的技术成熟度曲线（纵轴是大众对新技术的期望值）：（请在百度搜索技术成熟度曲线）可以看到期望值随着时间会出现很大的变化，先后经过技术触发期、期望膨胀期、迷茫期、低调发展期、主流发展期。我们使用的所谓新产品（如iPhone），一般是渡过迷茫期的二代产品，第一代的也许都没等到这一天（如Nokia N70）。以下是2014年的技术成熟度曲线：（请在百度搜索 2014技术成熟度曲线）我所从事的Big Data，还远没过时，处在迷茫期。一位组员听了报告后的感想：听完了，发点感悟：内容很丰富，很多例子听起来也很有趣。前半段听的比较仔细，后面太饿了，注意力没有太集中。总体上的感觉是以前理解的创新总是很高大上，很突出的东西，虽然很向往，但是总感觉离自己很遥远。已至于别人提出了可能比较创新的idea，自己也可能是那个泼冷水的人。现在觉得创新体现在我们身边更多是一种微创新，创新也可以是一种从量变到质变的过程，我们做的很多工作从一个点来看是也许单调枯燥的，但从长远来看可能也在为整个互联网的创新贡献着些许力量吧(^_^)我算没白讲。[1] IT行业的创新 - 创新的迷思 http://www.cnblogs.com/xinz/archive/2011/07/09/2102052.html

一本集软件开发实战与软件工程教学的多年经验双剑合璧的精华之作

邹老师的课程资料我在备课中已多次研习参考，内容大多都已熟识，可拿到书稿读来仍有一气呵成盎然生趣之感。毫无疑问这是一本集软件开发实战与软件工程教学的多年经验双剑合璧的精华之作，可以预期这本书将在教材市场和畅销书市场获得双丰收，甚至会在一定程度上促进国内业界软件工程素养的提高。软件工程来源于软件开发实践又应用于软件开发实战，而将软件工程思想的理解内化为软件工程师的职业习惯是软件工程教学的核心目标，《构建之法》的实验设计恰恰非常有助于这一内化过程，个人项目、两人项目和团队项目由易到难循序渐进不断总结，我在教学中借鉴这一思路，从学生较为熟悉的编程训练入手，以范例演示基本编码规范、 No Design时的代码、经过基本Modularity (also called separation of concerns)设计的代码、writing code to make it reusable on future projects以及一些特殊的接口设计如callback函数和函数的可重入性（reentrant）或线程安全等较深入的设计问题；并在演示代码基础上进一步引入实际可用的测试代码并切入测试技术基本理论和方法。从编码实践中理解软件工程思想就会跳出纸上谈兵的政治课之感。重实践可以形成对软件工程直观感性的认识，并逐渐由直观感性的动手编码过渡到更高层抽象的设计，如OO的封装、多态和继承，高内聚低藕合、UML等。然后再来理解软件生命周期、软件项目任务切分工作量评估、项目计划、项目管理、进度跟踪等涉及软件工程项目全局性的概念方法。这些做法很多思想和具体资料都来源于邹老师的课程资料，即《构建之法》一书。

《构建之法----现代软件工程》书评----软件工程学习新方法

有幸选择来到中科大软件学院，有幸学到软件工程这门课程，有幸读到《构建之法》这个本，在读这本书之前，在网上也看了很多关于这本书的报导以及介绍，评价不错，再加上软件工程老师的推荐，所以就买了这本书读了读。开始读这本书，最大的感受的感受就是软件工程原来是可以这么学的，以前学习软件工程的课程的时候，总是感觉这门课程及其枯燥无味，总是在说太多的理论，很少 会涉及到实践，甚至根本就是没有实践这个环节，所以学习很无聊，但是研究生阶段读到这本书，真的是全新的感受，首先，不仅仅只是在说理论了，加入了很多实 践的东西，而且还可以在网上可以与其他人进行交流学习心得。开篇作者就说了“软件 = 程序 +软件工程”，以前写软件或者说程序，就只是写程序，最多会考虑到数据结构的知识，很少会用到软件工程，但是随着学习的深入，代码量的累积，如果还是和以 前一样只是关心程序只要是可用的，实际可运行的，那么就没有意义了，这样的程序写出来也是没有价值的，首先，软件工程不仅仅就只是涉及到计算机或者软件方 面的知识，相反，软件工程涉及了很对其他学科的知识，比如：管理学、数学、工业设计等等学科，一个合格的软件开发人员如果只是懂得怎样去写程序，那么嗨仅 仅只是初级阶段，更高级的应该是从一个更加高级的层面上去考虑更多的东西，如整个软件的架构。整本书从实际软件开发的各个阶段出发，详细地分析了软件工程的各个环节，如：需求分析、设计实现、用户体验、软件测试已经最后的发布等等。首 先，说说代码风格，一个良好的代码风格规范是一个软件开发人员最起码的要求，即使程序写得是多么地出色，具有广阔的市场应用前景，但是如果背后是混乱不堪 的代码，那么就会对这个软件日后产生不少的负面的影响，特别是在后期的维护以及版本的迭代上，不规范的代码对于日后的维护人员来说，简直就是噩梦，以至于 最后实在是没办法了，只好是全部推倒重写，当然这个最坏的打算了，所以好的代码规范是多么地重要，特别是在日后开发具有商业价值的项目时，或者是在一个软件项目的团队里工作，代码规范相当重要。结对编程，对我来说这是一个很有意思的新词，尽管这个词语的出现可以追溯到上世纪，以前不管我们是自己独立地进行项目的开发还是几个人组成一个小团队进行开 发，最基础的还是需要每个人写代码（独立地），但是，在结对编程的模式下，是由开发人员肩并肩、平等地、互补地进行开发，无论是设计、分析、编码、测试。 结对编程最大的好处就是可以使得实际开发出来的代码不断地处于“复审”的过程中，可以及时发现问题，可以及时解决问题，可以极大地避免将问题带到最后的测 试或者是发布阶段。敏捷（Agile）开发，也是一个很早就提出来的技术解决方案，敏捷是一系列的价值观和方法论的集合，前人通过 不断地实践，总结出来的开发方法及开发过程，对我们现在的开发有很强的指导意义，敏捷开发的原则很多，其中印象最深的就是“经常发布可用的软件，发布间隔 可以从几周到几个月，能短则短”，以及“可用的软件是衡量项目进展的主要指标”，我的理解是敏捷开发强调的是“小而美”，定期地完成一个小版本的软件项 目，比只是最终发布产品要好的多，这样也有利于产品的迭代，敏捷中的Scrum方法论，看起来简直就是无与伦比：要做什么->当前要解决什么 ->冲刺->得到一个增量版本。分阶段地不断递进地解决问题，但是敏捷也有很多的弊端，敏捷宣言不是圣旨，不必完全尊从，就像是Scrum， 实际执行的时候也不是看上去那么美好，在一个复杂的项目中，往往不能带给团队更多的惊喜，所以，敏捷慎用。具体到软件的设计与实现，从软件工程的角度来看，并不是一上来就是进行实际的编码，而是进行诸如需求分析、写设计文档等相关的编码前的相关准备工作，第一步就是写设计文档（Design Document），然后针对这个设计文档进行团队内部的复审，然后再进行开发，如果在编码的过程中还会遇到一些意想不到的问题的时候,和PM进行交流，写完代码后，按照原先的设计文档和代码指南进行自我复审，重构代码；接下来写单元测试，如果可以，那么可以发布一个简单的小程序，在少数用户的范围内使用，方便及时地发现问题。好像到了这里，如果没有什么大的架构或者程序上的问题的话，那么一个相对比较完整的软件版本就已经实现了，但是在软件工程中还有一个问题往往会被忽略，那就是“用户体验”，我们都知道一个界面美观的设计有的时候也会给一个软件增色不少，使得用户的第一个直观的感受就是这个界面首先是吸引人的，做好一个用户体验，首先需要明确这个软件的受众或者说面向的是什么样的群体对象，根据具体的群体是喜好进行针对性的设计，才能更好地满足用户。最后来说说软件测试，不仅仅是这本书中，几乎所有的介绍测试相关的书籍，都对测试讲得很多很多，说到测试，大家最熟悉的就是黑盒、白盒测试等，要写好一个不错的测试，首先要有一个好的测试方法，如：Unit Test、Function Test、Structure Test、System Test等等，测试方法多种多样，关键是怎样找出合适的测试方法最好地完成测试，怎样写一个Test Case?这个好像很麻烦，你必须首先知道并熟悉这个需求，要写出一个完整的测试过程，要考虑好测试的边界值的选取，极端情况下程序的健壮性，所以写好一个测试不简单。学好软件工程也是不简单的。

构建软件工程的进阶之道

构建软件工程的进阶之道惟楚有樵2015年3月24日（一）《软件工程》是很多计算机专业必须学的一门课，这门课一般是处于比较尴尬的地位的。说它是理论课，但它里面又需要大量的实操作业，必须做一些编程的具体作业或者编写一个小系统（当然，最多的是什么“图书馆管理系统”之类的作业）。说他是实操实践课，通常的教材里面又都是理论、步骤、原则一大堆，学来学去只是懂得了一些大概的原则。所以软件工程对于学生而言，学了好像没有得到什么。说没学，好像脑子里又有一些理论框框。导致学生认为这门课远不如《数据结构》《操作系统》之类相对理论的课程重要。但事实上，学生到软件公司工作的时候，都需要很长时间来适应编程工作，不能给很快上手。恰恰是由于软件工程这门课没有教会学生真正的本领，没有为学生打下良好基础。我觉得之所以如此，一是在于原有的软件工程的教材是学校老师编写的而不是实际的软件公司的高手编著，导致理论太多，参考来参考去，变成了四不像。二是在于教授本课程的老师本身大多是学校老师（废话，不是学校老师怎么能教书？），我的意思是大多数的老师并没有编写一些实际应用软件的经历，并没有实践过。（不过，现在这种情况慢慢变少，很多学校已经在邀请软件公司的高级工程师来一起承担课程进行互相合作）。不过现在的大学同学们和老师们不用再困惑和彷徨了。一本能够解决上述问题的大作《构建之法：现代软件工程》横空出世，解了上述两种尴尬的情况。这本书的作者邹欣是来自微软的大神，领导过多个大型软件工程开发团队，国内国外科班软件专业毕业。叙述这样的背景并不是为了吹捧作者，而是说明这本书是出自一个在“战争”中洗礼过的人所著，能解决实操性。这本书来源于作者和国内多所大学进行软件工程共同合作6年教学经验的积累，是一本从教学中做出来的教材。解决了理论和实践的结合，具备基本软件工程的理论结构。而且很有针对性，开篇就有给“任课老师和助教的建议”，这门课的教学更多的吸取了西方课堂的教学方式，不是简单的作业+考试或者论文的形式，而是整个学习过程贯穿着一系列的综合作业，学习博客，互相实例编程等等，强度应该是通常课程的3-5倍。我曾经这样写到我初步读完本书的一个读后感：学习软件工程，好像武林之中学习内功。很长时间似乎只能意会而不能身传。这本书是少有的“干货”云集，可教性极强的书籍。通篇强调“做中学”，理论与实践结合，练习量大，要学下来估计会脱一层皮，但如果能过，估计在软件工程的路上会”凤凰涅槃”，终成正果。

构建之法，运用之妙，存乎一心

构建之法，运用之妙，存乎一心1. 构建之法，存乎一心史学理论与史学史，是把历史自己作为研究对象的学科，前者讨论历史本身所研究的内容，后者讨论历史研究本身的历史。这种对于抽象的抽象的研究，正符合计算机领域 meta... 这样的思想。当年 xml 刚出来时，不少计算机和图书情报的大学生照本宣科地提到，xml是关于数据的数据，是 meta-data。史学理论与史学史专家周老师在谈到史学理论的时候说到 (大意) ，学习史学理论与史学史，必先有历史的修养，要努力了解更多的史实，也就是先了解历史所研究的对象，然后才能涉及到以历史本身作为研究。我想，周老师的意思是，没有"肤浅的"认识之前，先不要着急讲深刻。一个例子事实与推论的例子。在网上在现实生活中，都有人跟我提到过，我国人民的善良与热爱和平；作为旁证，中国自古以来就没有杀战俘和屠城这样的事。这时，我愿意以一个建议结束讨论，就是请他去读一下五代十国那段历史。如果连基本史实都还缺乏，遽然得一结论过于草率了。在讲授软件工程类课程时，我也面临这样的难题，正如《构建之法》作者所说，是同学们对此毫无感觉，既不觉得有用,也不觉得有趣。这大致就是夏虫不可语冰的意思。很多同学在学到软件工程的时候，代码量总计可能不到1000行，单一项目最大代码量不到200行。如果去除语言类或算法课作业，代码量就更少得可怜。软件工程所讨论的是当代码量巨大、当涉及人数众多、当项目需求多变时所要解决的问题。而同学们在学习时根本就没有这样的需求。200来行的小程序，没有软件工程思想，也能完成，甚至更快捷。所以，《构建之法》的作者在教学中，要求学生完成大量的代码，让亲身的经验证实软件工程的手段是必要和有效的。除此以外，别无他法。在教学中，可能最大的问题还不是学生积累的代码量小，而是教师也是如此。作为实践类课程的教师，你又写过几行代码，读过几本软件工程著作呢。我的偶像YMH曾经考虑过一个问题，算法课该让哪些老师上呢。我提议：这个好办，找几道ACM题，凡是申请上算法课的老师在线答题，谁答得好谁上。偶像说，那有些老师不会编程序啊。我说：不会编程上什么算法课。偶像大笑。我坚信，一个优秀的将军，也许并非战场上最勇猛的那个战士，但是至少是合格的士兵。软件工程教学，教师须是身经百战，学生须亲力亲为，否则，玩具性质的项目、几行代码的实验课、走走过场不关心实用的工程，都是耍流氓而已。实践类课程，理论如何应用，只能以真实案例呈现 (如果需要规模，那就应该有规模)，而无法用形成上学的方式推演--否则就意味着工程可以自动化，无须人的创造性参与。运用之妙，存乎一心。2. 阵而后战，兵法之常如果工程思想的教学只能依靠师傅带徒弟，口口相授，那么教材和经典著作还有什么意义呢？如果是这样，面对软件工程书，明白的就是明白了，不明白的还是不明白。已经受过苦的人，有过相同经历的，能会心一笑；没吃过苦没糟过罪的，仍然鲁莽行事，事后一拍大腿，"哎呀邹欣已经说过这事儿啦，我当时怎么没明白呢，古人诚不我欺啊"。事实上，即使事后诸葛亮，也是亡羊补牢，尤未晚也。我们有多少知识是本科的时候学了，毕业以后多年才发现，原来在某个意想不到的地方才能用到。与课本相印证，能告诉你，你的失败并非偶然，你的境遇并不孤独，未避免同样的悲剧再次发生打下很好的基础。它还会告诉你，所经历的痛苦，可以用更形式化的方法，或者"最佳实践"得以解决。这比你自己另搞一套，闭门苦苦钻研十年，一抬头发现古人早完成了要好得多。我本科的时候写过一个程序，打印出来，把打印纸抻开，比我还长。用的语言是 BASIC，用行号编辑出来的。随着程序的生长，我越来越为"某些功能在好几个地方用到"感到痛苦--我用的那版本里或者我当时的知识里，还没有函数和过程。后来我终于艰难地完成了那个程序，在读一本1980年代的书的时候，发现了"结构化程序设计"思想。如遇故人，如蒙大赦。没有先前的经验，固然不会让我体验这么深刻，如果没有读到前人的总结，我们就不过是一次次重复失败而已。我们一生，一共也完成不了几个项目。以岳飞之善战，据统计，他一生经历不过几十战役。他的经验或者理论，想来大多是熟读孙子兵法和分析别人的战例得来的。所以说，阵而后战，兵法之常。前人的总结，现有的理论，适合的技术，优秀的paradigm，能给我们一定程度的行为约束，帮助我们更好地解决问题。技术犹刀也，是我们手臂的延伸，而且那上面还附着前辈杀手的灵魂。3. 武穆遗书 有多厚教师在选择教材时，除了受自己学识所限，要考虑学生的专业基础预备知识，还有一个有些无厘头的压力。就是教材的价格。领导们说，教材太贵了学生买不起，教材太厚了学生就不看了。图书馆采购的时候，鲜有优秀的国外教材和经典著作，而多是高校教师混成果用的薄册子。问为什么不多买些 o'reilly 这样的优秀作品呢？答：太贵。同学们也不怎么买书，原因也是太贵。对于抱怨书贵的，侯捷颇有微词，书是用纸张还是用知识来衡量价值。最近，我还看到一个说法，深以为然：你的第一份工作的薪水，与你大学期间所买的技术书总价相抵。其实一本书能有多贵，一场电影，一顿大餐？这些都是过眼云烟，而好的知识，越早了解，受益时间越长，在你剩余的生命之中全都可以发挥作用。请邹欣讲一门课程需要多少钱，请K&R当面给你讲讲C语言，请SICP作者给你剖析一下lambda算子构造邱奇数需要多少钱？上网打游戏感受快乐，你的青春值多少钱？软件工程经典教材，《软件工程：实践者的研究方法》，还有《代码大全》，都非常厚，《构建之法》相对来说薄多了。我想，这是作者的一个妥协的选择。作为大学本科的软件工程，不如叫做软件工程导论更合适，因为受课时和此时学生的经验所限，能涉及的知识都是蜻蜓点水，不得深入。导论类课程，到底是应该罗列完整的概念，这些名词学生们都听说了，从而"知识完整性"得到保证，还是浅显地了解其中的思想 (也许用了完全不同的名字)，还是把徒弟领进门，让有兴趣的同学自行继续深入，没兴趣的同学就此止步，从思路上得到此许受益。这种争议见仁见智。不过如果我是一个学生，我更愿意像读小说或者看电影一样，看到一些故事，以后用于类比，作为模板；而不希望接受高大上抽象的概念，如果能用非常好使，但是正如初高中背政治题，答案很清楚，唯独不知识该用在哪个问题上。如果教材还要再薄一些，我希望它们是科幻小说。我根本不关心这些方法如何具体实施，理论依据是什么，你就领我去看它绚烂的效果，让我亲眼见到它好使得不得了。剩下的，当问题横在我的面前，解决问题的迫切会让学习的艰难、参考书搜集、教材的价格、案例什么的，所有这一切困难迎刃而解，不复存在。这种效果的反面也正是现实，作为教师，你都不会编码，你都不会用软件工程的这些方法，怎么说服你的学生相信你学习你。所谓 learn from, 学生所学习的，不是教师的知识，而正是教师本人。4. 题外话从瀚哥开始，每届新同学都会问我一个问题：老师，你为什么这么关心项目的结果。我知道，言下之意也包括，你为什么不更关心对我们的教学。因为，我们以真实工程作为教学的工具。这是因为，没有人乐意做假的工程，仅仅为了学习目前还不确定是否有效的知识。这意味着，真实的工程必须存在，才可能用于教学，而真实工程不同于假的实验的是，如果它失败一次，以后就不会再有真实的工程了。也就不会再有真实的工程用于教学。训练猎人的时候，要求师傅把猎物捆个结实，为了防止学徒害怕或怜悯它挣扎，还要给猎物打上麻醉剂，再给学徒穿上防磕碰的盔甲防溅血的服装，你为什么不再戴上护心镜和老花镜躲到绣楼里去。所以，当你要求或接受真实工程训练的时候，你就给了我你的承诺。我把武器交给你，你要像我保护你那样保护你。无论这个承诺有多么的小，一旦你说出来，它就是我的，不再属于你；我有权放弃我的权利，你没有权利背弃你的诺言。你，你们，背弃对我的诺言，我非常失望。我知道你并不在乎我失望与否，我也并不在乎你给我造成的损失，我在乎的是我所面对的我所关心的，是这样的世界。如果承诺不可信赖，未来还有什么可以期待。------------------------------------------博客会手工同步到以下地址：[http://giftdotyoung.blogspot.com][http://blog.csdn.net/younggift]

现今计算机专业学生最需要的书！

“当学生毕业之后觉得在计算机专业中最没用的学科是什么——软件工程，而我觉得计算机专业中最有用的学科是什么——软件工程。” 这句话是我指导老师说过的一句话，这也是我这学期听过印象最深的一句话。他讲了这么一个令人难以相信的事实给我们听：几个工作了十几年的 IBM 程序员不会通过单元测试，性能测试，持续集成测试等东西来测试软件质量，项目上线时需要人守在电脑前一直看软件是否有问题，最后的结果是并发性不合符要求，经过多次修改结果也没变。这十分难以相信吧，工作你十几年的，而且还是 IBM 的程序员了。而大概就是不懂软件工程的结果。我觉得现今的软件工程的课存在这样的问题：1. 不以学生独立完成一个软件为目的。而是以交付文档的目的。导致学生抄袭严重，没有开发经验，以为软件就是写文档，画 UML 图。2. 使用教材过于陈旧。学习的理念陈旧。这么多年仍然详细学习瀑布开发，对敏捷开发仅仅蜻蜓点水。3. 考试题目简直就是文科的题目。只要是死记硬背就能过的。4. 绝大部分学生没有开发经验，更没有多人合作开发软件的经验。当多人合作开发过软件，有项目失败经历的让你越能体验软件工程的价值，而对于没有开发经验的学生老师跟学生讲软件工程相当于鸡同鸭讲5. 有些老师本来就没有什么开发经验，可能就开发过几个没什么人用网站之类而且对于软件工程的观念停滞。自己都不是很懂怎么教学生。只能依书直说。。。起初，我是上知乎看到周筠老师在推荐这本书，在看了一下截图的内容，觉得这本书的内容太合我口味，马上下单。在看了一遍之后觉得这本书太值了。有很多我用了一两年的编程学习得到的结论在这本书中都有很好很深刻的总结和论述，而且有过之而无不及。然后我再看了一下邹欣老师的博客，看到他是怎样用他的理念进行教学，怎样指导学生进行确确实实的开发，学生是怎样利用博客汇报开发的情况等等。不禁感慨，能够上邹老师课学生是一种幸运。充分利用网络资源，让教学更公开化，我个人感觉这种教学方式十分先进。说回书，我对这本书的评价是：现今计算机专业学生最需要的书！绝没有半点夸大。下面让我来说一下这本书好在哪里。1. 文章写得生动形象，写得很程序员。我在这里很程序员不是一种贬义，而与之相反。在我眼中，在业界浸淫多年的程序员，不仅风趣幽默，而且可以用他们的智慧把一件复杂的事情说得简单易懂。说话不但不会老气横秋，而且有时代感，贴近生活实际。用我指导老师的话说就是会说“人话”，毕竟程序猿会说人话实属不易。（自黑一下，逃）2. 明确师生关系。在这本书的概论之前，将大学软件工程专业理想的师生关系概括为健身教练和健身学员的关系，甚是准确。而在讲述软件工程之前理清师生关系这点上，我十分认同。3. 为广大计算机的学子，树立正确的编程观，绘画出工程师职业发展的蓝图。大概每个没有接触过软件开发的学子都会有这几种疑惑：（1）学好算法，搞好ACM就能找到好工作了吧？（2）学好java，上个培训班学习java，android的开发就能找到好工作了吧（3）我会十几种编程语言，我会十几种编程语言输出“HelloWorld”就是牛。而这本书的前三章，仅仅是前三章就能解决这几个这个疑惑。几乎所有的程序员都知道 “ 程序 = 数据结构 + 算法 ”，加上老师的忽悠，不少人走上 ACM 的道路。但是我也不是说黑 ACM ，ACM 对思维的锻炼还是显而易见的。但是 ACM 这种东西还是会受限于个人的天赋，就算你怎样努力，相信大部分人也不会取得很大的成绩。我们学校的情况，有人日以继夜地刷题目，取得成绩一般，对于计算机的其他课程也不会很了解。在他们的心中，只要算法好就能找到好工作，因为他们心中 “ 程序 = 数据结构 + 算法 ”。但事实上，懂算法懂数据结构就能开发出软件吗？而我问起我的指导老师这个问题的时候，他是这样回答的，坚决不要搞 ACM 的，因为他们除了算法什么都不懂。难道只有他们懂算法吗，开发人员难道就不懂吗？不懂难道不会自己再网上找来学吗？。而邹老师提供了一个更高层次的抽象足以解决以上的矛盾，“ 软件 = 程序 + 软件工程 ”。而软件工程需要需求分析来做概念的完整性，需要有测试以保证质量，需要软件维护等等。而根据这个公式软件开发人员，除了懂程序之外也更要懂软件工程。而为什么大公司愿意请那些在大赛取得优异成绩 ACMER 实习呢？大概因为那只是实习。或者你只是以为他们只懂算法罢了。而培训班就教你简单的 java，android 开发，能懂软件工程吗？懂十几种编程语言的，不排除会有真正的高手真的理解面向对象，函数式编程等范式编程思想，但这种情况的绝大多数人只是停留在这本书第三章所讲的低层次的问题。不能理解计算机中的高层次问题，但时间就浪费在学习语言这种无聊的事上。而第三章的职业规划相信每个学子看到都会有所收获，至少前路看得清。4. 重视编码，重视软件质量，重视对软件工程的理解。我不明白老师要求学生提交测试计划，测试文档，UML 类图，流程图等东西是出于什么心态。看学生开发的进度，难道看看类图之类的东西就能看到学生的开发进度了吗？ 虽然这些东西确实要写，但是这些东西就能代替开发工作吗？学生真的懂怎样开发吗？开发计划那些随便瞎写，然后上网下个开源的代码论坛，在根据代码乱画 UML图。这就是我们学校软件工程的结果。第三章，初级软件工程师的成长，邹老师的一句反问。“一个工程师开你博客，转发很多别人的文章，这算有思想吗？另一个工程师坚持做任何设计都要画UML图，这算有思想吗？”我更是印象深刻。就如邹老师的微博名，程序员邹欣。大概是因为是程序员，所以十分重视编码，更注重编码的质量。第二章就有单元测试的详尽介绍，第四章中在讲代码的规范和复审，十三章讲的各种软件的测试，十四章讲质量的保证。之前我都知道这些概念，也做过，但十分排斥这些测试。大概是因为是师兄说要做单元测试，单元测试覆盖率要保证在90%以上，要用loadrunning做下性能测试。理由也只是因为这是质量的保证。当时too young toosimple的我，觉得做这些东西有点浪费时间，甚至跟师姐“讨论”了一番，当时我的观点“如果测试这么重要，为何开发人员比测试人员的工资高”，最后师姐也只是很牵强说服一下我。由此可见，说服一个人不是这么地简单。看了这些章节后，充分明白为什么要做的，对于这些测试也没有那么地排斥。当下次师兄说要做代码复审，我表示非常认可。我觉得要透彻地了解软件工程，很简单，就是踏踏实实地开发一个产品，了解开发的流程。但也很难，因为不是这么多人喜欢编程，我们年级（200多人）每天都写代码应该不超过15个。5.当之无愧的“现代”软件工程。(1)在这本书中会有介绍敏捷开发，而不是蜻蜓点水。更说了敏捷开发的使用范围，打破了我之前觉得敏捷开发就是万能的想法。(2)会说到用户体验的问题。这也是我们实验室最近一直强调的东西，被人吐槽软件的用户体验已经很多遍了。虽然这里讲得不是很详尽，但有专门一章去讲软件的用户体验甚是难得。这章中的滑稽搞笑的例子，印象深刻。(3)关于IT行业的创新这一章，甚是惊喜。我没有想到会在软件工程的书籍中说到科技的创新这一点。而且对我来说这章讲得不错，矫正我对创新的各种错误认识6. 最后一章 人、绩效和职业精神。看了，但还没有到工作，所以对绩效没有什么深刻的认识。但是萝卜与白菜的故事，甚是深刻。关于这本书的建议：1. 相关网页放在章节的后面，翻看有点麻烦，不是很习惯2. 嘻嘻哈哈地学习软件工程是不错，但是章节深度不够是肯定的，就如：第四章代码规范，肯定是不够 《代码整洁之道》《代码大全》好。如果在这些章节的后台推荐一些书给同学们参考就好了3. 可能是书名，还是封面不好，我推荐给同学看，接受的程度不是特别高。4. 希望邹老师能够添加自己对未来软件工程发展的看法。======================豆瓣处女书评，如果觉得我的书评中有什么不足的地方，欢迎指出。

建议把书里的链接，按章节列出放在网上

如果出版社已经发布了所有链接的面面，建议在本书的介绍页面中明显标示。就像介绍页面中明显标示出各网店出售本书的地址一样。第8章，需求分析第164页http://www.stellman-greene.com/aspm/contnt/view/23/38/http://en.wikipedia.org/wiki/Wideband_delphihttp://www.drdobbs.com/stop-promising-miracles/184414570

软件工程还可以这么写——读《构建之法》

2003年的某个寒冬的夜晚，我决定放弃继续阅读那本英文原著《Software Engineering: A Practitioner's Approach》。第二天就要考试软件工程了，可是我还有最后三章没有看完，管不了那么多了，再看下去真的要吐了。所幸只是开卷考试，即使有些题目没答出来，还是考了85分。十二年之后我还能清晰的记起那天夜晚时我的感受。我很少半途而废，尤其是在看书或者学习上，但那是其中的一次。在那之后，因为职业的原因，依旧对软件工程领域保持着关注。期间看过比较好的著作有《人月神话》，还有《走出软件作坊》（有趣的是和本书是同一策划）。但这两本都不太适合作为大学生的教材使用。直到春节前，因为研究创新的话题而买了这本《构建之法》。看了之后就被其中的一些内容吸引住了，特别是作者邹欣的诙谐的语言，简直可以当段子看。因为不用为了考试而赶工，这本书是断断续续的读，一般是在遇到某方面的问题时，把对应的章节阅读一下，所以直到最近才把整本书看完。要考虑到我是一个工作了八年的工程师加项目经理，评价的视角会与在校学生不同。本书的第16章是讲IT行业的创新的，是我最喜欢的一章。正是因为这一章，解开了我多年对创新的困惑，即“伟大的创新怎么就灵感一现的来了？“。这一章是邹欣的博客文章《IT 行业的创新》的扩展版，内容要更系统一些。至于一本讲软件工程的著作为什么要讲创新？我专门咨询了邹欣老师，并得到了解答：Build To Win - 构建之法 - 知乎专栏。当最初看到这章内容的博客版时，真的有种相见恨晚的感觉，要知道我已经被创新这个概念问题困扰了至少十年了，如果在2011年这篇博客发出时就能看到，要少死掉不少脑细胞。我还通过周筠老师（本书策划编辑）拿到了这章内容的PPT，先后给两个团队（离职前在百度带的团队，以及现在的创业团队）做了分享，许多同学听了表示很受启发。有位同学说之前都觉得创新是一件很遥远的事（都是些传奇故事），听了之后自己都有信心做出些创新的东西来。因为创业的缘故，对团队的人的因素比较关注。本书的最后一章讲到了猪、鸡和鹦鹉的故事。它们三类动物凑在一起开餐馆，猪割了自己的肉做红烧肉，鸡下了蛋卖煎蛋，鹦鹉扯扯嘴皮子吆喝顾客。它们三者的投入和风险是不同的，得到的回报也是不同。在从考虑创业到真正创业三个月，这个过程中对这个分类深有感触，自己心中的这杆秤可以分的很清楚。经常有些朋友拿着自己的想法和团队和我聊创业，我都会把这个段子讲给他们听。前面说到这本书的一个特点是语言诙谐，还有一个特点就是讲的透。我从2008年开始带团队，到现在也有了7年的经验了。但看到书中讲团队合作划分为萌芽阶段、磨合阶段、规范阶段、创造阶段时，才恍然大悟，为啥有的阶段的产出不靠谱，而有些时候又非常好，原来有阶段的因素在里面。对于什么是团队，什么不是团队？书的第5章举了个形象的例子，一堆路边打零工的，你给点钱就去干，干多少拿多少的钱，各做各的事，这只能叫乌合之众。而真正的团队应该像接力赛跑、足球队那样，有共同的目标，并且有各自的分工，相互协作共同完成任务。书的第三个特点是与时俱进，不管是创新，还是用户体验，还是敏捷开发。都是一些在当下IT领域最为关心的问题，而非和现实脱节。至于需求分析、软件设计、开发、测试、发布等经典环节，本书都有系统的论述。当然，我已经过了学习这些基础知识的阶段，相信对初学者更为有用。在阅读本书的过程中，我有幸也加入在了构建之法微信群中。目睹了几个学校使用本书作为教材的实践过程，以及遇到的一些问题，相信那些认真学习的本书的学生，会有更大的收获。

我都类比项目研发过程，跟编程没什么太大关系

《构建之法----现代软件工程》对于这本书我最主要的想法是：这虽然是一本讲软件工程的书，但是里面的原理可以应用到我们做一个项目的流程，有相似性，每一个环节对于项目研发来讲都是很适用的，而且流程逻辑清晰，主线明确。对于编程而言，我并不陌生，大学专业与编程相关性很高，毕业后也从事过编程的工作，这是一个很有挑战性的领域。开始读这本书，最大的感受的感受就是软件工程其实是很有意思的，当然在日常生活中也应用性很强。开篇作者就说了“软件 = 程序 +软件工程”，以前写软件或者说程序，就只是写程序，写过C语言和C++程序，最多会考虑到数据结构的知识，很少会用到软件工程，但是随着学习的深入，代码量的累积，会发现软件工程不仅仅就只是涉及到计算机或者软件方面的知识，还应该涉及了很多其他学科的知识，比如：管理学、数学、工业设计等等学科，一个合格的软件开发人员如果只是懂得怎样去写程序，仅仅只是初级阶段，更高级的还应该考虑整个软件的架构。整本书从实际软件开发的各个阶段出发，详细地分析了软件工程的各个环节，如：需求分析、设计实现、用户体验、软件测试已经最后的发布等等。第一，先调研客户需求，在做任何项目之前先要对市场进行调研分析，根据市场反馈的需求信息去做相应的产品，这样才能保证产品做出来之后能有稳定的客户群。第二，设计实现，这是研发过程中最主要的一环。先说说本书中提到的代码风格，一个良好的代码风格规范是一个软件开发人员最起码的要求，即使程序写得是多么地出色，具有广阔的市场应用前景，但是如果背后是混乱不堪的代码，那么就会对这个软件日后产生不少的负面的影响，特别是在后期的维护以及版本的迭代上，不规范的代码对于日后的维护人员来说，简直就是噩梦，以至于最后实在是没办法了，只好是全部推倒重写，这样会浪费很多的资源。项目的设计研发也是一样的，在设计研发的过程中首先要进行产品多次迭代，确定产品的主心骨，然后在之后产品进行升级。第三，用户体验。用户体验是产品是否成功的最重要因素，如果用户对于产品不买账，产品就是失败的，而客户体验也是产品进行优化最主要的依据。最后，等之前的每一步都做好了之后，进行产品的最终发布，那么这个产品一定是实用性很强的。

等待也许是国内最好的软件工程教材

#Comment_Alpha timestamp = 20140830-05:00am先不论书，首先五星给邹老师精彩的博客和至今仍在脑海中回想的《移山》。（博客地址 http://www.cnblogs.com/xinz/ ）邹老师的博客有一段时间不更新了，原来是在潜心着书啊！作为《移山》和作者的博客长期读者，可以说邹老师的文章enlightens me a lot。 对这本书，别的不说，仅仅就邹老师极其幽默的文笔和Learning by doing，Knowledge construction by critical thinking的授课风格，小弟就充满了期待。 btw，说现代软件工程任务量大的同学，可以看看Coding Master Univ的计算机系的这门课 http://www.cs.cmu.edu/~410/ 翻翻过往的记录，同学您就知道现代软件工程的任务量已经很人性化了。以上是满满的期待。(☆_☆)/~~先占坑，等到手后再写具体的评论。

做中学习

本人非计算机专业，在专业课和自学软件的过程中，都深刻感受到被动接受知识的弊端。学以致用，将知识用起来才能体会到学习的乐趣。师者，传道授业解惑。学习的一个作用就是解惑，心中带着疑问才能高效率学习、正真领会知识的内含。通过做小项目和练习、有助于产生疑惑，用问题引导学习更加有针对性，形成良性的学习循环。开篇看到书中的讲解思路——做中学习，让我欣喜若狂。邹欣老师给任课老师和助教的建议内容，可以看出他是真正站在学生的角度上考虑：如何让学生在学习中保持热情、如何让学生高效学习，让学生自己练习和表达、从而构建自己的知识体系。

《构建之法:现代软件工程》读后感

二更：“掀起你的盖头来” — 剖析《构建之法》（更新于2016年5月14日）文/A软件领域可以分为两个方面：一方面是技艺创新的大爆发；另一方面是坚持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90% - 95%的比例。—— 瓦茨·汉弗雷 / 软件工程的奠基人之一”遇见《构建之法》，实属偶然。2015年初的某个上午，刚到公司，发现位置上多了一本书，说是公司发的。这本书的全称是《构建之法 — 现代软件工程》，封面设计得很朴素，说实话，没有亮点。但作者吸引了我，在念大学的时候就开始在微博上关注邹欣老师，他是微软Windows中国工程团队首席研发总监。第一次翻开《构建之法》，真的是眼前一亮，这本书与国内高校常规的软件工程教材有本质的不同，这本书写得跟小说似的，而且语言幽默风趣，颠覆了传统软件工程教材刻板生硬、枯燥乏味的形象，相较之下，这本书显得清新脱俗。一、其实这就是一本小说“阿超”、“小飞”、“果冻”、“小李”都是现实中典型的软件行业从业人员形象。我在现实中，就遇到过“小飞”和“果冻”的混合体，毕业刚一年的应届生，看过点代码，相当浮躁，总想着一口吃成大胖子，可是基础薄弱，更缺乏经验，老想着做大功能，总是说之前看过什么，之前做过什么，扯一些名词，他说的东西恰好我也略知一二，于是我便抱着和他探讨的心态，问了他几个问题，他却支支吾吾了半天。没有必要装这种逼，一下子就穿帮了。“看过”和“看懂”是两码事，夯实基础比什么都重要啊。正如书中所说的，“我们要让团队中做事不仔细的人慢下来，这样能减少他们的危害”；另一方面，这种人有热情，能踏踏实实的话，是一定会有成长的，只是现阶段对项目的影响还是“危害”大于“贡献”。“萝卜快了不洗泥”可不行，先做一颗“慢工出细活”的“白菜”可好？也见过那种自认为“我是写C++的，你们这些写C语言的都是low逼”的人。我也很幸运地得到过基础扎实，大局观优秀，而且细致耐心的大牛的指导。可以说每家公司都能见到这几类人，作者根据他们的特点而虚构的人物，很容易让读者产生强烈的代入感，很容易入戏。当作者提出一个具有争议或让人困惑的观点时，会通过文中虚构的人物来提出读者可能的疑问，并通过对话的形式，给出作者自己的见解。例如以下场景。“项目接近尾声时，要确保（修复）门槛越来越高。今天的“Must”必须比昨天及以前的“No”严重性高，这样才能不断提高系统的稳定性。小飞：这个“Bug bar越来越高，事实上是说有更多的Bug会留在软件中，这是不是意味着在最后关头忽略质量。”作者随即借”阿超“之口，说出了自己的看法。这种自问自答的对话场景贯穿全书。”提升Bug bar是放走一些无伤大雅的Bug，换取项目能如期完成。其指导思想是抓大放小，既然没法全解决，就集中精力解决最重要的Bug。避免频繁地到处改动代码而引入新的Bug，是以谓之”稳定“。但是，我们还是会研究”为什么在产品后期才发现这样的Bug？早干什么去了”。这些问题会成为我们“事后诸葛亮”会议的议题。“二、自己使用自己的方法论在第10章中提到的如何定义典型用户和典型场景，以及从典型用户到场景，从场景到任务的过程。作者在写书的过程中，也恰恰使用了这套方法论。有了典型用户之后，我们还得决定每一个典型用户的目标 — 他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。“阿超”、“小飞”就是《构建之法》这本书的典型用户，他们之间的对话就是现实中许多工程师在工作中会遇到的场景，这是“从典型用户到场景”。场景怎么写？首先针对每一个场景，设计一个场景入口（描述场景如何开始）。接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）。然后给场景划分优先级，按优先级排序写场景。作者借书中角色之口，说出了工程师们在遇到问题时的困惑，以及思维方式，并对他们在当前场景中的心理活动进行了幽默风趣的刻（吐）画（嘈）。“小飞：超总，我想提一个和我职业发展有关的问题。我们接受的可都是科班的软件工程教育，我们当时的院领导说我们毕业后都是要朝CTO发展的，至少是软件金领，我当然知道这是遥远的将来的事，但是我总觉得我至少可以做一个软件白领吧，这些构建之类的事情，嘿嘿，是不是要由所谓的软件蓝领来做？阿超：问题提得好......他望着这位将来的CTO、软件金领，突然想抄起身边的塑料水桶，把水都从他的白领里灌进去。他喝了一大口水，退到窗边，勉强把这个念头压了下去。阿超：我觉得大学的软件工程课，本来要教全面的技术，但是考试往往只考定点投篮和无防守情况下的配合......（以前面的篮球考试为例切入）。”我不禁感慨，不会写小说的程序员不是好编剧。然后，作者再给出他的看法以及一套解决方案，应该怎样解决这些问题，这是“从场景到任务”。三、谁最适合看《构建之法》本书作为软件工程课的教材很实用，可以让学生一开始就接受“正规军”的系统训练。但是，如果学生没有足够的代码量和工程经验，对里面所讲的很多问题并不会有太多的切身体会，可能很难深刻理解。我认为《构建之法》最适合有一定代码量积累和经验的人阅读，尤其是在做项目过程中，时常感到困惑的一线工程师，或者是面对一个庞大的软件项目开发任务而感觉力不从心，无力掌控的负责人。此时，这本书就能帮助读者“理论结合实际”，发挥它最大的功效。但这并不代表不适合缺乏软件经验的人看，这部分读者把它当成是一本趣味性强的“软件工程导论”也未尝不可，对相关的软件工程概念有个印象，先在心里“播下一颗种子”，未来在成长到一定阶段再来反复精读，在实践过程中慢慢体会，“做中学”，这颗种子便会生根发芽，开花结果。比方说书中提到的一些估算工作量的方法，例如“Y=X±(X÷N)”。对于刚接触这些估算方法的读者而言，觉得这公式很玄，不知道是否靠谱，只能先了解个大概，以后在自己的实际工作中去体会，去把握。第一次估算不准，多估算几次，从而形成自己的一套关于工作量估算的方法论。对于书中第6章提到的敏捷开发也是一样。以下是敏捷开发的一种定义。“敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用的状态。”什么时候该使用“敏捷开发”，还是“瀑布模型”。设计的时候是“自顶向下”呢，还是“自底向上”呢，都不是绝对的。需要根据实际的项目情况，去分析，去拿捏，更多时候是多种方式结合使用。而且软件工程不是单一的学科，它是多学科交叉的一门综合学科。除了要具备工程能力外，还要有良好的基础知识，和一定的架构设计能力，以及必要的沟通能力，不然无法掌控一个大型的软件项目。四、适用范围在软件领域的各种角色其实都适合看这本书，例如软件工程师、硬件工程师、项目管理工程师、测试工程师、产品经理、研发经理等，可以让一个项目团队中的不同角色了解其他人的工作内容和职业特质，让大家在同一个“知识体系”内，或者说在同一个“话语体系”内，避免出现“鸡同鸭讲”的情况，减少不必要的沟通成本。例如，第5章的“团队和流程”中，提到了足球团队。足球团队从一开始的一窝蜂抢球演变到后来有明确分工、阵型、战术的团队，软件团队也是如此。其他领域的团队是不是也有“主治医师模式”、“明星模式”、“社区模式”、“业余剧团模式”、“秘密团队”、“特工团队”、“交响乐团模式”、“爵士乐模式”、“功能团队模式”、“官僚模式”呢？第10章的“典型用户和场景”、第12章的“用户体验”，这同样适合产品经理阅读。如何定义用户，如何定义场景、如何写功能说明书，这不就是互联网公司产品经理的日常吗？第6章的“敏捷流程”、第7章的“MSF（微软解决方案框架）”，对其他工程领域也有一定的借鉴价值。第17章的“人、绩效和职业道德”适合管理者阅读。在项目开发过程中，由人组成的这个集合会慢慢演变出五类人。P = {P1 = 做事的，P2 = 不做事的，P3 = 不让别人做事的，P4 = 作假的事的，P5 = 假装做事的}。中药组方的原则叫“君臣佐使”，“君主”、“臣僚”、“僚佐”、“使者”四种角色分别起着不同的作用。“针对病因或主症的主要药物为“君”，辅助主药发挥作用的药物为“臣”，治疗兼症或消除主药副作用的药物为“佐”，引药直达病所或起调和诸药作用的药物为“使”。”“君臣佐使”，让合适的人在合适的时机出现在合适的位置上。当然，“合适的人”和“合适的位置”也是在动态变化，P1/P2/P3/P4/P5并不会一成不变。这一章节作者通过对一些常见绩效管理的反思，例如，比工作量/比资历/大锅饭/比效率/背靠背评比，介绍了一种二维的评价体系来区别对待。这是一本探讨方法论的书，既然是方法论，那其适用范围就绝不仅限于软件工程。作者从其他方面去与软件工程中的相关知识作比较，看似说的是软件工程，但其探讨的方法论也是适用于其他领域的。其他行业也可根据书中提到的方法论，实现"1+1>2"的效果。五、主题阅读的索引本书每章节后的参考文献链接也可作为继续深入学习的“索引”，帮助读者完成“主题阅读”。这些参考文献链接可以帮助读者强化对各章节的理解能力。而且参考文献涵盖的面儿比较广，并不全是深奥的理论，也包括技术博客、相关话题的新闻、软件发展史或行业史上的奇闻轶事等。这本书有些链接是作者自己的技术博客，里面有作者在北航教授软件工程课程的讲义，成书过程绝非一蹴而就，作者09年开始在北航开设《现代软件工程》这门课，清楚国内软件工程教学的现状，因为有长期的教学实践经验，能够抓住学生们的“痛点”，并结合了自己多年的研发经验，让这本书更接地气。———————————————————————————————————————————（原文写于2015年2月1日）读构建之法, 打持久之战之前一直有在微博上关注邹老师，最近有幸拜读了《构建之法》，自知水平不足，不能对这本书提出有见地的意见，只能结合自身的工作经历，写点读后感，聊聊自己在工作中的一些感受。不算是书评，以后再更详细地评论这本书。我是网络工程专业毕业的，业余时间喜欢研究Linux内核中的面向对象思想和设计模式，喜欢玩硬件，还有不能自拔的“工匠情怀”（自觉脑补老罗那幅图），所以毕业后，工作在嵌入式领域，希望“软硬兼施”。一．背景差异该领域的一线工程师与互联网行业有很大的不同。嵌入式领域的工程师主要是电子类专业毕业的，例如，电子信息科学与技术，电子信息工程，通信工程等专业。在本科期间，在校课程并不一定开设软件工程这门课，即使开设，也不会受到重视。（勤奋好学，目标明确的同学不在此讨论范围内）。而且很多嵌入式设备的代码量并不大，因此，很多电类学生在写程序的时候，其实是没有“框架”这个概念的，很多程序可能就是封装几个寄存器操作函数，然后开始写程序，写到哪儿算哪儿。软件“腐烂”得很快，接手这种代码的第一感觉就是必须重构了它。于是，吃了很多亏，才开始琢磨是否可以“复用”一些代码，开始注意“功能”复用，接着“框架”复用，“模型”复用。这些意识上的转变对于电类的学生来说，需要很长的时间，而且他们的代码量不够，没有吃过足够的亏。但是，这不能成为不重视软件思想的理由。任何涉及到软件开发的岗位，都必须有软件思想去指导实际工作。二．“设计文档没可能写得那么细的”这句话在很多小型的电子公司中，经常能听见。不少软件项目负责人并不重视项目初始阶段的软件详细设计文档，只是写个大概，更像是为了证明自己是“正规军”，而走走过场。很多主导一款嵌入式设备软件开发项目的负责人，其本人并不是一个优秀的程序员，无法真正把需求转换成相应的软件模型，无法很好地进行抽象。在一个项目的开发过程中，需求分析，把需求抽象成相应的软件模型，思考使用哪种设计模式，框架代码如何拥抱变化。软件工程师不能阻止需求的改变，只能最大限度地拥抱它。软件应做到在只修改配置文件的基础上自由地扩展和裁剪功能。这些是需要在团队动手之前想好的，否则后期会很难受，尤其在项目进度压力大的情况下，一个需求的扩展可能就搞得整个团队紧张兮兮。三．在战争中学习战争我最近在主导一个功率计的软件开发，时间非常紧。有点像书中关于“团队”模式中所提到的“主治医师模式”，我通过与非软件的同事反复确认需求说明书中的条款，避免因表述不清而出现歧义，并转换成软件设计文档，文档中包括对需求的解读，如何用软件抽象该需求，软件模型是怎样的，框架设计细节。最终，使用C语言写了个MVC模型（C语言也是面向对象的，好不好），采用“分而治之”的思路，并把繁琐的逻辑拆分成独立的“插件”，逐个击破，通过配置文件决定是否调用某个“插件”的构造函数，实现“插件”的可插拔。软件工程中的团队模式与足球中的战术体系，在本质上是一样的，谁动不动就强调他的个人能力，那么他一定不懂得配合队友，这是意识的问题。为了不断提高自己的水平，突破自身的瓶颈，我采用“做中学”的态度，结合《构建之法》中的原理，指导自己的开发工作，效率提升得很快。《构建之法》之于现在的我，就像《论持久战》之于抗战初期的中共，具有绝对的指导意义。

难得的软工教材

出版前有幸帮助做了proof read, 作为一个在这行天天和类似问题打交道的人都觉得颇有收获，实践能力很重要，但能把实践中的理论体系化，反过来再来指导实践是件很不容易的事情。 软件工程在大学是最难讲的一门课、也是最容易讲的一门课，容易在这门课涵盖的内容和外延特别丰富，这些内容学生基本没概念、短期也无法落到实处来验证有用没用，所以老师可以大讲特讲，人畜无害；难就难在你要在学生一片空白的情况下（没有很强的代码能力、没有团队概念、没有项目经验）去让他懂得这些东西，那必然得自身有丰富实战经验，能深入浅出、兼顾理论和实践，能用生动的案例勾起学生兴趣并引诱他们从实际的项目认识这门课的重要性。 在我认识的人中，能有丰富的项目经验又愿意花时间在教学实践上最终能把各种知识理论体系化的人寥寥无几。邹欣老师是恰好这几点都具备的人，所以对他的书在开卷之前是充满期待。花了大概一两天快速的翻完整本书，最大的感受是这本书出版的恰当其时，传统的软件工程教材早就该翻新了。即便作为一本课外读物，学生也需要这样一本书来引导他们从一个码农走上真正的软件工程师之路。在传统软件工程所关注的需求、流程、团队协作管理和测试这些部分，邹欣老师重新用实例辅以故事的手法，把原本比较枯燥的内容讲的生动易懂；除此之外，有些章节，例如软件工程师的成长，对学生的职业生涯的规划很有帮助；而有些章节，敏捷流程、IT行业的创业的迷思等对我这种长期在一线参与研发的人都大有裨益，从中有所感悟。太好的话不多讲，这会是一本很好的软件工程的教材、参考书，对已经在IT职场奋斗并想在研发管理部分更上一层楼的同学也是很好的读物。

软件需要严肃对待，谨慎修改

首先，作为一个嵌入式工程师，一般纯软件工程的书我平时很少会去看。但之后由于工作的原因，日渐偏向软件方面。在工作之余想提升自己在软件方面的能力，就读了这本《构建之法》作者不愧是有着丰富技术经验的软件工程师，如果我还是学生的时候，读这本书印象不会很深。但现在有了一定的工作经验、碰了不少钉子后，才发现书中的内容均是经过不少实践后总结出来的经验，而且很多关于合作上的内容看了简直不能再赞。作为一个刚刚工作三年的菜鸟，而且还是半路出家，对于“软件工程”这个概念一直都停留在听说过的层面，自己平时编程时也不甚注意一些软件方面特有的工作方法，致使走了不少弯路。在读这本书的时候，我时时刻刻感受到作者出身于顶级软件公司技术第一线的高超水平，很多例子举的都非常接地气，而且不少内容让我觉得相见恨晚。之前在编程中，我甚至都不知道“单元测试”这个名词，也不知道其的重要性。在知乎轮子哥发的一篇文章里才看到过，现在在作者的书中看到了详细解释，特别是那句“如果连单元测试都没有时间做，那么也没有时间写好这个功能”，“单元测试应覆盖所有路径”等，回想起我在工作中碰到的几次反复，真是越看越觉得所言非虚。之前我总是认为代码不过是在键盘上敲敲，有时候改起来比较随意，弄的给我测程序的人颇有微词。本书中讲到的代码审核、结对编程、敏捷流程等等一系列的软件工程特有的知识，看完后让我感到软件是一门工程，是一门学问，是需要严肃对待、谨慎修改的作品。这本书对我最大的帮助就是建立起了软件工程的概念，同时不少的先进理念与工作技法都是作者的经验之谈。大大开阔了我的眼界，应用于实践中必将对我工作有着很大的帮助。

100倍速度前的慢动作

周老师请我写下读后感，一直没有写，原因是工作十几年第一距离技术一线渐行渐远，第二距离微软方法论渐行渐远，第三在近期工作无论微信硬件平台还是无人机都是最前沿的领域，没有太多可以参考的东西，基本都是在破坏旧世界建立新世界，对团队同学和自己的要求都是首先“忘掉过去的经验”。看了邹老师的《构建之法》，往日在微软学习的扎实的方法学一幕一幕回来，里面也加入了很多邹老师在研发互联网产品对微软传统方法的反思和互联网方法的实战经验。我把几本书送给微信的几位核心开发，反馈也是，如果新同事有这样扎实的训练，更能够适应微信高灵活性的开发。和曾经微软的一名开发同事现在小米公司的一名核心员工聊天，我问他，你在微软和小米都做了开发，两者的区别是什么？回答：把微软方法的速度提高一百倍就是小米的方法。因此，对于学徒，在实战之前，先认真学习拆解动作，免得将来到实战场基础不行速度上不去被淘汰，或者速度上去了基础不扎实打成王八拳误伤了自己。因此，买书学习，别选那些三脚猫的神忽悠，看邹老师的书，周筠老师的书，都是口碑之选。别费时间去网上找PDF，别买盗版，你花多少钱投资自己决定你将来有多少回报。《构建之法》，就是100倍速度以前的慢动作学习。

构建之法，超越软件

收到china-pub 寄来的《构建之法》，忍不住一口气读完。经常有业界人士抱怨毕业生只有知识而不会方法，在理论原理和开发技术细节之间，缺少的正是构建之法。一切系统都需要构建，构建都需要方法。所以邹老师这本书的意义实际上是超越软件工程领域的，值得所有工科生学习体会的。在我们所在的制造自动化领域，设备和系统中软件的成分已经越来越多，一个机电系统慢慢从机械零件的集成、电子芯片的集成发展到复杂软件系统的集成。每次用到欧洲公司开发的控制软件，我一直在思考的是，他们到底用什么开发模式来开发如此稳定可靠好用的软件？国内很多很有名的自动化企业，生产的PLC或者机器人控制器的底层软件其实都是购买欧洲公司产品，而欧洲一家很小的公司，也能推出一个功能完整的机器人控制器产品，说明我们自动化软件的构建能力和欧洲同行比还很弱。可以想象，一个具备良好机电背景和软件构建能力的毕业生，将有无比广阔的舞台。通过阅读邹老师这本书，我们有必要进一步思考和实践控制软件的构建之法。此外必须要为周老师出版团队的工作点赞。

其实还是软件工程

软件工程说到底还是一个工程问题，既然是工程问题，那必然是“实践是检验真理的唯一标准”，没有实践，再好的理论书籍都没有切身的感受，本书从趣味上来说确实胜过很多干巴巴的软件工程教材，看起来还算是比较有意思的，这几天基本上是当成小说在看，然而看完后其实并并没有多少深刻的认识，可能是缺乏实际的实践所致。感觉目前最有用的却是 关于个人技术流程 的一章，提到了很多自我提高的部分，可操作性比较强，还是很有收获的。最有意思的是最优有关创新的思考 和 团队管理，以前从来没有细致的考虑过这些问题，有点“啊哈”的感觉。就这样。

收获的不只是一点

之前在《文明之光》书评里说想看到JustPub出版发行 IT 类教材读物，这样我就能在信息世界更肆意饕餮，尽享 IT 之美，殊不知，已然有成品在架等我来取，知道消息那刻立即下单，至今读完，一路捧腹，邹老师真是笑死人不偿命 :-D。且带你再寻一遍大笑之旅。开篇有礼。“学生的行为（写完程序）是由什么驱动的？是对老师的服从，对技术的热情？是对中华民族第N次伟大复兴的热情？..."这只是邹老师第一次对所谓口号的揶揄，用初中语文逻辑的套路来回答，可谓奠定后文感情基调。注意到在后面的章节练习中还问了一个很有意思的问题，也“剧透”一下留给大家思考：团队精神和集体主义的区别？对于如何看待任务进度。老师也举抓坏蛋例子说，抓几个固然解恨，关键是得看还剩多少在台上。就如任务又花了多少时间投入固然欣慰，关键是还剩多少结题啊！是不是很佩服老师的机智呢，为什么写作的那一瞬间灵感会如此的一闪呢？再如后面的刁侃政府胡乱上4G项目、队友胡乱拍脑袋拍胸脯易惹来被拍砖头的后果、刁侃编剧“长达八年的抗日战争就要开始了...”、讽刺“大跃进”、刁侃“三峡大坝”报道及所谓专家解释、讽刺英语四六级、表达对稳定教育制度的无奈等，无不点评得妙趣横生，令人会心一笑，详不多说，点到为止。幽默的笔风是使文章煜煜生辉的品质，但它不是重点，重点当然属本书内容，闪光点一吨一吨。闪光点一：会讲故事。（活学活用该书产品上线流程）邹老师先亲身实践贴近用户，对高校软件工程教育建立认识，了解到学生学习痛点和老师授课痛点，为解决用户疼痛之处，计划打造一款产品（本书）普度众生。该书以故事的方式，通过几个典型用户（阿超果冻小飞小李）再模拟用户场景（产品从无到有流程）的形式，给我们上了一堂又一堂的软件工程“视频”课。之所以说是“视频”课，是因为故事能使人脑产生画面感，人脑对画面的理解是大于文字本身的，且印象深刻，过后不忘。本书能使读者更高效地学习软件工程知识，利用故事情节（产品从无到有流程）串联各个本来抽象又支离破碎的片段，使之浑然一体，能有条理地健全自己的软件工程知识体系。所以建议要学本课的学生以及想往产品经理方向发展的童鞋务必看看本书，尤其是后者，作为一名产品经理，首先要得有同理心，刚好借用邹老师程序员的身份来理解产品开发，既对未来“死党”的心理有了个很好的了解，又丰富了自己对产品的认知，两全其美啊。哦，不是两全其美，是三全，还是四全，可能五全？...因为后面的闪光点对想做产品经理的你亦良有益也。闪光点二：多元化思维。习惯了应试教育的单一答案论？不喜欢尝试第二种解法？想东西只能想到一面，好一点的想到两面？... ... 教育本该让我们更加了解自己，更具有思维上的思辨性，更知道如何系统的处理生活中遇到的千千万万的bug。可是，一切都让一元论毁了，由于从小到大一直在以标准答案为中心的教育体制下成长，我们大部分个体的差异性已丧失，思维趋于同处。注意，这样的群体聚集在一起很容易成就集体主义哦！也很容易为中华民族伟大复兴而奉献终身哦！但所谓的团队精神压根不是这样嘛，因为团队的每个人都具备独立的人格和思想的自由。好了，本书对一些问题的解决办法着实体现了万千世界的奇奇妙妙，尽显思维之美，多元之趣。如问：一个组（6-8人）决定徒步遍历中国大陆边界，假设硬件设备齐全，估计要几天？这本来就没有所谓的标准答案，一切都以你提出的前提进行合情推理为准，你可以像本书写到的说a.有可能完不成，团队旅行中有人可能跟少数民族少女醉入爱河而放弃；b.估算大陆边界3w米，红军一年万里长征，所以要3年；c.一年，寻求各个当地人员帮助，带领走完各个边界... ...再如模拟典型用户来了解实际需求，这就需要把自己假想为多种身份，同时进行思考，很能考验人思维的多元化性。这都是发散思维的代表，很值得学习借鉴，若是长期以这种角度看问题，脑袋就不容易被酱。闪光点三：深度挖掘。如果说闪光点二“多元化思维”提供了我们思维上的广度，那接下来我要说的闪光点是思维上的深度。常说透过现象看本质，那么究竟怎样叫透过现象看呢？且看反例漫画“用户满意吗？”里面的剪头发案例，如果一根筋酱在一种浅思维认知上，我们就不能发现客户的真实需求，进而生产出错误的产品。再看正例360装机量为何如此强大？正是它抓住了小白用户真实的需求，才赢得了安全市场。乔布斯说：“很多时候，用户并不清楚他们要什么，直到你把产品呈现到他们面前。”我想这某种意义上也是说明用户潜在需求的模糊性，如果能深度挖掘，抠出加以解决，定能实现商业利益。书中也讲到了很多抠需求的方法论，这也是它的闪光点，很可惜，没有确切实践，不能体会得更深刻。本书内容的闪光点还有许多许多，但我有些领会得不是很透彻，诸如方法论、系统化、图表法、练习与讨论等，故不再叙述。不过，我打赌这本书会是我将来做产品经理后再需阅读的好书，投入到实践中阅读起来更带劲。书里最后一章讲了个动物的故事，不禁使我回想起以前团队合作的事件，发觉自己好像该被批评的鹦鹉，只懂得叽里咕噜瞎说，却没有动手落实与操作的能力与勇气，还妄想当南郭先生滥竽充数占领团队果实。着实被打脸了一回，羞愧万分，对我启发很大，感谢邹老师的麻辣快语。不要做鹦鹉，更愿当啄木鸟除bug（臭虫）去。

《构建之法》----迷你版的《代码大全》

作者：Grey Zeng微博：@Grey_Zeng豆瓣：@Grey927博客：http://www.cnblogs.com/greyzeng/2014年读过的最有收获的一本书，同时也很荣幸接到《构建之法》的策划编辑周筠老师的邀请来写一篇对这本书的书评。如果要我用一句话来描述这本书的话，我会觉得：《构建之法》是迷你版的《代码大全》。举个简单的例子，在《代码大全》里面，关于编码方面的东西就写了好几章，这几章的描述更像一本代码规范手册，所以我对待《代码大全》用做参考手册，只是用到的时候翻到响应的地方去参考，但是《构建之法》里面对于代码规范的描述非常简明扼要，一两章的内容就说明了，实践性很强，只是不理解的是书中描述断行与空白的｛｝行，我觉得D没有明显的优势，在做Java开发两年多的时间中，用的和看到的基本都是格式C，而且我觉得格式D在debug的时候需要多按两次健 ：）。整本书对软件构建的方方面面写的很清楚，包括需求，设计，开发，测试，项目管理......实在无法一时消化，而且国内很多公司是无法做到像书中说的流程那么地全面和到位，可能也有各个公司特色的管理和开发方法。不过还是有很大的参考价值，至少对于我目前这样的状态的程序员来说，了解自己要怎么做，做的方向比要做什么更重要，本书提供了很多建议和方法，比如PSP（Person Software Process，没看这本书之前，真的没有听过PSP这个东西，惭愧），也由此了解到作为一个软件工程师，任务清单里面不仅只有要编好程这一项而已，还有计划，需求，测试，评估工作量等能力需要刻意培养。书中让我最有收获的地方在两章：第二章的个人技术和流程 以及第三章的软件工程师的成长，改变了我长期以来对我的一个职业困惑和误解，我一直觉得作为一个程序员只要学如何写代码就可以了，其他的能不了解就不用了解，算法之类的，是需要掌握的，但是实际工作中到底要怎么用上，不明白。对于职业规划一直还停留在学好算法计算机基础进谷歌微软这样大公司的naive想法层面上，虽然我一直在努力实现这一目标，但是读完以后更有针对性和方法来实现自己的目标，开始关注踏实的学习和提升自己，也提示我这样的初级软件工程师要如何让自己成长起来：技术技能（Java语言，开发平台等）的相关知识积累。问题领域的知识积累。软件思想（设计模式，软件工程等）的熟悉。职业技能（区别技术技能的沟通管理方面的能力）。实际成果（最重要的标准，如果可以量化尽量用量化的东西来说明）。所以我就知道，以后工作的过程中，要注意积累这些方面的知识，最重要的是量化自己做的东西。而且除了纯写代码的学习以外，还要关注软件工程相关的东西，同时要学会和同事上下级之间进行良好沟通的方法。同时，书中给出了职业成长的几个版本，我关注的大公司成长可能一时半会还达不到，但是，对于像我这样的一般工程师，书里也给出了一个扩展知识的进阶学习，例如：基本要求：有网页满足一般用户的查询需求基本技术：网页服务技术（ASP，PHP等）扩展技术：用户界面的设计，浏览器兼容进一步扩展：用户心理，用户交互的原则在不同设备的和不同场景下的应用。由于项目经验匮乏的关系，自己还是需要在基本要求和基本技术这里挣扎。不过相信随着项目经验不断增加，我关注的层面会慢慢高一点，到用户心理这个层面去分析。书中通过技能的反面来说明怎么样才是精通，所谓技能反面，书中说到的是解决底层次的问题。举了一个面试的例子，大学生在被要求用VIsual Studio IDE写一个程序的时候，考虑的都是“如何开始C＃命令行”，“如何定义数组”这样低层次的问题，这就是不精通，同时告诉我们如何提高自己的技能：不断练习，低层次问题变成自动操作，用时间和脑力考虑高层次问题。回到现实中来说就是：多刻意练习，夯实基础，不要让一些基础的东西绊脚石。本书一直强调做中学（Learning by Doing），看过两遍这本书，遗憾是没有完成后面的练习，下一步准备抽空把后面的练习也认真练习一下，真的需要多多的实践，才能总结出自己的东西，也才能真正理解什么是软件工程的最佳实践。作为读者对本书的一点建议：如果每章后面的链接是二维码会更好一点，这样就不用照着书来输入链接了。直接扫一扫就好。