《构建之法》的读后感10篇

　　《构建之法》是一本由邹欣著作，人民邮电出版社出版的平装图书，本书定价：49.00元，页数：396，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《构建之法》读后感(一)：《构建之法》--一本实用而给人启发的书

　　翻开书本的第一节标题，就令我觉得这是一本非常好的教材--软件=程序+软件工程。突出了软件工程的重要，软件并不代表写出达到目的的程序就可罢休了。开发过程中的可读性，可维护性，程序的架构，可扩展性等等都至关重要。

　　这本书不仅从大的方面--从单人开发到小组开发，为我们提供了道路。而且一些小的零碎的知识令我获益匪浅：Tab键与4个空格的缩进比较；对goto的理解；代码复审的重要性。

　　其中最令我印象深刻的，便是在本学期实验中老师推荐的敏捷开发Scrum方法。说实话，在使用Scrum方法开发之前，我个人真的没有料想到我们临时组成的，水平位置的团队，能够这样迅速有效的，计划明确的仅用一个多月每天少数时间，快乐编程，完成了一个从前端到后台的app。从通俗易懂的“昨天做了啥”，“今天要做啥”，“遇到什么问题”，到“燃尽图”，“Springt”。一个月走下来，感觉自己和以前丢三落四，想到什么写什么的搬砖程序员判若两人了，计划性大大提高。

　　总之，这本书整体上给我的感觉便是--实用。完全是面向实干，贴近实干的一本书。给人眼前一亮的感觉！

　　《构建之法》读后感(二)：创新的时机——学习《构建之法》

　　昨晚（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，自己也可能是那个泼冷水的人。现在觉得创新体现在我们身边更多是一种微创新，创新也可以是一种从量变到质变的过程，我们做的很多工作从一个点来看是也许单调枯燥的，但从长远来看可能也在为整个互联网的创新贡献着些许力量吧(^_^)

　　我算没白讲。

　　《构建之法》读后感(三)：所有软件工程教师与学生都值得一读的书

　　在有幸从周筠老师处获赠《构建之法》这本书之前，我就已久仰作者邹欣老师的大名了。多年以前就读过他的《移山之道》，和其他许多干巴巴地在书中罗列各种空洞概念的软件工程类书籍不同，此书别出心裁地把软件开发模型（MSF）与具体的开发工具（VSTS）相结合，介绍的还是在当时比较新颖的敏捷开发，并以故事的形式展现出来，读起饶有趣味，但又不失深度。这本书不但体现了邹老师深厚的内功，还体现了他优秀的语言组织和表达能力以及最重要的——一颗热忱的心。

　　后来又顺藤摸瓜，接触到了邹老师在博客园发布的《现代软件工程》系列教程，不禁直呼：谁要是能做他的学生，简直是太幸运了！一般来说，在各个高校中教授软件工程、项目管理、质量保证和软件测试等课程的老师，都不太会有在企业中主持中大型软件开发项目的经验，而邹老师不但有着丰富软件开发与项目管理经验，而且也有在高校中任教的经历，所以他的教程不像很多技术博客上的文章，虽然针对某个技术问题有十分详尽的解释，但是知识点却比较零散，无法组织成一个完整的体系，也不太清楚初学者们容易感到的困惑的地方到底在哪里。根据他多年以来在多个国内一流软件学院授课的经验，这套教程已经形成了一个完整的教授软件工程的体系，十分适合所有对软件工程有兴趣的学生、教师与技术人员们学习。

