第3次作业：阅读《构建之法》1-5章

作业要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178

第一章 绪论

第一章关键字：软件工程、开发过程、领域

       上个学期课程开篇就提及了“软件危机”的典型表现，即书中的第一章的1.2.1节对应的软件开发过程中有什么特殊的难题？结合上学期的内容与书中的内容，以本人的不全面的理解— —软件危机的一些表现为：

1.    开发过程中的复杂：功能实现的复杂（无法满足用户的需求）、各个模块之间依赖关系在开发过程中，关系的数量与开发时间成正比，其中还需要注意各个模块之间能够做到高内聚低耦合等；

2.    软件的质量难以保障：软件的可靠性无法保障、软件是否符合用户（市场）需求；

3.    软件常常难以维护：与书中的“易变性”、“不可见性”难题相对应；

       以上三点是本人的一些理解，可能存在一些片面的概述。这几点与书中提及的“复杂性”、“不可见性”、“易变性”、“服从性”的意思相差不大。其中，书中所提及的第5个难题— —“非连续性”的解释我不太理解，相关的资料解释也寥寥无几。“有时输入上很小的变化，会引起输出极大的变化”是指一个输入会产生多个不同的输出吗？

 

第二章 个人技术和流程

第二章关键字： 测试、效能

        单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。通常，单元测试和编码属于软件过程的同一阶段。对于初学者来说，在刚开始打代码的过程中，完成一个程序， 找bug并且修复bug就是“单元测试”最简单粗暴的理解。

       在找bug的过程中，数据的处理至关重要。例如：对函数abs()，就需要编写几个测试用例：考虑到正数、负数、0与非数值型类型这四种情况，而将这些测试用例放在一个模块里，那么这就是“单元测试”[1]。又有：对数组的处理需要考虑到临界条件以及是否溢出等测试用例。

       书中2.1.2节提到“单元测试应该覆盖所有代码路径”— —按照我本人的理解是考虑到所有会出现bug的可能性。那么在编码的过程中，我们需要考虑到哪些bug或者是在测试的过程中需要测试哪些内容，完成编码的完整性，保证模块的质量？本人翻阅资料知需要考虑几点内容：结果是否正确、所有的边界条件是否都是正确的、使用反向关联、用其他手段交叉检查一下结果、强制产生错误条件[2]。可以通过这几点来测试，尽可能地发现多的执行路径，确保所有的单元测试都能通过。

 

第三章  软件工程师的成长

第三章关键字：个人团队、思维误区、职业技能

       书中3.2节提到软件工程师的误区有分析麻痹、不分主次，想解决所有依赖问题、过早优化、过早扩大化、泛化。其归根结底是没有对整个软件进行完整的定义与开发设计。软件生命周期由软件定义、软件开发和运行维护3个时期组成。

       事实上，对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。对问题和目标的正确认识是解决任何问题的前提和出发点，软件开发同样也不例外。急于求成、仓促上阵，就犹如不打好地基就盖高楼一样，最终必然垮台。事实上，越早开始写程序，完成它所需要的时间就越长。

第四章  两人合作

第四章关键字：代码规范、代码复审、两人合作

       代码规范虽然不涉及技术层面，但是好的代码从规范做起。一般来说，代码规范主要考虑到可阅读性强：简明、易读。代码排版舒适、命名有意义、注释明了、模块独立单一等都是代码规范的内容。特别是缩进与命名问题是需要注意的：使用或括号与缩进、分行会阅读得更舒适；函数命名用动宾组合词，每个单词第一个字母都大写，变量命名使用骆驼法则：矮高矮高（第一个单词全小写，后面的单词的第一个字母大写）。

       一般情况下，代码复审者（测试员）与程序员最好不要是同一个人。两人合作的结对编程— —一人写代码，一人复审，交替进行。结对编程使两人的代码不断地进行复审，提高设计与编码的质量，能够及时发现并改正错误。

 

第五章  团队和流程

第五章关键字：团队模式、开发流程

        一个项目需要一个团体的合作，就如上章所说的一个软件由一个人单枪匹马完成，已经很少见了，软件都是在相互合作中完成的。如今的项目团队，会有许许多多的分工，进而出现多种不同类型的工程师— —这些工程师都是由一个个个体组成。软件团队是由个人组成的，然后个人组成团队。

       软件团队模式有各式各样，他们之间的关系在一定程度上促进了团队的发展，当然有利必有弊。我认为功能团队模式是一个比较好的团队模式。如书中所说，将具有不同能力的同事共同协作完成一个功能，多人合作可提高设计与编码的质量，查漏补缺完成功能（功能团队模式与结对编程类似，只是功能团队模式是针对整个项目而言，而结对编程针对某个功能模块），当完成这一个功能，则可解散重新组队进入下一个功能。功能团队模式促进了团队间的的交流，及时发现问题与修正、同时可完善与合理地扩充功能，满足用户的需求。

       书中5.3节的开发流程提及了“写了再改模式”、“瀑布模型（子瀑布模型）”、“Rational Unified Process统一流程（RUP）”、“老板驱动流程”、“渐进交付的流程”这几个开发流程。从上个学期学习到的软件过程中，书中的“渐进交付的流程”与“快速原型模型”思想相同。“快速原型模型”的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机使用它，通过实践来了解目标系统的概貌。“渐进交付的流程”的具体做法是把产品最核心的功能用到最小的成本实现，然后快速征求用户意见。但是本人第一次看到这个名词时会与“增量模型”的内容弄混淆。“增量模型”是分批地逐步向用户提交产品，整个软件被分解成许多增量构件，开发人员一个构件接一个构件地向用户提交产品[3]。本人认为“渐进交付的流程”的字面意思与“增量模型”思想一致，所以会导致这样的理解误区。

 

[1]https://www.liaoxuefeng.com/wiki/001374738125095c955c1e6d8bb493182103f

ac9270762a000/00140137128705556022982cfd844b38d050add8565dcb9000

[2] https://blog.csdn.net/potatostyles/article/details/79177163

[3]张海藩，牟永敏.软件工程导论（第6版）.北京：清华大学出版社.2013