《构建之法》经典读后感10篇

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

　　《构建之法》读后感(一)：说实话，难得的一本好书

本人今年大三，软件工程专业，学校是在大二下开始教授软件工程这门课的。当时采用的教材是机械工业出版社的一本软件工程，根据国外翻译进来的，很厚（跟Java编程思想差不多，书皮也差不多），据说很经典。不过说实话，实在看不懂，只记得什么瀑布流程，敏捷开发，螺旋模型，以及测试很重要。老师一遍遍的跟我们强调软件工程的重要性，但在整个课程的学习过程中，只背了些晦涩难懂的概念，期末随便画了些图，意思意思就过去了。到头来想想，又浪费了半年的时间，什么都没学到手。机缘巧合之下，在微博上看到有人推荐这本书，又搜索了下，似乎很不错，就在京东上买了本。刚开始觉得这书有点薄，有点小失望，但看了几章之后，不敢说瞬间打通任督二脉，但真的很让我着迷。作者的思路很清晰，文字也很有趣，让人欲罢不能。目前只看了前面5章，但我已经从中学到了很多，作者关于软件开发的流程介绍以及程序员生涯的理解，真的让我学到了很多。具体的不多加评论，我看的还比较少，但已经看到的这部分就已经让我觉得这本书物超所值。另外，关于本书的一些不足，我觉得在书中的注释方面做的不够好，每章的注释不够明显，而且关于注释的解答都放在章节的最后面，让人在阅读的时候感觉很不方便，希望以后能有所改善。

　　《构建之法》读后感(二)：匠心独运，干货满满

一年半前准备实习面试，曾寻觅到邹欣老师博客上“现代软件工程”讲义来突击学习PM相关章节，而这次《构建之法》出版，通读全书更是受益匪浅。
从一个初入职场的PM的角度来看，这本书是走入PM大门不可或缺的读物：其项目管理和产品相关章节既有宏观的介绍，又可运用于实战。而作为PM去看开发/测试的章节，则能进一步理解工程师们的工作和职责。通读下来，各个不可或缺的“模块”构建起软件工程的整体。反复品读书中案例，再思考现实中的工作和身边的产品，又教人有更多感悟。
对我而言读书的目的无非是“学东西”或“找乐子”。这两个目的在通俗意义上是难以并存的：轻轻松松看小说神马的最开心了，而抱着教材死啃则真是苦不堪言（学霸学神除外）。
《构建之法》却是本可以让人边学习边找乐子的优质教材：接地气的实战经验，与时俱进的产品案例，语言生动、寓教于乐，还附赠吐槽小技能，其犀利诙谐让人不禁捧书傻笑。而这种特色，正可让人愉快地接受理解知识且印象深刻，想必这位作者的授课教学也必是循循善诱的:)
虽说“内容重于形式”，但为提升用户体验、让阅读学习变得更更愉快，有建议如下：
① 格式建议：
1) 对章节分“篇”：这本书囊括广泛，开发、项目流程、交互设计、软件测试、管理，都有所涉及。将相关的几章归为一“篇”后，既可方便读者有针对性地阅读，同时在阅读过程中（譬如从第4章结对编程看到第5章团队和流程时）也不会因跳转突兀而感觉奇怪。
2) 每章末增加总结：在顺畅又愉快地通读完一章后，若能看到几句话的总结重述本章的重点，便可以及时温故。也与章开篇大纲、章末思考题相呼应。
3) 部分段落增加高亮/加粗的使用。这本书的知识点是和故事融合在一起，如果将概念或思想相关的字句都加粗，则可避免在快速浏览或复习时有所遗漏。同时这也将是备考学生们的福音。
②部分章节结构改进：
所涉案例和概念们在涉猎广泛的同时，也应有所类别划分以及侧重点，若有作者的综合评述则更佳。具体如：
1) 第12章（用户体验）：初次给我的阅读体验是，似乎每段都有所收获，读下来也很顺畅，结构却有些乱，尤其在看到某些部分联想到先前读过的书时难免觉得没“到位”。——该问题是难免的。毕竟是将可以写上好多本书的主题浓缩到一章内。
（既然类似文献综述的概述与本书风格有违）本书在介绍用户体验的一章就应另辟蹊径，更多体现与软件工程相关的流程，而不仅仅是具体的体验设计案例：可将12.2与12.1调换顺序：先叙述“用户体验设计的步骤”，随后再以各种案例锦上添花。而最好也能对设计步骤进行拓展。
此外，对于12.3中的7条评价标准，若要实践难免需硬背才能够记全那些标准。而其实各出处的标准都很精辟却又有些重合，建议分一下层次类别，就可以将其总结到一起~（譬如：Constraints, Affordances, Natural Mapping, Visibility and Feedbacks 相关都可归到*提高易用性*一类，此外考虑各种用户及操作情况的*周全完整的流程设计*，及error strategy相关的*风险/错误应对措施*均可作为分类。）这样不论是在评价体验设计时都会有章可循。
2) 第5章（团队和流程）13章（软件测试）：其中都涉及到较多定义。在读过后，难免会一时迷糊这段都讲了什么、该如何应用。因此适当地加入对比分析和作者总结，将使本书将不仅具备课堂上娓娓道来幽默风趣的生动带入感，更兼具老师的对比分析和复习指点，学习的体验和效率将大为提升。
比如5.2，虽已清楚地介绍各种团队模式的特点和优劣并有举例，但好坏混在一起，不知道哪种模式才是被推崇、应选择的。同样地，13.2中的各种软件测试方法，在概念叙述后也可以进行综合的总结。此外在随后的13.3实战流程中，也建以将测试方法的选用融合其中，从而体现其在实战中的应用和价值。这种有一定重复性的总结可以助力于温故而知新的过程。
最后，不要被高大上的书名和高冷的封面误导哦~
这真的是本匠心独运且干货(fucking good)满满的书！

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