　　《构建之法》这本书可以看作是“现代软件工程”系列教程的扩充与总结，是我看过的软件工程书籍中少有的适合直接拿来直接作为教材的书籍（当然，本书的目的是为了让读者们真正的懂得软件工程是什么，能做什么，该怎么做，而不仅仅是应付各种考试）。本书的一开篇就分析了目前国内高校中软工课程的教学现状与师生关系（作者的微博上还有相应的吐槽系列），很多场景简直就是活生生地出现在我们的周围，我作为软件工程系的专业教师，体会更是深刻。书中提出了最理想的师生关系是“教练/学员关系”的观点，我深表赞同。反观周围的不少老师，包括自己，在教学过程中，往往采取的是书中“保姆/幼儿”的关系，巴不得把所有知识都掰碎了，咀嚼好，然后喂给学生们。虽然这种方式可以保证大部分学生都多少学到些知识，可以做到课堂内容充实，条理清楚，还能有助于学生打分的提高，但是其实大家都清楚，至少对于软件工程、计算机等工科专业来说，不实实在在写几千几万行代码，不反反复复修复各种奇怪的BUG，开发水平又怎么能提高呢，更不要说团队合作编写一个稍微像样的程序了。而这些学生中最优秀，对计算机真正拥有浓厚兴趣的那一批人，往往会主动加入老师们的实验室，形成“教练/学员”的关系。在这样的环境中，他们往往不得不去学会在压力面前如何自行解决问题，所以四年下来，他们的水平已然拉开了其他的同学们一大截，自然在就业时的竞争力也提高了许多。虽然因为各种原因，要形成这种理想的师生关系很难，但是如果每一位老师和学生一起努力，也并不是遥不可及的事情。邹老师的这本《构建之法》，就是很坚实的一步，从微博上的反馈来看，许多对软件开发有兴趣的同学，也正因为这本书，被激起了他们的兴趣与热情。

　　接下来的篇幅，邹老师就软件工程中的方方面进行了介绍。在我看来，本书最大的优点，就是内容覆盖特别全面。从基本概念到职业规划，从瀑布模型到敏捷开发，从软件测试到质量保证，从代码规范到用户体验，只要是软件开发会涉及到的方面，这本书中都涉及到了，绝对的“一站式体验”。如果是想要加深自己对于软件工程的理解的读者，又苦于没有太多的时间和精力将各种经典书籍一本本地看过来，那么从这本书入手，一定不会有错！而且作者在书中并没有太多的长篇大论，而是用一个个实例说明一个个小小的观点，读起来比较轻松。这些例子中有不少和软件工程并不直接相关，而是借用了许多社会生活中的例子，可能对于某些想要通过本书提高自己技术，或者找到现实中遇到的问题的答案的读者来看，略有失望，但是我觉得这样反而是非常beginner friendly。即使读者本人对于要这些例子说明的观点并不熟悉，但是仍然能比较容易地记住这些例子。终有一天，这位读者在碰上同样问题的时候，会先想到这个例子，然后恍然大悟：哎呀，这个例子原来是说这么一回事呀！毕竟，软件工程中“工程”的许多概念，就是借鉴了人类实践了四五千年的建筑工程的概念发展而来。

　　其次，我认为与绝大部分介绍软件工程或者项目管理的书籍非常不同的一点，就是邹老师非常强调“人”在软件开发中起到的作用。其他许多书籍，往往把重点完全放在各种开发模型、国际标准、项目流程上面，却把如何处理开发过程中人与人之间的问题一笔带过。实际上，我觉得，一个优秀的项目管理人员，真正有竞争力的地方应该是如何挑选合适的人，去做适合他做的事情，同时还能够很好地调节开发团队内部，及开发团队与外部人员之间的关系。本书用了一小半的内容来介绍“人”的问题，如“第3章——软件工程师的成长”、“第4章——两人合作”、“第5章——团队和流程”、“第9章——项目经理”、“第10章——典型用户和场景”以及“第17章——人、绩效和职业道德”。像第5章就非常详细地介绍了一个团队中常见的岗位，以及每个岗位的职责，同时还列举了理想的模式，以及不那么理想但非常常见的模式。如果是有志于从事项目管理工作的读者，读到这里就非常有价值了。还有第4章，就拿一对舞伴互相磨合的过程作为了例子，来说明开发过程中团队成员之间经常遇到的问题，相信有许多有类似经验的，尤其是经历过恋爱的读者们，看到这里，会会心一笑。绝大多数软工类书籍都强调要“加强沟通技巧”，但是如何沟通却完全没有涉及。邹老师实实在在地在书中介绍了不少“说话的艺术”，即使读者并不从事软件相关的工作，这一部分也是很有学习价值的，毕竟世界上绝大多数工作，多多少少都需要人与人之间的沟通。

