作业三：读《构建之法》1-5章读后感
由于放了国庆假所有看书的效率不是很快，只能慢慢的去研读研读，不过正是这研读才能使我有了深刻的体会。
第一章：概论
第一章主要内容是讲述了计算机科学的领域，软件工程和计算机科学的关系，软件的特性，软件工程的定义与组成部分。
之前很多老师问过我们：“什么是软件？”，我总是想到了软件=数据结构+算法，但是看了这一章之后，我突然醒悟原来我之前的角度和看法都是有误的，正确的思路是程序就是数据结构+算法、软件即程序+软件工程、软件企业即软件+商业模式。程序包括算法、数据结构是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量，商业模式决定了一个软件企业的成败。将我从软件就是单纯的一串串的代码的死胡同中拉了出来，带我进入一个新的视野。
在1.24中，有句一著名的笑话：这不是缺陷，这是一个功能（It’s not a bug，it’s a feature）！很多人认为有Bug就是质量不合格，没有Bug就是质量完美，其实这也未必。我们大街上看到很多不同品牌的汽车；这些汽车出厂时都通过了各自的质量检测，符合行业的质量标准。但是你问路人哪些车的“质量好”，很多人会告诉你有些车的质量大大好于另外一些车，那为什么还有人买那些质量“不够好”的汽车呢？对于某些顾客来说，某一类的汽车满足了他们的需求，他们就会买。如果销售人员不经市场调研向不合适的目标用户推销自己公司的汽车，最后销量未必理想。其实是否存在一个问题只是看你的角度问题，站在一个角度看可能是一个缺陷但是站在另一个的角度上看，可能就是一个完美的东西。例如在沙漠上看黄金会远远不值于水，但是在城市里看水的价值将会远远的不够黄金重要。
第二章：个人技术和流程
第二章主要内容是讲述了单元测试，回归测试，效能分析和通过PSP讲解个人软件开发流程。
在2.4，上有一句话“哎，你看我一通加班，就写好了程序，得了高分。也不用啥软件设计的原则，事先也不用需求说明书，也不留什么文档，就搞定了！软件容易得很！“。这句话就是学生陷入了”我有银弹“得误区，虽然短期看来完成了作业，也得到了锻炼，而且花费的时间很少!但是细细分析，长期来看是对自己不利的，首先，这样在学习期间并没有学习到很多东西，只是单纯完成作业而已，其次，打代码的习惯并没有很好的得到练习，缺少了设计原则，以后工作会处于一个非常不利的地位。
我觉得，个人学习应该一步步慢慢来，稳扎稳扎的向前走，而不是为了应付而应付。
第三章：软件工程师的成长
这章的主要是评论软件工程师水平的主要方式，技能的反面，TSP对个人的要求，软件工程师的思维误区。
在3.3中，有五个等级分别是临时的寄托或工作、工作、职业、投身的事业以及理想的呼唤。我觉得前三种的进步空间是很小的，后面两种可以让你有很大的进步空间。我在一篇博客中看到一句话：“要么不要做，要么就精于事情。”只有你投身于事业中，你才能感到乐趣，才能够真正的完成一件事情，我觉得一个软件工程师的成长就是要以投身事业的态度去学习
第四章：两人合作
这章的主要内容是代码规范，极限编程，结对编程，两人合作的不同阶段，影响他人的技巧。
在4.5.2节中，我看了这一段文字“在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平比较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间”。虽然我觉得这样会带动那个水平比较低的人，但是我觉得还是让两个水平差不多的人结对比较好，可以让这个程序的会更加的完美，只有融合了不同思路的软件才能够更全面，使这一个软件不至于那么的片面，我看过很多人做作业都是抱大腿然后都是由那个大腿一人决定了这个作业的好坏，但是这样的成品并不是很好。
第五章：团队和流程
这章的主要内容是典型的软件团队模式和开发流程都有哪些？各有什么优缺点，TSP,MVP,MBP,RUP。
在5.1中，有句话：“这七八个人是团队（Team）么？不是，他们只是一群乌合之众，临时聚集在一起，各自完成任务就领钱走人。我永远相信着一句话：”一加一大于二“。一个团队的效率肯定要大于个人的能力，但是一个完美的团队肯定是一个强大的军队。我觉得想要成功就应该组一个团队，而不是找一群乌合之众去完成一个项目。然后在一个团队中要有明确的分工，不应该个人在一个集体中不知道自己的定位是什么。
总结：虽然我现在是一个还没入门的软件工程师，但是看了这些内容后，我照着着思路走下去，我会渐渐的会越来越优秀。