编程是艺术，开发是工程
比起一门编程语言，软件工程的入门过程，要难得多。盖因一门语言，其语法、关键字、系统库和常用工具，总是确定而有限的。
而软件工程，作为工程学的一个门类，它肩负着在软件开发的过程中，将种种条件确定下来，将资源安排妥当，使工作过程确定清晰，产出稳定可靠的责任。
这其中的微妙和复杂，往往在经典的教材中也不能充分表达。其中大量与人的协作，与时间的较量，其经验和体会，都是要在实践中才能慢慢积累起来。
这就使得软件工程课程，在学习过程中，常常处于一个尴尬的位置。一方面我们都会宣称它非常重要，另一方面，我们却很难从中得到收益。一方面我们都反对形式主义的软件工程，另一方面因为难以落实，使得我们最终总是在实践中流于形式。
软件工程，作为软件开发的一个基础的知识领域，它的学习过程，也迫切需要一个启动的支点。
在这样的背景下，得到邹欣老师的《构建之法》，对我来说是非常惊喜的事情。这本书很好的解决的这个知识领域“从零到一”的问题。我数了数手头十来本软件工程方方面面的读物，还是觉得，如果你是一个在校生，刚刚开始学习软件工程；或者你是一个刚刚走上工作岗位的程序员，迷惘于如何在形式化的团队开发规程和自负的才华之间找到平衡；甚至你是一个刚刚走上管理岗位的技术领导，第一次从“软件工程的受害者”成为实施者，急于完成角色转换，走上人生巅峰。你都是这本书潜在的目标读者。
Build To Learn 到 Build To Win
Build To Win 是 《构建之法》一书的英文名。这本书很好的阐述了如何逐步改进软件开发过程，邹欣老师将不同的阶段和形态形象的区分为：
• Build To Learn：开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。
• Build To Show：为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面。
• Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。
• Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现，技术突破最好的试金石。这是我在研究院之外的十余年中做的最多的项目类型，也是这本书的英文名字。
书中有针对性的设计了一个十六周的课表，可以供学校授课时使用，也可以供个人学习者或企业团队实践中估算学习用时。这本书是作者多年在高校实际进行软件工程教学——我们这些同行，都很喜欢看邹欣老师在微博上与学生的互动——的经验总结，可以作为一门课程，在一个学期内完成。独立的学习者，也可以遵循类似的时间线，即从环境和知识准备（代码仓库－测试工具等）到项目规划和组织（由个人软件开发过程开始，引入结对和团队项目形态，以及相关的项目管理和测试工具），再到质量管理、发布、跟踪维护、总结和改进等，循序渐进。
和我以前阅读的其他软件工程书籍一个很大的区别在于，作为教材，《构建之法》的启动过程非常的平滑。有一些读物是按照经典的瀑布模型，从需求分析，概要设计开始——是的，我教过这样的教材。而本书则是从一个微型项目最有可能的起步过程开始：组建团队、准备工具。
从经验来讲，版本管理工具和单元测试工具，也确实是非常适合上手的，这两种工具见效快，学习相对简单，一旦学会，学习者会迅速体验到工程化开发带来的好处：可回溯、可控制、可管理。
在其后，大量的章节用于讨论协作、项目跟踪和控制等环节，书中基本跳过了关于UML的讨论，也没有细致的讨论一个完整的软件项目可能会用到的所有技术。这种取舍非常有必要，也把握的很好。如果深入编程语言或UML这样的方向讨论，会迅速脱离整个软件工程的大范畴，陷入某个局部或者范畴外的某处，难以自拔。
即使对于学校外的学习者，也不应该将这本书视为完整的学习一个项目开发过程的指导，而应该按照这个过程去执行一个自己选择的项目来学习。这样的设定保证了全书的内容专注于软件工程本身的学习，不至于失之繁冗，也可以让学习者从一个技术上对自己比较有利的项目。这个项目所需的技术对于读者应该尽可能比较熟悉，尽量不需要学习太多。毕竟这里我们要学习的是软件工程，而不是编程技术。
书中一个很有意思的地方在于，每一个假设的情景都很活泼形象。事实上我多年以前读过的另一本微软出版的技术书籍，就曾经着重介绍过故事卡片在微软开发过程中的使用。微软的优秀团队很擅长使用这个工具。从我的经验来讲，故事卡也是一个很实用的软件工程手段。它可以作为需求分析的草稿，也可以用来引导思考，建立用例图和概要设计等。即使不将故事卡作为正规工具的团队，个人在工作过程中，建立故事卡也可以很有效的帮助自己。当然有些朋友可能在这个过程中会遇到困难，我的职业经历中，确实比较少见到擅长书写，文笔足够熟练的建立故事卡的同行。但是其实这项技能是可以练习的。只要有心，经过一段时间的训练和联系，普通的工程师也可以写出质量稳定的故事和情景设计。而本书中的情景设计，也可以印证作者对这一工具的运用是比较娴熟的，值得读者学习。

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