　　本书还特别强调了软件测试在软件工程中的作用。在经典的软件工程教材中，软件测试往往不作为整个软件开发流程中的一个重要环节来进行介绍，导致至今还是有不少人忽视软件测试的作用。但是随着软件行业的不断发展，软件规模的不断扩大，软件测试的重要性也越来越凸显出来。由于篇幅所限，本书对于软件测试的介绍自然比不上以软件测试为专题的教材，但是基本上各种基本概念和测试类型都涉及到了，还有不少具体的例子，相信对于软件测试有兴趣的读者，可以按照各个知识点顺藤摸瓜，进一步了解各种测试。作者与时俱进，非常强调单元测试在开发中起到的作用（当然这和他在微软长期从事开发与项目管理工作是密不可分的），而且还提到了单元性能测试，这是大多数书籍所忽略的一点。按照目前的观点，单元测试已经成为衡量一个开发人员是否优秀的重要标准，所以本书在第2章——“个人技术与流程”中就花了很大的篇幅来进行介绍，而这是很多其他经典教材所忽略的。

　　还有一点，也是许多书籍所忽略的，就是本书的排版看起来十分舒服，采取了对于中文来说比较前卫的空行分段但不缩进的方式（对于经常阅读网络媒体及英文文章的人来说可能非常容易接受），中英文字体及其大小也经过精心挑选，行间距和段间距也十分合理。也许大多数读者不会特别地注意到这点，但是对于我这个有一半工作时间都是在编写各类Word与PowerPoint文档的人来说，可以深切地体会到本书编辑——也就是周筠老师的良苦用心和对于本书的精雕细刻。至少从我的经验看来，一模一样的内容，在不同的排版之下，读者阅读起来的耐心与细致程度是完全不一样的，自然读后的效果也大相径庭，周老师显然不希望排版成为这本心血之作的短板。

　　最后，邹老师在百忙的工作当中贡献出自己的业余时间，为大家奉献上这样的一本优秀的书籍，为我国的软件教育事业不遗余力地做着贡献，真是让人钦佩。相信像他这样的人会越来越多。

　　《构建之法》读后感(四)：《构建之法》——给coder带来的思考

　　作为一名软件工程的大三学生，软件工程这门课终究还是要学的。说实话，我很害怕这种牵涉范围很广的课。软件工程四个庞大的字眼，乍一看什么都有，可是一学期的课都上完了，我却感觉自己学到的内容很空洞。上课时，老师强调了很多遍让我们去看《构建之法》这本书。抱着无奈又疑惑的心情，我翻开了这本书。

　　书的内容很吸引人，在看我们的教材《软件工程 面向对象和传统的方法》时，整个人有些迷糊。究其原因，除了因为书中包含大篇幅概念论述以外，书的内容也很枯燥乏味。因为书的内容看不懂，所以很着急，一着急就想着往后把它赶紧看完，从而显得内心更加急躁。表面上看其实我是在看书，可实际上那段时间脑子里只是一闪而过许多概念，什么都没有看进去。在接触《构建之法》后，我看书的心态从浮躁变得平和。因为这本书的语言很幽默，而且通俗易懂。作者使用风趣的对话和幽默的口吻揭露了概念的本质，从而使读者理解某个概念的真正含义。这比”一大堆概念从脑子一闪而过“有用的多。

　　在做到不让读者枯燥这一点后，这本书的覆盖面相比于我们的教材，在关键面上也是一点都没落下。在《构建之法》的章节中可以看到，书涵盖的知识点齐全。除了重要的概念讲解，书本中还有很多关于该概念在实际研发过程中的应用和该概念的引申。引申的内容包括软件工程师的成长、如何当好一名PM、IT行业的创新与职业道德等等。在软件工程师的成长方面，我印象最深的是关于团队那一章节的讲解。该章节阐述了各种团队模式（其中包含一些常见的却错误的团队模式），指出了一个优秀的团队应当具备怎样的素质。在学生时代，我们组成的团队大部分都是”业余剧团模式“。即在上一个团队，你还是后台开发，但在下一次组队时，你可能就变成了前端设计甚至是PM。作者没有明确地指出这种团队的错误之处，但在后续几种模式的介绍中，我们发现这种模式没法很好地做到让成员各司其职。什么都会的情形下很可能演变成什么都不会。这一段内容让我对”写代码“之外的领域进行了大致的了解，也让我对自己所处的团队产生了思考。

