阅《构建之法》1——5章
这个作业的要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178。
在这个愉悦的国庆小长假，我仔细阅《构建之法》1-5章，对软件工程这门课有了全新的认识。在阅读过程中我产生了一些疑惑，并对问题进行多方查询，有了自己的见解和分析。
第一章
飞机的安全功能，乘坐飞机时，你会看到乘务人员不厌其烦地给你介绍飞机有几个出口，如果氧气罩自动掉下来，应该怎么做。你身下的坐垫是可以漂浮的，飞机还可以在水面上降落，逃离飞机的时候应该怎么跳到气垫上……但是，没多少人使用过这些功 能？如果你买了一张特便宜的机票，登机时，乘务员说‘为了节约成本，本次航班没有那些安全设备，没关系的，反正大家也不会用到......’你还敢坐么？若我是本飞机的乘员，毫无疑问，马上离开飞机。有些事情并不是概率低不会发生就此放弃，不同于爱好者，可以不断改善未考虑的问题，而商用的飞机着实考虑乘员的生命安全，并不能忽略。例如，一栋摩天大楼，认为消防措施很完美了，认为单独提供电源的电梯，和许多电梯来提供安全通道，但事实上还是不够安全的。1.1节通过三个简短的对话，启发我对什么是程序，什么是软件，什么是软件工程，也了解到了一个软件不是简简单单就能说写就写的，还需要考虑各种因素，如人们的需求，功能的可行性。1.2节详细的给软件工程下定义，介绍软件工程的特殊性，介绍软件工程中的“工程”的由来，讲述了软件工程与计算机科学的关系，告诉我软件开发中应用工程化原则的重要性。软件=程序+软件工程。虽然这看上去是1+1的关系，《构建之法》的第一章中，对于软件工程的概念解释是：软件工程师系统的，有序的，可量化的方法应用到软件的开发，运营和维护上的过程。软件工程包括下列领域：软件需求分析，软件设计，软件构建，软件测试和软件维护。软件工程和下列的学科相关：计算机科学，计算机工程，管理学，数学，项目管理学，软件人体工学，系统工程，工业设计和用户界面设计。软件工程的覆盖面之广和复杂程度也是可见一斑。软件工程的目标是——创造“足够好”的软件，在书中基本意思是，能满足客户的需求，可靠，可维护等方面有质量的软件。
第二章
第二章讲的是个人技术和流程，最吸引我的一句话是：“你的RP是由你的程序质量决定的。软件是由多人合作完成的，不同人员的工作相互有依赖关系。”这让我发现好的单元测试才能准确、快速地保证程序基本模块的正确性，同时，单元测试能帮助程序员记录模块的历史的设计变更的理由。单元测试很重要，并不是玩玩的。好的程序总是要在最低的功能上验证程序的正确性，正如很多软件他们的源代码是在最低的版本上编写的，便是为了能够在任意版本上兼容。虽然在功能上可能会比较不方便，但很多地解决了兼容问题，毕竟现在科技高速发展，人们总不能预计信息发展的速率，因此，在最低的功能上验证程序的正确性是最明智的决定。好的单元测试必须由最熟悉代码的人或程序的作者来写，代码的作者最了解代码的目的、特点和实现的局限性。转而到回归测试，我们在验证新的代码的时候改正了自身的缺陷，同时也需要验证新的代码有没有破坏模块的现有功能。在修复bug的同时，也应当要注意做容错处理，这样才能做出一个好的程序，回归测试最好要自动化，因为这样就可以对于每一个构建 快速运行所有回归测试，以保证尽早发现问题。 单元测试是回归测试的基础。只有不断测试，不断完善，才能做出更好的软件。
第三章
无论是学习还是工作还是一些兴趣爱好，从第三章中的感受比较多的是凡事都需要坚持。敲代码如画画一般，都是一门艺术，修修改改，从一个丑陋的框架到美观壮丽的细节，无论怎样从开始到最后甚至一辈子都可以为之感兴趣的兴趣的艺术。我写代码的时候会通过学过的语言结合相关的相似的修改成自己想要的程序。在我眼里，程序都是一样的，都是通用的，没有好程序与坏程序之分。在每一个程序员精心编辑下，每一段程序代码都有它独特的意义。可以说，编程的过程本身就是一门艺术。中国，软件工程师的职业资格考试有：计算机等级考试和全国计算机技术与软件专业技术资格考试。考证通过了，而考试“以答题/评分为主要考试形式，没有面对面的考察；考试中每个人单独行动，不能考量团队合作能力；要考虑到通用性和稳定性，考题内容相对滞后于工业界的发展，部分内容相当滞后”。那么参加考试的人是否轻松应用在实际项目开发中呢？
第四章
规范代码很重要，代码是给人看的，不是给机器看的，从代码的风格规范到设计规范，在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平比较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。不同的性格、不同的代码习惯会有不一样的风格。代码规范差异太大会影响团队的合作。代码的缩进排版风格完全没有必要统一，前提是你的团队成员都使用了有高级代码格式化功能的IDE，并且项目版本库设置了提交前自动格式化代码的hook！试想一下，你将自己的IDE配置成自己喜欢的排版风格，然后打开代码文件时，IDE都自动将代码重新格式化成你的prefer风格；你编辑好代码保存之后，提交到版本库，比如Git或Hg，并且在版本库上设置了一个before commit的hook，对所有要进入版本库的源代码都按照一个统一的排版方式重新格式化后再提交到版本库。这样，每个人都可以使用自己喜欢的代码排版方式Coding or Review，也不会影响其他人。所以，是不是代码风格没有太大影响，代码不规范才会影响呢？
第五章
接力赛和赛龙船可以看出，团队有共同的特点：团队有一致的集体目标，各有分工，相互依赖，共同完成任务。团队跟个人的关系——团队是由个人组成的，个人离不开团队，团队又依赖于个人，个人与团队是相互依存的两个实体。每个人都有每个人的优点，取每个人的长处，改进每个人的短处，这样就可以更快地做出更好的程序了。但在这里，从瀑布模型开始的各种模型都有一个共同点：重计划，重事先设计，重文档表达。这一类的方法中集大成者要算Rational统一过程。RUP把软件开发的各个阶段整合在一个统一的框架里我有一个疑问，瀑布模型跟原型模型都有它的特点——瀑布模型需求明确但不实用，原型模型实用但需求分析不明——我们应当怎样选择不同的开发流程才能开发出适应时代的软件呢？