《构建之法》刚面市不就就买了纸质版，后来出了多看版后也第一时间购买了电子版。这也是第一本同时购买了纸板和电子版的技术书籍。周筠老师在微博上催过我几次书评，无奈年后一直忙于公司产品的研发，直到最近才看完，进度很缓慢。
《构建之法》是一本讲软件工程的书，但又不是一本传统的软件工程的书。先说下本书的几个特点：
1、接地气，不枯燥，有很多生动的例子；
2、沿用了《移山之道》里面的人物虚拟场景，对于之前看过《移山之道》的朋友来说会觉得特别熟悉；
3、不按常理出牌，以独特的视角让阅读者能全面了解企业软件开发的过程。
记忆中大学是软件工程课上每次都是老师念PPT，一学期结束唯一记住了的就是瀑布模型。没有项目实践、没有编码。除了瀑布模型里的那几个阶段的概念，还是不知道软件工程到底有什么用。所以当看到《构建之法》这本书的时候，有种相见恨晚的感觉。
在本书的前言部分的课程安排建议、师生关系的比喻以及八条建议直接吸引我将该书看下去。
1、课程安排不仅可以对老师和助教提供参考，其中提到的很多在实际软件开发中的工具和方法论，对学生也有很大的参考价值。举个例子，最近半年面试了很多应届生，大多都没有用过源码管理工具，知道Git或使用过Github的更是寥寥无几。我想他们如果有幸读到这本书的话，肯定也会有相见恨晚的感觉；
2、师生关系的比喻最终说明一个道理，学习要有主观能动性，记得小时候母亲经常教导我，要将老师“要我学”变成我们自己“我要学”，这样才能提高成绩；
3、八条建议是对老师和助教的建议，我倒觉得学生从中也能反推自己应该如何来进行学习。
我理解的软件工程是：利用合适的工具、手段、方法快速、高质量地完成软件开发的过程。而我们学过的软件工程都是自顶向下的，从需求分析、设计、开发、测试到最后的交付。当年在学习软件工程这门课的时候，根本就没有任何编程经验，所以那些理论知识很难理解的很透彻。
在《构建之法》中恰恰是按照最容易理解的步骤，从开发测试、开发人员成长、团队管理一直讲到需求分析、设计以及用户体验等。先让我们知道开发为何物，每个人都有了编码实践的经验后再一步步到需求分析、设计就会理解的更透彻。
一本好书除了本身的内容外，还需要能引发读者思考，能够学习到更多的扩展知识。记得之前网上有人回答怎样找到一本好的技术书时说过：
“在一本经典的书籍上找找所参考的书籍或引用的书籍，大致都还不错。”
我认为还是挺有道理的。《构建之法》的正文以及练习与讨论中有大量有价值的引用，这些内容可以让我们了解更多更广的知识，练习中大量的习题如果都能够独立思考并想办法解决的话，对我们的实际动手能力会有很大提升。
总之，这是一本值得反复阅读的技术书、一本可以教会我们怎样去做好一名合格软件工程师的书、一本无论是对在校学生还是一线软件工程师都会受益的书、一本很适合阅读电子版的书。本书内容很多，我也只是选了几个我认为还比较重要的视角进行了阐述，希望对您有所帮助。