　　对于大部分软工专业的学生而言，现阶段的我们处在一种”写了再改“的模式里。即在实现一个系统之前，我们思考的时间很少甚至可能没有。而”盲目地代码，发现错误，急忙修改“的情形却是经常出现。我抱着”不能让软件工程挂科“的心态拾起了《构建之法》这本书，却在书里收获了许多思考。仿佛有个声音在耳边说：”你是要当一个搬砖程序员，还是要当一个独当一面的软件工程师呢？“ 我相信这本书也能给你们带来思考和收获。

　　《构建之法》读后感(五)：花费了大量的精力

　　第一，理论与实践并重。本书介绍了软件工程的相关概念，如：软件工程、单元测试、软件开发流程、敏捷开发、软件需求、用户体验、软件测试、质量保障等。在介绍这些基本概念的同时，作者也全面地诠释了它们在实际的研发工作中是如何表现的，它们又是如何与每个开发和测试人员息息相关的。在介绍这些概念的时候，作者多用举例的形式来说明，这样也使得大家更加的容易理解。

　　第二，文笔优美，图文并茂。作者为了让读者在阅读本书的时候不感觉到枯燥，可谓是花费了大量的精力。首先，每一个文字段的内容都不是很多，防止读者对着一大页文字发呆而失去了继续读下去的勇气；其次，本书包含了很多有趣的图片，读者可以通过这些图片加深对相关概念的理解；再次，书中内容层次分明，作者将很多知识点通过几个小点顺序列出，让读者阅读和理解起来更加的容易。

　　第三，语言幽默、诙谐。软件工程里面的概念比较的枯燥和单调，作者也深知这一点。因此，在本书的很多地方，作者都用十分幽默的方式来讲述。例如，书中用“阿超”、“国栋”、“小飞”、“小李”等角色之间的对话来揭示一个概念的本质。这让读者觉得十分的“接地气”，同时通过他们之间风趣的对话又加快了对相关概念的理解。个人觉得，这是本书最大的特色。

　　《构建之法》读后感(六)：《构建之法----现代软件工程》书评----软件工程学习新方法

　　有幸选择来到中科大软件学院，有幸学到软件工程这门课程，有幸读到《构建之法》这个本，在读这本书之前，在网上也看了很多关于这本书的报导以及介绍，评价不错，再加上软件工程老师的推荐，所以就买了这本书读了读。

　　开始读这本书，最大的感受的感受就是软件工程原来是可以这么学的，以前学习软件工程的课程的时候，总是感觉这门课程及其枯燥无味，总是在说太多的理论，很少 会涉及到实践，甚至根本就是没有实践这个环节，所以学习很无聊，但是研究生阶段读到这本书，真的是全新的感受，首先，不仅仅只是在说理论了，加入了很多实 践的东西，而且还可以在网上可以与其他人进行交流学习心得。

　　开篇作者就说了“软件 = 程序 +软件工程”，以前写软件或者说程序，就只是写程序，最多会考虑到数据结构的知识，很少会用到软件工程，但是随着学习的深入，代码量的累积，如果还是和以 前一样只是关心程序只要是可用的，实际可运行的，那么就没有意义了，这样的程序写出来也是没有价值的，首先，软件工程不仅仅就只是涉及到计算机或者软件方 面的知识，相反，软件工程涉及了很对其他学科的知识，比如：管理学、数学、工业设计等等学科，一个合格的软件开发人员如果只是懂得怎样去写程序，那么嗨仅 仅只是初级阶段，更高级的应该是从一个更加高级的层面上去考虑更多的东西，如整个软件的架构。

