这个作业的要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
第一章：概论
在第一章概论中，作者给我们讲述了软件工程是什么。在第一章中我们知道了“程序=数据结构+算法”，“软件=程序+软件工程”，当中得意义，了解到了软件工程中各个方面的大概内容，如“软件工程是什么”，“软件工程与计算机科学的关系‘，”软件工程的目标“等等。而我在阅读第一章的过程中，对其其中的一段非常的感兴趣。
”计算机人工智能研究“的一个重大挑战，就是计算机程序能否再国际象棋这个游戏中打败人类。从20世纪60年代开始，就有许多人员从理论和”智能“的角度着手，取得了一定的进展，但是最终离胜利的是遥遥无期。1985年，还是一个研究生的许峰雄这样想：”我们从一个不同的方向去逼近这个问题。我们，至少是我自己，把这个问题看成是一个纯粹的工程问题。“ 历史证明，这个工程的角度出发，用“蛮力”提高计算速度的工程方法远远甩开了同时代各种“智能”方案。1997年，许峰雄带队设计的“深蓝”战胜了国际象棋大师 加里·卡斯帕洛夫。“
然而，对与这段文字我有一些问题：“深蓝”是怎么样通过“蛮力”实现的?“深蓝”算是人工智能吗？
在查阅了一些资料后得到了以下的内容。
深蓝是并行计算的电脑系统，建基于RS/6000 SP，另加上480颗特别制造的VLSI象棋芯片。下棋程式以C语言写成，运行AIX 操作系统。1997年版本的深蓝运算速度为每秒2亿步棋，是其1996年版本的2倍。1997年 6月，深蓝在世界超级电脑中排名第259位，计算能力为11.38 gigaflops。1997年的深蓝可搜寻及估计随后的12步棋，而一名人类象棋好手大约可估计随后的10步棋。每增加1步棋的搜寻能力约等于增加下棋强度约80 ELO分。
深蓝是穷举，因为国际象棋棋子的变化在于计算的空间内，所以深蓝相当于是一个超级计算机系统，直接算到了几乎所有的可能。
那么“深蓝”算是人工智能吗？
人工智能的定义可以分为两部分，即“ 人工”和“ 智能”。“人工”比较好理解，争议性也不大。有时我们会要考虑什么是人力所能及制造的，或者人自身的智能程度有没有高到可以创造人工智能的地步，等等。但总的来说，“人工系统”就是通常意义下的人工系统。
关于什么是“智能”，这涉及到其它诸如 意识（CONSCIOUSNESS）、 自我（SELF）、 思维（MIND）（包括无意识的思维（UNCONSCIOUS_MIND））等等问题。人唯一了解的智能是人本身的智能，这是普遍认同的观点。但是我们对我们自身智能的理解都非常有限，对构成人的智能的必要 元素也了解有限，所以就很难定义什么是“人工”制造的“智能”了。
而对于许峰雄的个人见解，它认为对“弈棋电脑”的研究与传统的“人工智能”毫无关系。“我的一些同事认为AI是无稽之谈，”许峰雄表示，“深蓝”根本就不是基于AI技术构建的。我们的研究很单纯――只想解决一个问题：我们能不能创造出一台速度快到足以击败人类世界冠军的计算机。”
而我对这个问题依旧感到困惑，通过穷举实现的超级计算机系统“深蓝”，它算是人工智能吗？
第二章：个人技术与流程
在第二章个人技术和流程中，教材中给我们普及了一些基本的概念和技术，如单元测试，回归测试，和能效分析工具。在我们工作中，绝大部分的软件都是由多人合作完成的，让自己负责的模块功能更可靠，更稳定，更完善是很有必要的，那么单元测试就是一个很不错的解决方案。教材中通过给我们展示了单元测试的具体案例，让我们更清楚的理解了单元测试的必要性以及具体过程。而回归测试，效能分析教材中也通过具体的例子与流程清楚得讲述。在阅读得过程中，有一段话引起了我的疑惑。
”啊超：再写技术模块得规格说明书时，要越详细越好，最好各项要求都可以表示成一个单元测试用例。“
这一段话让我产生了疑惑：1.做单元测试是否要面面俱到，不管该单元简单复杂，都写单元测试？换句话说，简单的单元我们是否可以不写单元测试？
2.在实际工作中，单元测试是否被公司硬性要求的？即在公司工作是否必须写单元测试？
在查阅相关资料后，得知，单元测试，是在计算机编程中，针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。
对于为什么要进行烦人的单元测试，可以看一下这篇博客：https://blog.csdn.net/happylee6688/article/details/37962283?utm_source=copy
博客中有提到，在日常的开发中，代码的完工其实并不等于开发的完工。如果没有单元测试，那么如何保证代码能够正常运行呢？测试人员做的只是业务上的集成测试，也就是黑盒测试，对单个的方法是没有办法测试的，而且，测试出的 bug 的范围也会很广，根本不能确定 bug 的范围，还得去花时间来确定 bug 出在什么地方。难道这就不浪费时间了吗？甚至，这样的方式，时间浪费的会更多。
所以，进行单元测试是很有必要的。
但是我仍然有疑惑：简单的单元我们是否可以不写单元测试？在公司工作是否必须写单元测试？
第三章：软件工程师的成长
在第三章中，作者给我们讲解了关于软件工程师的成长，主要讲到了对于软件工程师能力的衡量，软件工程师思维的误区，软件工程师的职业发展等。并且详细讲解了对于软件开发工作量和质量的PSP。以及对于软件工程师的思维误区，1.分析麻痹 2.不分主次，想解决所以的依赖问题 3.过早优化 4.过早扩大化/泛化。接着是对于软件工程师的职业发展，首先分析了人们对于职业的态度，划分了几个等级。接着是对于职业的发展道路，进行了各种不同方向的分析。在阅读的过程中，有一段话引起了我的疑惑。
”没有人能在学校里掌握所有”将来会用到的知识“才离开学校，随后马上把技术运用在实践中，工程师应该在实践工作中不断学习和不断成长，根据自己的情况选择在哪个方面追求”专和精“ “。
对于该段文字我有一点疑惑：如果说在学校的学习还没有达到实践工作的水平，那么招聘时，企业对于应届生的能力要求是怎么样的？企业招聘应届生时，一般会希望到达什么水平？
在知乎中看到了一些回答，主要归于一下几点：技术水平：合格：有一门熟悉的编程语言，备完整的计算机基础知识体系(如操作系统，计算机体系结构等)，能在指导下完成项目的功能的正确实现。优秀：能有几门熟悉擅长的编程语言(如C++, Python等)，具备完整的计算机知识体系观，具有融汇贯通的能力，如能把操作系统，计算机体系结构等课程知识串联起来。能在指导下完成项目的功能的正确实现，并且能进行一定程度的优化，使其运行更加的高效。大牛: 能有几门熟悉擅长的编程语言，并能追寻背后的实现与原理，如C++的内存对象模型，STL的实现及其原因(如vector自动增长因子的设置理由)，编译器如何去实现的等。具有完整的知识体系观，不仅能在理论上融汇贯通在一起，还能有实际动手能力。如修改开源指令集RISC-V，能知道修改LLVM编译器来支持实现修改后的RISC-V指令，并能延伸拓展使用QEMU编译运行新的修改后的RISC-V指令集的Linux操作系统。其也能在指导下完成项目的正确实现，并能进行优化，使其运行更高效。与此同时，包括但不限于会更加思考代码的维护性，扩展性，可衡量性(如单元测试)等问题，并能在项目本身提出后续的改进与演进的方向。
来源：知乎
企业视角：99%的应届生没办法在校期间有过真正的商业项目经验。也许读过不少open source，但…因此我们面试应届生的时候，主要是考察他的专业课水平和思维模式。所以如果专业课挂科，或即使不挂课，却一问三不知的人。即使号称C或C++精通，也通常会我放一边。可能大多数人都没意识到，应届生真正的核心竞争力，并不是在于那一鳞半爪的项目经验，而是理论造诣。当一个应届生被放到商业项目组时，理论课水平高的人，可以很快就能掌握新的语言、平台、框架，并吃透项目的设计，很快就能接手维护代码甚至参与开发。相反，那些理论课挂课的人，虽然看过很多open source，最多也只能照猫画虎，甚至还画不出来，只能 ctrl c + ctrl v 然后改改变量名和函数名。另外，如果从导师的角度来看，一个理论知识扎实的跟班，会让人顿时心生喜爱，会有把他培养成项目骨干的冲动。而理论知识稀松，参加项 目例会跟不上节奏的人，通常会被摆在维护组一摆就是几年。 再说了，理论知识扎实的人，自我学习能力都不算差，看资料看得懂，看论文看得懂，把他丢进项目组之后，他会知道自己应该看什么书，应 该问什么问题，而不是像个傻瓜一样，事无巨细都去问自己的导师。这种差别往往决定了导师会不会把真正的核心知识教给你。
链接：https://www.zhihu.com/question/284111737/answer/494587065
来源：知乎
在第四章中，主要讲到关于代码规范，代码复审，结对编程，两人合作的技巧等。在代码规范中主要讲到关于代码风格的规范，如缩进，分行，注释，命名等。代码设计的规范，如函数，类等。而在代码复审中，主要讲到为什么要做代码复审，怎样做代码复审等。结对编程则讲到，为什么要结对编程，如何结对编程等。两人合作的技巧则讲到，影响他人的方法等。在阅读的过程中，有一段话引起了我的疑惑。
”结对编程是个渐进的过程，有效率的结对编程不是一天能做到的。结对编程是一个相互学习，相互磨合的渐进过程。开发人员需要时间来适应这种新的开发模式。一开始，结对编程很可能不比单独开发效率更高，但时在度过学习阶段后，结对编程小组的开发质量，开发时间通常比两个人单独开发有显著的改善。“
对于该段文字我有一点疑惑：一个好的结对编程应该是怎样子的？结对编程的两个人，是应该选择水平相近的，还是一个能力较好带一个能力较一般的？
在一些博客中了解到，效率相近的两人结对通常会比差距较大的效果更好。原因可能是由于开发人员有更多共同点，这等于即时“无代价”的情感沟通，有助于他们增进交流。这点在矩阵中的位置是十分清晰的。本质上，强强联合能够产生更好的化学反应。他们了解并尊重彼此，能够经常交换意见，互相帮助学习。其结果往往是令人满意而且相互受益的互动。当然也会有很多乐趣。
而两个低级程序员时，收获可能更多。可能因为低级开发者并不一味坚持主见，他没有强大的自尊心影响，与“正确性”相比，他们更加关心学习。
当两个低级程序员结对，他们的主要目标应该是学习。
而当两个高级程序员结对时，往往有相同的原因导致他们很难良好配对。每个程序员都是不同的，都有不同的主见。经验更多，会有更强的个人主见。而且，当你知道得越多，越有可能自尊心膨胀。当一个人有很强的自尊心时，搭档可能会屈从于一个拙劣的决定，原因可能是没有安全感，或者是因为他“小心行事”，确保他们不会伤害到搭档的自尊心。更糟糕的是，结对双方都有很强的自尊心。在这种情况下，他们争论（不是辩论）许多问题，整个氛围由于敌意变得紧张。
优秀的高级程序员结对会彼此尊重对方。他们会谈论许多。他们辩论、讨论、做计划。他们以专业的水准在工作，而不是仰仗个人。这才是美妙的事情。这时公司能够从高产出中获得极大的收益。
当两个高级程序员结对，主要的目的就是生产。