读完《构建之法》的1-5章后我才发现这本书把我们软件工程诠释得太好了，有很多精辟的思想和建议在这里，让我看完之后感触颇深，虽然我才看完了前五章，但是我的激情已被点燃，我发现我已经深深爱上这本书了，强烈地好奇心迫使我快点往下看了。可我还是先暂时压制住了我的好奇心，先把读后感写完再看。
第一章：这章主要是讲软件工程的概论，讲述了软件工程的发展史还有起源及其软件工程的特性。这使我开阔了我的视野。让我了解到了软件工程的由来也不是容易的，它经历了好几个阶段。这章让我比较感兴趣的是讲述了软件工程的开发和维护，还有在这些过程中所遇到的一系列严重的问题。开发一个新软件不是那么容易的，而且在经历多个阶段后开发出来了它的维护问题也紧跟着来了，所以不免会遇到众多难题。不过最重的还是团队的力量，记得它讲述了团队的bug让我记忆犹新。是啊，我刚开始还一直在想为什么开发个程序那么复杂呢？现在我明白了，团队的合作市最重要的，我们一个团队必须有强大的凝聚力和团结精神，不然来一个团队的bug都会让你损失惨重。
第二章：这一章主要讲述了单元测试跟个人技术和流程。如何写单元测试也是我们需要重视的一个问题。因为测试很重要在我们写程序的过程中。如果我们写的程序有问题或bug，都会影响到程序的正确性和准确性，测试会很好地很准确很快速地保证我们程序的正确性。那个VSTS是什么来的？我百度了一下也还不是很懂，希望老师能告诉我。实践也是很重要的，我们要是没有实践那只是空有一身理论不会应用，简直就是纸上谈兵。
第三章：这章主要讲述了软件工程师的成长。在开发研究一个项目中，软件工程师的个人技术和水平也是很重要的，所以在团队里必须利用好你队伍里面每一个成员的特长，因为每一个人的个人能力很重要，因此分工要明确和合理。我们软件工程师的成长和就业也是一个比较尴尬的历程，还要考好几个级，我们在工作上也是需要从入门到熟练，从熟练到带头人，最后到大师的历程。可是我不清楚入门的软件工程师是具备哪些技能呢？不过只要我们技术过硬找个好工作还是没有问题的。
第四章：这一章主要讲述的是代码的规范书写和两个人的合作，比如说两个人结对编程，结对做项目和论文，也还讲述了两个人合作的阶段、技巧、影响和必要性。首先说明了代码的各种明确格式，讲的很详细，让我学会了很多，让我知道了弄出一个完整能使用的代码来是很复杂的工程。因此，结对编程时很重要的。为什么要结对编程？答案已经很明显了。一般我们结对编程中有两个角色：驾驶员和领航员。驾驶员是控制键盘输入的，领航员是起到领航、提醒的作用。这两个角色我们可以轮流切换着用，工作不要连续超过一小时，一小时后要休息15分钟，这样不会太累。可是结对编程最重要的还是要看两个人合作的技巧，因为在合作期间会经过萌芽阶段，磨合阶段，规范阶段，创造阶段，解体阶段，所以两个人需要怎么做，怎么配合，怎么默契做事尤为重要，这关系到项目能不能成功完成。
第五章：这章讲述的是团队和流程，主要说典型的软件团队模式和开发流程有哪些，各有什么优缺点，团队模式和开发效率。可是我不明白为什么每个团队模式都有它的缺点？团队的模式有很多，像一窝蜂模式的团队是不行的，他们只是临时聚集在一起，存活的时间不长的。主治医师模式是有一个主要负责程序的人，其他人在各司其职，这种模式看似虽好，但是到最后往往会退化为“一个学生干活，其余学生跟着打酱油”。随后也出现了很多团队模式，比如说明星模式，社区模式，业余剧团模式，秘密团队模式，特工团队模式，交响乐团模式，爵士乐模式，功能团队模式官僚模式，写了再改模式，瀑布模式等等。写了再改模式是大多数学生都在使用的模式，看起来跟一窝蜂模式非常像。我比较欣赏的是功能团队模式，这个模式就是具备不同能力的同事们平等协作，共同完成一个功能。在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能，他们之间没有管理忽然被管理的关系，这样有利于小组和谐交流，也能充分发挥出每个人最杰出的技术，使项目最好的完成出来，这样效率也高，准确性也高，也比较和谐。虽然这个模式有时会怕每个小组写的格式规范不一样，不过这些都是小事啦，我会事先让大家都统一好一样的格式规范就不会乱啦。所以在我看来目前比较好的就是功能团队模式了。