　　整本书从实际软件开发的各个阶段出发，详细地分析了软件工程的各个环节，如：需求分析、设计实现、用户体验、软件测试已经最后的发布等等。

　　首 先，说说代码风格，一个良好的代码风格规范是一个软件开发人员最起码的要求，即使程序写得是多么地出色，具有广阔的市场应用前景，但是如果背后是混乱不堪 的代码，那么就会对这个软件日后产生不少的负面的影响，特别是在后期的维护以及版本的迭代上，不规范的代码对于日后的维护人员来说，简直就是噩梦，以至于 最后实在是没办法了，只好是全部推倒重写，当然这个最坏的打算了，所以好的代码规范是多么地重要，特别是在日后开发具有商业价值的项目时，或者是在一个软件项目的团队里工作，代码规范相当重要。

　　结对编程，对我来说这是一个很有意思的新词，尽管这个词语的出现可以追溯到上世纪，以前不管我们是自己独立地进行项目的开发还是几个人组成一个小团队进行开 发，最基础的还是需要每个人写代码（独立地），但是，在结对编程的模式下，是由开发人员肩并肩、平等地、互补地进行开发，无论是设计、分析、编码、测试。 结对编程最大的好处就是可以使得实际开发出来的代码不断地处于“复审”的过程中，可以及时发现问题，可以及时解决问题，可以极大地避免将问题带到最后的测 试或者是发布阶段。

　　敏捷（Agile）开发，也是一个很早就提出来的技术解决方案，敏捷是一系列的价值观和方法论的集合，前人通过 不断地实践，总结出来的开发方法及开发过程，对我们现在的开发有很强的指导意义，敏捷开发的原则很多，其中印象最深的就是“经常发布可用的软件，发布间隔 可以从几周到几个月，能短则短”，以及“可用的软件是衡量项目进展的主要指标”，我的理解是敏捷开发强调的是“小而美”，定期地完成一个小版本的软件项 目，比只是最终发布产品要好的多，这样也有利于产品的迭代，敏捷中的Scrum方法论，看起来简直就是无与伦比：要做什么->当前要解决什么 ->冲刺->得到一个增量版本。分阶段地不断递进地解决问题，但是敏捷也有很多的弊端，敏捷宣言不是圣旨，不必完全尊从，就像是Scrum， 实际执行的时候也不是看上去那么美好，在一个复杂的项目中，往往不能带给团队更多的惊喜，所以，敏捷慎用。

　　具体到软件的设计与实现，从软件工程的角度来看，并不是一上来就是进行实际的编码，而是进行诸如需求分析、写设计文档等相关的编码前的相关准备工作，第一步就是写设计文档（Design Document），然后针对这个设计文档进行团队内部的复审，然后再进行开发，如果在编码的过程中还会遇到一些意想不到的问题的时候,和PM进行交流，写完代码后，按照原先的设计文档和代码指南进行自我复审，重构代码；接下来写单元测试，如果可以，那么可以发布一个简单的小程序，在少数用户的范围内使用，方便及时地发现问题。好像到了这里，如果没有什么大的架构或者程序上的问题的话，那么一个相对比较完整的软件版本就已经实现了，但是在软件工程中还有一个问题往往会被忽略，那就是“用户体验”，我们都知道一个界面美观的设计有的时候也会给一个软件增色不少，使得用户的第一个直观的感受就是这个界面首先是吸引人的，做好一个用户体验，首先需要明确这个软件的受众或者说面向的是什么样的群体对象，根据具体的群体是喜好进行针对性的设计，才能更好地满足用户。

　　最后来说说软件测试，不仅仅是这本书中，几乎所有的介绍测试相关的书籍，都对测试讲得很多很多，说到测试，大家最熟悉的就是黑盒、白盒测试等，要写好一个不错的测试，首先要有一个好的测试方法，如：Unit Test、Function Test、Structure Test、System Test等等，测试方法多种多样，关键是怎样找出合适的测试方法最好地完成测试，怎样写一个Test Case？这个好像很麻烦，你必须首先知道并熟悉这个需求，要写出一个完整的测试过程，要考虑好测试的边界值的选取，极端情况下程序的健壮性，所以写好一个测试不简单。

