《构建之法》读书笔记
一、前言
早在10月份还在上软工实践课的时候，就立了一个Flag说要读完《构建之法》。可惜当时并没有完整地将书读过一遍，而是在实践中要用什么内容就读什么内容。后来等有时间通读过一遍后，却没有记录成博客，等到邹欣老师给我留言的时候已临近期末，再加上自己的拖延症，导致该文静静地躺在草稿箱中不见天日。（这么看来，deadline真的是第一生产力...
二、初步印象
软件工程，一开始给我的体会就如同书中二柱说的那样，”软件工程讲的净是一些奇妙玄幻的概念，拗口的专业名词加上纷繁复杂的流程，其实做软件完全没有那么难，主要靠的还是程序员自身的修养和完成工作的素质“。（摘自7.7节 练习与讨论）面对课内教材动辄二十几章的内容（还是经过改编的本科教学版），如果不是为了考试，实在是没多大兴趣翻下去。好在，栋哥在课程伊始给了一些参考书籍，其中有一本叫《构建之法——现代软件工程》，翻阅了几页之后，给我的第一印象是生动有趣，接地气！
在开篇，作者提到了“程序 = 数据结构 + 算法”这个广为人（程序员）知的名言，我由于常敲算法题，对此深以为然。我一直以为软件和程序之间差别应该不大，所以才会有二柱那样的体会。但是后来作者通过移山公司程序员阿超的例子展现了软件和程序的区别，提出“软件 = 程序 +软件工程”这一推论。这让我对软件的认识发生了深刻的改变，会写算法和数据结构、会写能跑的程序只能算是自己的一项基本功，在此基础上，软件工程这门学问才是真正决定了软件的质量和命运。不得不说，概论部分介绍的方方面面，让我第一次对软工有一个全景式的直观感受。
虽然软件工程涉及的面非常的广，但是作者还是尽可能的囊括了软工的方方面面。“全书对软件工程内容的覆盖不逊于任何一本现行的教材”，确实，从目录中便可窥知一二。不仅包括从软件工程师的成长、团队流程、敏捷开发到项目经理、用户体验、测试发布这些软件工程的核心内容，最后还包括了IT创新和职业道德等内容，因此覆盖面广也是书中一大特点。
全书始终贯穿着情景式、对话式的对白，作者善于将一些晦涩难懂的概念透过人物生动形象、幽默有趣的对白展现出来，可谓是深入浅出。这可能跟邹老师曾投身于教学一线有关，才会了解学生在学习软工课时的痛点。在阅读对话的时候，自己也会不知不觉地融入其中，仿佛也在着参与这场讨论。在第七章讲到MSF（Microsoft Solution Framework，微软解决方案框架）时，其中有许许多多的对话内容，这对于我们这种一点都没接触过MSF的同学理解它的思想有很大的帮助。试想，如果一上来就长篇大论各种虚无缥缈的概念，第一是什么第二是什么balabala...，我想很多人是没多大兴趣看下去。即使勉强看下去，没有实际软件开发经验的学生也会看的一头雾水，到头来也还是什么也不知道。
邹老师始终强调 Learning by Doing，做中学的模式，这也是他自己在教学实践过程中总结出来的。因此，书中不仅仅流于概念和方法论的介绍，还十分注重实践过程，对于大部分内容都会配合很多的思考与练习，同时也会提供相关的评价指标。毕竟，软工如果只有理论没有实践，也就失去这门课的意义了。周筠老师在知乎专栏文章 他们说我们永远做不到，然而我们有『做中学』（Learning by doing）——来吧，IT小小鸟 里也举了一些具体的例子，说明了将该模式与软工实践结合的益处。不得不说，栋哥采用“做中学”来指导我们的软工实践课是一个正确的选择，选修了这次的软工实践课可谓是受益匪浅！
三、付诸实践
在软工实践课上，也曾布置过多次博客作业（需求分析与原型设计，毕设导师智能匹配，软件产品案例分析），通过阅读书中相关内容后将其付诸于实践。其中，前两个是结对编程项目，需要和同伴一起完成。书中提到，结对编程中有两个角色：驾驶员和领航员，一个负责具体的执行，另一个负责导航、检查、护航。在实践当中也确实如此，一个人掌控键盘编写程序，一个在旁边指出程序中的错误，这在一定程度上确实能够提高代码的质量。书中为结对编程提供了“方法论”，讲述了如何进行结对编程以及两人合作的技巧等。其中给我留下深刻印象的是4.6.2小节—如何正确地给予反馈，作者将反馈分为最外层（行为和后果）、中间层（习惯和动机）和最内层（本质和固有属性），不同层次的反馈给人不同的感受。如果将反馈上升到最内层，说不定两人合作将从磨合阶段直接到解体阶段... 感谢当时的结对同伴，在结对编程的时候我们能够进行有效的交流反馈，顺利地完成任务！在结对编程的同时，我们还学习了解了PSP（Personal Software Process，个人开发流程），并估计了完成结对编程项目所需的耗时。
在软件产品案例分析中，我们不仅要充当实际用户、还要充当测试人员甚至是项目经理。这个难度看起来有点高，要一人分饰多角。其实在软件开发过程中，也常常需要这种换位思考。在进行需求分析时，书中提供了一个竞争性需求分析框架—NABCD模型，这一模型被多次用于我们的实践课程作业中。第12章用户体验中举了飞机中的遥控器等例子，强调了用户体验设计的一个重要目标就是要降低用户的认知阻力，也就是我们常说的“这款软件上手快不快”。因此在软件产品案例分析中，用户体验部分也作为我评测的一大重点。评测部分还有一项内容是“估计这个项目做到这个程度大约需要多少时间”，书中也举了一个“徒步遍历中国陆地边界”的例子，同学们给出了从50天到不可能的各种答案。除了盲目的估计，其实也有一套有章可循的项目估计的经验公式：Y = X ± X ÷ N。
在团队开发中，我们团队经历了萌芽、磨合、规范和创造阶段。当然，我们不会像王屋村“搬砖团队”那样，临时聚在一起，各自完成任务就走人，没有一个集体的目标。虽然我们组内经常戏称各种抱大腿，如下图所示。
四、个人建议
其实吧，自己作为一名学生也没有什么实际软件开发经验，也谈不上提什么建议，所以下述内容可能也有不对的地方，还请各位批评指正。
- 书中的注释都放在每一章的最后，感觉翻起来不太方便，直接附在相关页的下方会不会更好？
- 本书有较多的超链接，虽然封面提供了整合链接的二维码，但是有的时候读者可能仅仅对某一注释中的链接感兴趣，所以希望能够提供短链接
- 2.1.1小节 用VSTS写单元测试，这边给的例子是用C#编写的，但是大多数同学应该没有C#编程经验，所以建议可以更换成同学们比较熟悉的语言，如C++等。这样也可以跟第四章中关于代码规范方面用C++举例相对应起来
- 第七章用了一个章节讲了微软解决方案框架，如果说本书的定位是面向高校的软工教材的话，我觉得可以不用这么多篇幅，MSF这部分可能更适合作为补充延伸的阅读材料
- 希望能够有一个完整的项目贯穿全书始终，比如像《软件工程—实践者的研究方法》这本书中的“SafeHome”安全住宅项目，这样可能使读者更好地把各部分内容串在一起理解，融会贯通
- 索引部分的条目可以稍微精简一些，更加突出重点
