《构建之法》1-5章后感
作业要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
第1章 概论
第一章的内容主要说了软件、程序、软件工程三者的等式关系以及软件工程与计算机科学的关系，在此章前半部分我们可以得知“软件=程序+软件工程”推导出“ 程序=算法+数据结构”的关系，但在我，看来算法和数据结构固然重要，但是你一直执着于竞赛，你是没办法做出软件的。对于大部分人，竞赛还是参与为主。后半部分说明计算机科学中的理论研究部分，大多可以从形式上证明，与数学、离散数学、数理逻辑密切相关；计算机科学中与时间相关的部分，都和数据以及其他学科发生关系；软件工程则和人的行为、现实社会社会的需求息息相关。
在看这一章之前我一直有一个困惑：软件工程是不是教哪些不怎么会写程序的人开发软件？看完后我才知道软件工程是教会开发程序的人，更好的，更完善的写出软件，而教不会人写程序。写程序，需要去练习数据结构和算法。
第2章 个人技术和流程
每一个团队都需要有特定的流程来管理开发一个项目，每个合格的工程师也都会在软件生命周期所做的工作中有一个流程，这一章介绍PSP（Personal Software Pro-cess，个人软件开发流程）。在这章中作者一开始就向我们介绍了“单元测试”，其作用就是：“让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证。”什么是好的单元测试呢？
1.单元测试应该在最基本的功能/参数上验证程序的正确性。
2.单元测试必须由最熟悉代码的人（程序的作者）来写。
3.单元测试过后，机器状态保持不变。
4.单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
5.单元测试应该产生可重复、一致的结果。独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
6.单元测试应该覆盖所有代码路径。
7.单元测试应该集成到自动测试的框架中。How？
8.单元测试必须和产品代码一起保存和维护。
看完了第二章我有一个疑问就是：每一段代码都需要单元测试吗？为什么如果单元测试的结果是错的，就一定是程序出了问题？
第3章 软件工程师的成长
这一节主要讲述了初级软件工程师如何成长？衡量个人工作量和质量的指标、以及在团队中如何做一个优秀的队员。
团队对个人期望是怎样的？
1、有效的交流
2、按时交付
3、接受团队赋予的角色并按角色要求工作：是否能接受不同的任务并高质量的完成
4、全力投入到团队的活动：评审会议、代码复审等
5、按照团队流程的要求工作
6、做好准备：在开会讨论之前、开始一个新功能、新项目之前，都要做好准备工作。
7、理性的工作:一个成熟的团队成员必须从事实和数据出发，按照流程，理性的工作。
这一章我的疑惑是在讨论质量指标的过程中，提到了是否能够按时交付。但是实际软件开发过程中，很多工程师不能够做到按时交付，那么工程师不能按时交付的原因到底是什么呢？他们算不算合格的团队？
第4章 两人合作
这一章一开始写的是如何规范我们写的代码，因为如果代码设计则涉及函数、参数、类等的设计，当你的函数分类明确，参数设置让人一看就能懂这是用来做什么的，这样的代码就会显得有层次、有条理。
关于结对编程，其好处是：
（1）在开发层次，结对编程能提供更好的设计质量和代码质量，两个人合作解决问题的能力更强。
（2）对开发人员自身来说，结对工作能带来更多的信心，高质量的产能能带来更高的满足感。
（3）在企业管理层次上，结对能更有效地交流，相互学习和传递经验、分享知识，能更好地应对人员流动。
两个人合作阶段包括：萌芽阶段、磨合阶段、规范阶段、创造阶段和解体阶段。
在每一个阶段中，两个人一起合作，自然会出现不同的意见，没有绝对正确或错误的方法，只有合适或不合适的方法，要学会聆听别人对自己写的代码提出的意见，整合起来，找出更好地方法。
看完了第四章我有一个疑问就是：如果在结对编程的过程中两个人产生了分歧的话，这不是会拖慢工程进度吗？为什么作者还是要推荐结对编程呢？
第5章 团队和流程
在这一章中作者介绍了软件团队的几种模式：1.一窝蜂模式。2.主治医生模式。3.明星模式。4.社区模式。5.业余剧团模式。6.秘密团队。7.特工团队。8.交响乐团模式。9.爵士乐模式。10.功能团队模式。11.官僚模式。接下来作者讲述了几种开发流程模式：1.写了再改模式。2.瀑布模式。3.由瀑布模型的各种变形。4.统一流程。5.老板驱动的流程。6.渐进交付的流程，mvp和mbp。7.tsp的原则。
看完了第五章我有一个疑问就是：当我在开发程序的时候，怎样在这众多流程中选择一个合适我程序的流程模式呢？