　　学好软件工程也是不简单的。

　　《构建之法》读后感(七)：等待也许是国内最好的软件工程教材

　　#Comment_Alpha timestamp = 20140830-05:00am

　　邹老师的博客有一段时间不更新了，原来是在潜心着书啊！

　　以上是满满的期待。(☆_☆)/~~

　　先占坑，等到手后再写具体的评论。

　　《构建之法》读后感(八)：循序渐进，步步为营

　　编程是艺术，开发是工程

　　比起一门编程语言，软件工程的入门过程，要难得多。盖因一门语言，其语法、关键字、系统库和常用工具，总是确定而有限的。

　　而软件工程，作为工程学的一个门类，它肩负着在软件开发的过程中，将种种条件确定下来，将资源安排妥当，使工作过程确定清晰，产出稳定可靠的责任。

　　这其中的微妙和复杂，往往在经典的教材中也不能充分表达。其中大量与人的协作，与时间的较量，其经验和体会，都是要在实践中才能慢慢积累起来。

　　这就使得软件工程课程，在学习过程中，常常处于一个尴尬的位置。一方面我们都会宣称它非常重要，另一方面，我们却很难从中得到收益。一方面我们都反对形式主义的软件工程，另一方面因为难以落实，使得我们最终总是在实践中流于形式。

　　软件工程，作为软件开发的一个基础的知识领域，它的学习过程，也迫切需要一个启动的支点。

　　在这样的背景下，得到邹欣老师的《构建之法》，对我来说是非常惊喜的事情。这本书很好的解决的这个知识领域“从零到一”的问题。我数了数手头十来本软件工程方方面面的读物，还是觉得，如果你是一个在校生，刚刚开始学习软件工程；或者你是一个刚刚走上工作岗位的程序员，迷惘于如何在形式化的团队开发规程和自负的才华之间找到平衡；甚至你是一个刚刚走上管理岗位的技术领导，第一次从“软件工程的受害者”成为实施者，急于完成角色转换，走上人生巅峰。你都是这本书潜在的目标读者。

　　uild To Learn 到 Build To Win

　　uild To Win 是 《构建之法》一书的英文名。这本书很好的阐述了如何逐步改进软件开发过程，邹欣老师将不同的阶段和形态形象的区分为：

　　• Build To Learn：开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。

　　• Build To Show：为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面。

　　• Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。

　　• Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现，技术突破最好的试金石。这是我在研究院之外的十余年中做的最多的项目类型，也是这本书的英文名字。

　　书中有针对性的设计了一个十六周的课表，可以供学校授课时使用，也可以供个人学习者或企业团队实践中估算学习用时。这本书是作者多年在高校实际进行软件工程教学——我们这些同行，都很喜欢看邹欣老师在微博上与学生的互动——的经验总结，可以作为一门课程，在一个学期内完成。独立的学习者，也可以遵循类似的时间线，即从环境和知识准备（代码仓库－测试工具等）到项目规划和组织（由个人软件开发过程开始，引入结对和团队项目形态，以及相关的项目管理和测试工具），再到质量管理、发布、跟踪维护、总结和改进等，循序渐进。

　　和我以前阅读的其他软件工程书籍一个很大的区别在于，作为教材，《构建之法》的启动过程非常的平滑。有一些读物是按照经典的瀑布模型，从需求分析，概要设计开始——是的，我教过这样的教材。而本书则是从一个微型项目最有可能的起步过程开始：组建团队、准备工具。

　　从经验来讲，版本管理工具和单元测试工具，也确实是非常适合上手的，这两种工具见效快，学习相对简单，一旦学会，学习者会迅速体验到工程化开发带来的好处：可回溯、可控制、可管理。

　　在其后，大量的章节用于讨论协作、项目跟踪和控制等环节，书中基本跳过了关于UML的讨论，也没有细致的讨论一个完整的软件项目可能会用到的所有技术。这种取舍非常有必要，也把握的很好。如果深入编程语言或UML这样的方向讨论，会迅速脱离整个软件工程的大范畴，陷入某个局部或者范畴外的某处，难以自拔。

