《构建之法》读后感

　　首先我认为本书作为软件工程课的教材很实用，可以让学生一开始就接受系统训练。但是，如果学生没有足够的代码量和工程经验，对里面所讲的很多问题并不会有太多的切身体会，可能很难深刻理解。

　　尽管在课程的推进过程中老师有意地布置了一些小项目和大作业，想借此让我们实践书中的内容，但是效果仍不明显。首先，最主要的问题就是项目的大小设置。大的项目，在这里指的是需要至少十个人参与，每人平均代码量五千行以上，而且从需求分析到软件发布一共需要三个月以上时间的项目。对于课业繁重的学生来说，让我们在一个学期中全身心地投入到这种长期项目显然是不靠谱的，因为我们不是只需要学这一门课。所以，老师就用小的项目代替了大的项目，这样就尽可能地减小了我们的负担，同时保证了大多数人的参与。可是，当实际实施项目时，我却发现这种妥协其实是没有益处的。当人数限定在了很少几个人之中，代码量又没有太大的情况下，很多软件工程的手段是体现不出效果的。

　　比如，当我们的目标仅仅是两人或四人合作完成一个计算器程序、地铁售票系统或者电梯控制系统时，代码规范似乎并不是非常的重要，因为没有人会再回过头来阅读其他人的代码，我们所要做的仅仅是把自己负责的那一部分做好即可，如果遇到任何问题只需要让相应的负责人更改他负责的代码即可，完全体现不出实际工程当中代码迭代的过程。

　　又比如，当我们仅仅是一个宿舍内的（或关系好的）几个人一起开发这种小型项目时，我们完全没有必要利用任何版本控制软件。我们所要做的就是写好自己的代码，然后通过U盘、网盘或者QQ等手段将新的代码传给其他人就好了，至于新加入的功能、功能的解释、代码的审批等环节完全都被省略了，原因是我们互相都比较相信对方，而且沟通没有障碍，结果一般不会与预期有太大偏差。

　　像以上的例子可能是由于我们学生的执行方式有问题而造成的，但是如果能够更换成其他的项目形式，这样的问题可能就会被完全避免。

　　我认为，我们的课程应该将整个班级作为一个团队，整个学期的课程对应的项目应该围绕这个大的团队来进行制定。首先，整个团队应该共同参与一个项目，但是整个团队一分为二，一部分负责基础功能开发，另一部分负责添加新的功能。如此一来，对于开发基础功能的团队，他们会学到需求分析以及设计方法的知识，而对于添加新功能的团队，代码的托管，版本的控制，注释的编写，代码的阅读这几方面都会被考察到。为了能够让所有学生体会到两部分的工作，可以让整个团队同时开始两个项目，这个项目中负责基础功能开发的组在另一个项目中负责添加新的功能，反之亦然。而在评分时，可加入互相评分的部分，负责添加新功能的团队给负责基础功能开发的团队进行评分，以激励学生按照规范编写代码以及编写和整理相关文档。通过将团队扩大的这种方式，之前的问题也会迎刃而解，不会出现“根本不需要软件工程课的知识就能又快又好地完成项目”这样的情况。其次，当学生被分成了两个对立的部分（因为要互相平分）之后，学生的竞争意识也会对学习过程产生积极的影响。最后，采取这种做法最大的难题在于想出一个（两个，因为之前提到让所有学生体验两部分的工作）合适的项目题目，这些题目既不能太难以至于学生不能按时完成，或无法提出新的改进（来让另一组继续），又不能太简单以至于学生不需要沟通合作或使用软件工程的方法。但是我相信，只要认真思考，这样的项目是一定能想到的。

　　总而言之，我认为《构建之法》最适合有一定代码量积累和经验的人阅读，但这并不代表不适合缺乏软件经验的人看。但是如果将其作为教材，一定要让学生接触大的项目。如果不让学生接触大的项目，学生永远不会对书中提到的问题认真对待，相反地，大多只会认为其中的道理显而易见无需强调，等到真正遇到实际问题之后才追悔莫及。