　　《构建之法》读后感(七)：可否把邹欣老师这个人也给“出版”了？

“软件工程是计算机专业里很难讲的课程之一。面对在软件开发方面经验很少的学生，邹欣老师通过丰富生动的故事和隐喻帮助学生建立软件工程的思维习惯，通过严格扎实的动手训练与考核帮助学生总结归纳自己的“最佳实践经验”。读这本书，软件工程课不再是一门枯燥沉闷的“文科类哲学课”，变得出乎意料的生动有趣。这是IT学生的幸运和福气，也为从事软件工程教学的高校教师指明了一条全新的教学之道。”
------------------------------
我与邹欣老师没有见过面。最初是在微博上关注了他，看他对软件工程的诸多想法。最有趣的是，经常看到他搜索微博上各种关于软件工程课的吐槽（大多来自于上这门课的各校学生），他时不时转发几条，加上些揶揄的话，跟学生一起“抱怨”他们的软件工程老师。说实话，邹老师的有些揶揄经常让我浑身不自在，因为自己恰恰也曾表现过学生们所抱怨的那些“软件工程现象”。
不自在也罢，有趣也好，一名大学教师终究该时刻正视自己身上的不足。于是关注邹老师的个人博客，逐篇看他在北航等学校所实践过的软件工程教学经验总结。看多了，被他的授课思路所吸引，渐渐开始在自己的课程里引用邹老师的某些观点和材料，把哲学化的软件工程讲义渐渐变得生动起来。从这一点来说，我也算是邹老师的学生之一了。
另一个交集是，2012年冬天（抑或是2013年初春），受微软亚洲研究院大学合作部门的邀请，我本计划去MSR现场旁听邹老师对某高校学生们软件工程实践项目的结题答辩，这是MSR对邹老师的软件工程教学思路在各高校的推广的一部分。可惜的是，因为其他事情的耽误没有成行，但还是派了我的两位从事软件工程教学的同事到北京去。他们回来之后，连连感叹被“洗脑”，大呼在自己的课程里进行“改革”的必要。
我个人从2007年开始承担计算机系本科生软件工程课的教学工作。当年从退休的前辈手里接过这门课，颇为意气风发。最初2-3年热情高涨，一直遵循着“绪论-软件开发过程与项目管理-需求分析-软件设计-软件测试-软件维护-新进展”这样的传统思路在授课，没觉得有什么不妥，也自认为学生们的学习效果不差。2、3年之后，面对教室里随着授课进度而不断下降的听课人数和他们日渐消减的热情，猛然警觉起来，愈发觉得这条路子不对。这才明白，为何学院里的诸多大牌教授居然不愿意上这门重要的计算机专业课程。
不对在哪儿？难在哪儿？
软件工程不是理论课，是实践课。没有公式，没有定理，只有方法，只有“最佳实践”。学生们已经习惯了学公式和定理，但这里给出的方法，丝毫没办法在理论层面证明，只能在实践中不断应用和练习，才能理解并体验到它们的好处，把它们死背下来不起任何作用。面对在软件开发方面经验很少的学生，你把这些经验性的方法讲给他们听，丝毫无法说服他们。课堂上太多的“经验”，让这门课变成了一门枯燥沉闷的“文科类哲学课”。本来学生们对政治课哲学课就提不起兴趣，老师再照本宣科，他们自然就选择逃掉，能坐在你的课堂里玩手机或是睡觉，那已经太给你面子了。
这样一来，虽然授课教师已经很努力，但学生们给出的评教成绩始终在中游徘徊。自我安慰说：“这不是我们水平差，是这门课太难讲叻。”
是这样吗？
直到看到邹老师的实践以及他所总结出的诸篇blog（这些正是本书的前身），才恍然大悟该如何讲授软件工程课。
面对在软件开发方面经验很少的学生，邹老师通过丰富生动的故事和隐喻帮助学生建立软件工程的思维习惯，通过严格扎实的动手训练与考核帮助学生总结归纳自己的最佳实践经验。软件工程课不再是一门枯燥沉闷的“文科类哲学课”，变得出乎意料的生动有趣。他会要求学生以实际软件产业内的真实软件开发团队配合和管理方式开展自己的软件项目，要开发真实的软件并在互联网上发布，要走出去找到真实的“用户”，要倾听用户的真实反馈。一个个来自他切身实践的“经验”以故事的形式呈现在学生面前，引导学生“做中学”（learning by doing）而不是“学后做”（doing after learning），靠自己“做”的过程中的经验和教训总结而不是靠老师的宣讲灌输而形成适合每个人的特有的“最佳实践”。
这两年，邹老师的很多想法已经被融合进了我们的课程里。比如说，我们改变了授课内容的次序，从学生们最感兴趣的写代码入手，逐步引导他们思考对代码书写规范的思考、对代码性能分析与优化的习惯培养；再逐步扩大软件的规模与复杂度，引入软件架构的思想，让学生持续书写代码和学习新的开发技术；刻意强调真实用户的重要性，引导真实用户为学生们提出各式各样需求的变更，在辅之以考核时间上的压力，让他们自然接受结对编程、快速迭代、持续集成等敏捷开发的思想；当学生们发现靠自己掌握的现有技术实在无法“敏捷”起来的时候，再引导他们考虑设计思维，考虑需求，考虑是否该引入这样那样的建模。如此等等，这样一步步下来，下一阶段要学习和训练的知识与技术，恰恰好就是学生们在上一阶段里所遇到的无法解决的困境，于是自然而然勾起了他们继续往下走的兴趣。我们把将近30%的课堂时间用于课堂讨论，而不再是传统的“老师讲、学生听”。
所以，当看到邹老师终于愿意整理成书并且在9月份付梓，我马上在本学期的第一堂课上真切的向学生们推荐了这本书。可以借鉴邹老师的很多想法和做法，但因为所处的高校环境完全不同于邹老师所在的MSR，我们的师生都需要做很多方面的改进才能跟上这本书里的软件工程“先进性”。但至少，这是IT学生的幸运和福气，也为从事软件工程教学的高校教师指明了一条全新的教学之道。
个人认为，若想成为一名好的软件工程的老师，应具备以下的条件：
（1）有丰富的软件研发经验，形成了自己的“最佳实践经验”；
（2）会讲故事，能将自己的“最佳实践”以生动有趣的故事的形式讲出来；
（3）跟学生们一起摸爬滚打，扮演“健身教练”的角色，而不是高高在上的指指点点；
（4）有勇气与传统的理论和数学类授课方法说再见，像软件研发一样教软件工程课；
（5）保持对IT业界新技术、新方法、新产品的热切关注，持续学习，持续改进自己的教学。
所以，我个人非常推荐大家阅读邹老师的这本《构建之法》。
当然，一本书不是万能的，邹老师的《构建之法》再精彩，也需要有更多的教师在自己的课堂上去实践。一本书也是远远不够的，若周筠编辑能够想办法把邹老师个人也给出版了，我们买回一个用作给我们学生的TA，面对面给学生以教诲，岂不妙哉？
哈哈。

　　《构建之法》读后感(九)：构建之法，超越软件

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

　　《构建之法》读后感(十)：构建之法——一本不可多得的软件工程教材或辅助参考书

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