　　即使对于学校外的学习者，也不应该将这本书视为完整的学习一个项目开发过程的指导，而应该按照这个过程去执行一个自己选择的项目来学习。这样的设定保证了全书的内容专注于软件工程本身的学习，不至于失之繁冗，也可以让学习者从一个技术上对自己比较有利的项目。这个项目所需的技术对于读者应该尽可能比较熟悉，尽量不需要学习太多。毕竟这里我们要学习的是软件工程，而不是编程技术。

　　书中一个很有意思的地方在于，每一个假设的情景都很活泼形象。事实上我多年以前读过的另一本微软出版的技术书籍，就曾经着重介绍过故事卡片在微软开发过程中的使用。微软的优秀团队很擅长使用这个工具。从我的经验来讲，故事卡也是一个很实用的软件工程手段。它可以作为需求分析的草稿，也可以用来引导思考，建立用例图和概要设计等。即使不将故事卡作为正规工具的团队，个人在工作过程中，建立故事卡也可以很有效的帮助自己。当然有些朋友可能在这个过程中会遇到困难，我的职业经历中，确实比较少见到擅长书写，文笔足够熟练的建立故事卡的同行。但是其实这项技能是可以练习的。只要有心，经过一段时间的训练和联系，普通的工程师也可以写出质量稳定的故事和情景设计。而本书中的情景设计，也可以印证作者对这一工具的运用是比较娴熟的，值得读者学习。

　　《构建之法》读后感(九)：构建之法，运用之妙，存乎一心

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

　　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. 题外话

　　从瀚哥开始，每届新同学都会问我一个问题：老师，你为什么这么关心项目的结果。

　　我知道，言下之意也包括，你为什么不更关心对我们的教学。

　　因为，我们以真实工程作为教学的工具。这是因为，没有人乐意做假的工程，仅仅为了学习目前还不确定是否有效的知识。这意味着，真实的工程必须存在，才可能用于教学，而真实工程不同于假的实验的是，如果它失败一次，以后就不会再有真实的工程了。也就不会再有真实的工程用于教学。

　　训练猎人的时候，要求师傅把猎物捆个结实，为了防止学徒害怕或怜悯它挣扎，还要给猎物打上麻醉剂，再给学徒穿上防磕碰的盔甲防溅血的服装，你为什么不再戴上护心镜和老花镜躲到绣楼里去。

　　所以，当你要求或接受真实工程训练的时候，你就给了我你的承诺。我把武器交给你，你要像我保护你那样保护你。无论这个承诺有多么的小，一旦你说出来，它就是我的，不再属于你；我有权放弃我的权利，你没有权利背弃你的诺言。

　　你，你们，背弃对我的诺言，我非常失望。我知道你并不在乎我失望与否，我也并不在乎你给我造成的损失，我在乎的是我所面对的我所关心的，是这样的世界。如果承诺不可信赖，未来还有什么可以期待。

　　------------------------------------------

　　博客会手工同步到以下地址：

　　《构建之法》读后感(十)：《构建之法》读后感

　　作为一名软件工程专业的大三学生，因为课程所需有幸拜读了这本《构建之法》，以下是我读过这本书之后一些感受。 这本书首先给我的感受就是通俗易懂，可读性强，如果是非软件工程的学生阅读这本书也能读得进去，看得懂。比如第一章，用程序员阿超做例子，说明了什么是“软件”什么是“程序”，而在另外的教材中就不会这样讲解。 在阅读这本书的过程中，我同时在带入自己过去的项目经历，发现了很多以前没有做好的工作，比如没有好的代码规范导致和队友的合作有障碍。一个优秀的项目不仅仅是代码写得好就可以的，我以后还会时时阅读这本书，时时反思自己。 但是这本书也不是完全没有缺点，因为它的目录放在前言和“给任课老师和助教的建议”后面，每个章小结的后面也没有标注页码，当我想把它作为工具书查找资料时，就不是太容易一下子找到我想要的东西。