这个作业的要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
第一章 概论
这一章主要介绍了软件工程的理论和知识点还有其特性、计算机科学的领域介绍和它与软件工程的关系。
在读到1.2.5节的时候，我看了这一段文字 “软件行业也有一句著名的笑话：这不是缺陷，这是一个功能！（It's not a bug,It's a feature!）很多人认为有Bug就是质量不合格，没有Bug就是质量完美，其实这也未必。我们大街上看到很多不同品牌的汽车；这些汽车出厂时都通过了各自的质量检测，符合行业的质量标准。但是你问路人哪些车的“质量好”，很多人会告诉你有些车的质量大大好于另外一些车，那为什么还有人买那些质量“不够好”的汽车呢？对于某些顾客来说，某一类的汽车满足了他们的需求，他们就会买。如果销售人员不经市场调研向不合适的目标用户推销自己公司的汽车，最后销量未必理想。有实际用处的同时又是完美的软件，在世界上是不存在的。没有实际用处的“完美”软件也几乎没有，有人会说一个打印“Hello World！”的程序似乎可以成为“完美”，但是我们不知道这个程序能不能算作一个软件。那市面上有这么多不完美的产品，软件团队为什么还要把这些不完美的软件发布出来呢？为什么不能等到它们完美之后再发布？”，有这个问题“怎么定义一个完美的软件，难道所有发布出来的产品都是毫无缺陷的吗？”。
我查了资料，CSDN里有位博主说道“不是所有的缺陷都要修改。让所有人都满意的软件是不可能的。对于用户体验问题一定要全面客观地评价。最终交付近乎完美的产品。”，根据我的实践，我得到这些经验—就好比如苹果手机，现在新出iPhone XS Max，尽管价格已经卖到上万，可是每次经过苹果专卖店里面都是挤满了人，甚至要买新产品需要排队等上半个小时到一两个小时才可以购买。为何那么多人趋之若鹜，难道ios系统毫无缺陷？其实不是的，作为iPhone使用者，ios系统还是有一些不够人性化的地方。就好像现在新更新的ios12新安装之后也会有不少问题，比如部分APP由于兼容问题出现加载图片异常的问题，耗电异常，续航变短还有地图无法定位导航，定位失效等问题。所以以后会有更多的版本ios13、ios14....每一个版本都是上一个版本的更新，完善，改进。在我看来，软件的缺陷是永远改不完的，正是不断有用户使用发现新的缺陷，软件才能做到不断地完善，这个产品才会越来越好。 但是我还是不太懂，我的困惑是既然有新的改进，那么软件工程师如何保证在新的改进上保持着原来软件的完整性呢？
第二章 个人技术和流程
这一章主要介绍了单元测试、回归测试、效能分析、个人软件开发流程（PSP）。
在读到2.1.1节的时候，小飞和阿超的对话引起了我的注意，阿超在回答小飞的问题时说 “也许因为他们没有在一开始就写单元测试，所以后来又很多小强要处理。很多调查显示，在软件开发后期发现的Bug，修复起来要花更多时间。”，那么我有个疑问“是不是每一步只要有新的功能出来就要弄一个单元测试，像C语言中一个单元就指一个函数，Java里一个单元就指一个类，如果是一个十分大的项目，有很多函数，有很多类，它不就需要许多个单元测试，这样繁杂的工序，有方法可以提高单元测试的效率吗？”
我查了资料，CSDN里有位博主写了一篇文章“如何通过测试替代（Test Doubles）合理隔离单元测试以提高单元测试效率”[注释1]，里面有提到使用测试替代技术隔离单元测试中对网络系统、数据库系统和文件系统的访问以提高单元测试效率的方法。Test Doubles为满足单元测试的要求，通过一定的方法和技巧，解脱单元测试对外界的依赖变得更有现实意义。良好的单元测试代码会极大的改善软件代码的架构设计和帮助开发人员编写可测试的代码（Testable Code），提高软件质量。测试替代技术就是这样一种方式，它可以帮助单元测试人员摆脱对第三方系统的依赖，进而提高单元测试的隔离性和执行效率。 根据我的实践，我平时写c语言或java的时候，每写完一个函数功能就运行一次，看看有没有Bug，但是有时候有些Bug是逻辑上的，j就会很难显示出来，要自己慢慢地想，通常这种情况我都是屏蔽掉某些语句，然后运行，一直运行下来哪条突然运行有误就知道是这个语句有问题，但是这个过程通常都要花费不少时间。但是我还是不太懂，我的困惑是比如是不是每个函数和类尽管之前测试后没有问题，只要往后需要修改一点都要重新测试？那为了不断完善代码，是不是要一直进行单元测试？
第三章 软件工程师的成长
这一章主要介绍了软件工程师个人能力的衡量与发展和其发展还有技能的反面。
在读到3.2.2节的时候，我看到了有关于“职业成长”的内容： “史蒂芬·迈克康奈尔创立的公司也为员工提供了一套成长路径。简介如下。首先，一个软件工程师需要具备一定的知识和能力。知识：迈克康奈尔把相关的软件知识分为十大知识领域。能力：一个工程师对这些知识的掌握分为如下四个阶段。入门；熟练；带头人；大师。其次，工程师有职业成长级别。迈克康奈尔把工程师分为8个级别，一个工程师要从一个级别升到另一个级别，需要在各方面达到一定的要求。”，那么我有这个问题“人们都说如果一个软件工程师不往上爬（也就是不升级），一直原地踏步做码农，到一定年龄就会被淘汰，这个到底是为什么？”。
我查了资料，CSDN里有一篇标题为“程序员年龄大了真的会被时代淘汰？”[注释2]的文章，虽然不长但我觉得讲出了我心中疑惑的答案。他说“俗话说老姜辣味大，老人经验多，老程序员的长达几十年经验是年轻程序员短时间内所不能企及的，满足现状，忽视知识更新，与时代脱节这类的人才会被社会放弃，由此可以看出跟上社会脚步，定期进行知识的更新与交流是很有必要的。”根据我的实践，我还是很认同这位博主说的话，其实淘汰的不是年龄而是技术，是知识。原地踏步得不到提升，于现在的社会状态就是会被淘汰。就好像达尔文所说的适者生存，道理是一样的，有一群准备吃树叶的长颈鹿，开始时，每只长颈鹿都能吃到树叶。可是后来，较矮的树叶被吃完了。这时，那些脖子比较长的长颈鹿就因能吃到树叶儿活下来了。人就像举例里所说的长颈鹿那样，社会需要与时俱进的人才，社会在进步，可是我们人却止步不前，终究会被淘汰。一个程序员如果不更新自己，就会被这个圈子淘汰。基于这个答案有点我又不太懂了，我的困惑是一个程序员要怎么样才能做到与时俱进呢？只是不断学习就可以了吗？
第四章 两人合作
这一章主要介绍了代码和其风格还有设计的规范，代码复审，结对编程，两个人合作的不同阶段和技巧。
在读到4.6.1节的时候，我看了一个表格，它列出了“影响他人的4种方式”，分别是“断言：感情很强烈，适用于充分信任的同伴。语音，语调，肢体语言都能帮助传递强烈的信息。”、“桥梁：给双方充分条件互相了解。”、“说服：有条理，建立在逻辑分析的基础上。即使不能全部说服，对方也可能接受部分意见。”、“吸引：可以有效地传递信息，但是要注意信息的准确性。夸大的渲染会降低个人的可信度。”。看完这几种影响他人的方式之后，我便有了疑惑，每个人的性格都不同，每一个人的影响他人的方式也都不同，那么如果当某一部分出现不同意见的时候，肯定很麻烦，为何不能一个项目一人完成，一定需要一个项目团队？
我查了资料，王梓木先生写了一篇名为“企业中人与人之间最本质的关系是合作”[注释3]的文章，里面提到“互联网时代是信息高度对称的，在这种情况下，英雄创新的时代快结束了，大众创新的时代到来了，大众创新体现的依然是一种合作文化。”根据我的实践，我觉得很多事情可能一个人真的可以完成，但是完成的情况还有时间会与多人合作完成的相差很远。比如一个人做一个模型或者拼一块拼图肯定比几个人一起做一起拼用的时间更多。多人合作可能会有分歧，会出现不同的意见，但是也正因为有这种分歧的出现，这个项目才会越做越好，一个人的想法永远困在那一个人身上，无法得到扩展的话，那么这个项目开发出来效果肯定没有一群人开发出来的好。但是我还是不太懂，我的困惑是当一个项目真的具有很大的分歧，意见怎么也不能够统一的时候要怎么样解决呢？互相说服吗？但是如果两个想法都很好要怎么取舍？
第五章 团队和流程
这一章主要介绍了软件团队的模式还有开发流程。
在读到节5.2节的时候，我看了作者列举出了好多个软件团队的模式，分别是“一窝蜂模式”、“主治医师模式”、“明星模式”、“社区模式”、“业余剧团模式”、“秘密团队”、“特工团队”、“交响乐团模式”、“爵士乐模式”、“功能团队模式”、“官僚模式”，那么我有这个问题“在那么多的团队模式中，怎么样才能知道自己的团队属于哪个模式呢？”
我查了资料，百度有篇文章“软件开发和团队建设”[注释4]，里面提到“一支程序开发团队之所以成立，是为了承担并完成某项由任何个人都无法独立完成的任务。因为只有团队合作，才能将复杂的事情变得简单，将简单的事情变得容易，使做事的效率倍增，可以说，团队合作正推动企业向简单化、专业化、标准化的方向发展。不管怎样只要是团队中的每个人能做好自己的事情，并能不断的和别人交流，那么这个团队就是成功的。”，这几句话不仅说明了团队对于软件开发的重要性，并且解答了我心中的疑惑。的确，无论是处于哪一种模式的团队，只要做到自己做好自己的事情并且能够善于与队员沟通就肯定能成功。每个团队的模式是要根据大家的情况来定。以前学校也经常需要我们小组合作，做的最好的小组通常组员的参与度最高，只有大家齐心协力地做，团队做出来的产品才会像大家所预期一般。但是我还是不太懂，我的困惑是模式是根据具体的小组情况来定，但是它是规定化的吗？某个团队定下了某个模式之后团队模式还可以随着具体情况更改吗？
结语：
阅读了前五章的内容之后，解答了我很多有关于软件工程这一学科的疑惑，尽管又有了新的疑惑，但是对软件工程这一专业的知识了解了更多一些。之前看有关于软件工程的书都觉得很难读下去，很多知识点都难以理解，但是这本书作者写得十分生动形象，理解起来基本没有问题，而且觉得很有趣。
注释：
1、如何通过测试替代（Test Doubles）合理隔离单元测试以提高单元测试效率：https://blog.csdn.net/cxboyee/article/details/50516486
2、程序员年龄大了真的会被时代淘汰？：https://blog.csdn.net/keoAEIC/article/details/80326677
3、企业中人与人之间最本质的关系是合作：https://www.xzbu.com/3/view-7334047.htm
4、软件开发和团队建设：https://baijiahao.baidu.com/s?id=1605761291755616092&wfr=spider&for=pc