这个作业的要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
第一章 概论
第一次拿起这本书，给我的第一感觉是，有点厚，一开始以为又是一些枯燥的概念描述，想不到书中作者用了一些比较亲近的口吻和我们读者进行介绍。循序渐进，这会让即使是外行的人拿起这本书也有继续读下去的冲动。
但是书中对BUG的解释和举例稍有不妥。
在书中第16页写到，“什么是bug呢？简单的说，软件的行为和用户的期望值不一样，就叫bug。是否是bug取决于用户，开发者角度的不同。”
这段话，在理解中可以表示为：我觉得他有bug，就是有bug。
但是后面文中又说：“是虫子还是豆芽，不同的人有不同的答案。...这不是一个缺陷，这是一个功能”。
虽然书中作者有举例说明，但是作者至始至终没有表明他的观点，举例的例子又有些不知所云。如果说一开始那个解释就是表明意思，后面那句又有点打脸。
所以就是觉得作者的立场和观点在文中不太明确，有点像在写议论文提了一大堆问题和例子、解释，却没有一个是表明自己观点，那样的杂乱。
所以建议作者能在文中确切表明自己的观点和见解不要一味举例或比喻还有就是这个举例可以换个更好的，让读者有些明确的理解。就像是外行人读起这个书也不会被太多的举例而混淆理解。
又言，如果说作者真的是认为“是否是bug取决于用户”，我是觉得我反对这句话的。
此言可以理解为“一个软件对于不同的人有不同的bug”“再好的软件，我觉得他有bug他就是有bug 。”
如作者意思举例而言，我现在用微信发朋友圈，我要有转发功能，在朋友圈能看到非我的好友给我好友点赞。但是微信没有，所以微信有大bug所在。是这个意思吗？
若此，那你为什么不用QQ呢？你要的他都有，每个软件都有他自己的设定的功能。这不是bug。我觉得bug应该是程序在他本身拥有的属性下存在的一些缺陷或者漏洞。而不是单单的，不在他定义下的功能没有实现。
这就好比你叫一个历史学家打俄罗斯方块的代码，他说他不会，那他就是一个没有垃圾学者吗？他就是一个垃圾的历史学家吗？恐怕不是这样判断吧！？闻道有先后，术业有专攻，仅此而已。人若此，程序亦若此呀。
第二章 个人技术和流程
在第二章中我了解到了单元测试和回归测试、效能分析及SPS等。
其中我对单元测试这一块有点疑惑。
单元测试，处于软件测试初期阶段，任务主要包括：模块接口测试、模块局部数据结构测试、模块中所有独立执行通路测试、模块的各条错误处理通路测试、模块边界条件测试。
其中，1，模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。2，检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。3，除了局部数据结构外，如果可能，单元测试时还应该查清全局数据对模块的影响。 4，一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，5，边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。
由此可见，单元测试的工程并不小，那么我们在写一个程序之前是否都要写单元测试呢？一些比较简单没那么复杂的程序是不是就可省略呢？
第三章 软件工程师的成长
在第三章中，主要讲了软件工程师的主要方法，技能的反面，TSP对个人的要求，软件工程师的思维误区等。
在这一章的55页开始，写了软件工程师的自我评估。里面还写到了，没有人能在学校掌握所有“将来会用得到的知识”这个很有道理，就好像在互联网还为发展之前，那个时代的大学生也不会学到电商知识一样。
还有就是，工程师应该在实际工作中不断学习，不断成长，根据自己的情况选择在哪个方面追求“专和精”，在那几个方面达到“知道就好”的水平。
这个我有个疑问，怎么知道呢？通过老师吗还是要通过职业需求呢？
正确的自我评估流程是怎么样的？在职业发展的考级中，有什么是对我们而言比较有用的？因为听一些师兄师姐说就业后计算机二级、软考等一些证书其实并不能让你升职加薪或者说并没有什么用，这是怎么回事？
第四章 两人合作
读完这一章之后我觉得深有感触。
之前在一些大作业中会有合作的现象出现，在合作中我认识到代码规范化的重要性还有注释真的真的真的很重要！
这样可以避免你在写完你写的代码之后你的伙伴接过你的代码还要看很久，或者解说完后在调用的时候出现了重复或者名词出错的情况。
代码规范了就会比较容易看出这代表的意思，而不是一个定义用一个字母表示，最后恍恍惚惚不知道是啥子意思来的好。
问题：复审是不是真的有必要？会不会拖慢了进程？
产生意见分歧的时候要怎么解决？虽然书中有些举例，但是觉得不排除会有公报私仇的想法，情绪也会影响一个人的直观判断什么的，也会让一个 程序的进度变慢，那么怎么样才能让合作更有效率，让两个人能同时在一个代码浪口中驰骋?
第五章 团队和流程
在这一章我们知道了团队模式有，一窝蜂模式，主治医师模式，明星模式，市区模式，业余剧团模式，秘密团队，特工团队，交响乐团模式，交响乐模式，官僚模式，功能团队模式。
开发流程有，写了再改模式（这个好像是我们比较经常用，虽然比较LOW），瀑布模型，瀑布模型的变形，统一流程，老板驱动流程，渐进交付流程，敏捷流程等。
有不同能力的同学们共同完成一个功能，在完成这个功能之后又重新组织其他同学完成下一个功能，每个小组一般有1-3个人组成，他们之间没有管理和被管理模式，每个小组都是一个有自主权的单元可以自由选用最有利于他们完成工作的任何技术。先阶段大学生是否试用于这种模式呢？
让我受益匪浅。但有几个小问题： 在现阶段的大学生几个人小团队的大作业中，我们更适用于哪种模式和开发流程呢？