软工小白的第二次软工作业

项目	内容
这个作业属于那个课程	2021春季学期软件工程（罗杰、任健）
这个作业的要求在哪里	个人阅读作业#2
我在这个课程的目标是	和团队成员一起成功开发出一款具有实用性的软件，了解软件开发的流程并掌握软件开发过程的
这个作业在哪个具体方面帮助我实现目标	通过提问的方式快速阅读教材，对软件工程有一个基本的认识。学习CI/CD工具的使用，为之后的开发做好准备。

阅读提问

笔者所阅读教材为：《构建之法》——邹欣（第三版）

Q1: 教材P27

单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。为了保证代码覆盖率，单元测试必须测试公开的贺私有的函数/方法。

书中提到单元测试应该覆盖所有代码路径，由此我有一点疑惑是如何提高单元测试的覆盖率（尤其是对于经验不足的新人）。这篇博客提到常用的代码覆盖度量有语句覆盖、判定覆盖、条件覆盖、路径覆盖几种。根据我不多的测试相关的经验，感觉一开始很容易将语句覆盖作为衡量的标准，语句覆盖率实际上并不能真正达到我们想要的测试效果，路径覆盖才是最强力的测试依据，但是当代码的分支和嵌套比较多时，路径覆盖所需的样例数量会变得非常多，那么在这种情况下我们只能通过人力进行排列组合吗（是否有相关的工具可以使用）？或者我们应该考虑的是对代码的结构进行优化？

Q2: 教材P37

回头看我们在第一章提高的软件的特殊性，可以看出这些题目缺乏两个基本的要素：复杂性和易变性。我们提到，程序=算法+数据结构与；软件=程序+软件工程。软件工程的编程作业，不仅仅是程序，而是要加入软件工程的要素（复杂性、易变性和其他），有价值的软件工程的作业必须要触及这两个基本要素。

针对这一段话我有几个疑惑。

首先复杂性和易变性是软件的基本要素。假设有一个客户有一个明确的需求，开发一款仅支持四则运算的计算器，在我看来这是一个需求十分明确，而且也并不复杂的软件（但不可否认的是开发过程也有可能存在没预想到的困难）。那么这个计算器的开发就不需要运用软件工程的相关方法来辅助了吗？

其次我十分赞同有价值的软件工程作业需要满足复杂性和易变性。但是在操作时可能会遇到以下困难：

在选题时可能会因为功能的复杂导致不敢轻易选择，很有可能最后还是选择了自己能实现的功能而不是更有实用价值但可能需要一定的学习才能实现的功能。出现这个问题的原因我想主要是因为在考虑需求的时候往往会不由自主的思考需求背后的技术问题，最后就不变成了技术驱动需求而非需求驱动技术了。
在软件开发的作业中，我们实际上不仅扮演了乙方，也扮演了甲方。那么在需求提出的时候，我们往往会不自觉的提出甲方（实际上也是我们自己）所想的需求。这样的需求往往不会有很大的变化，那么易变性又从何谈起？

所以我的疑惑在于怎么能够提出有价值同时是我们的团队能够高质量完成的选题？

Q3: 教材P48

分析麻痹：一种极端的情况是想弄清楚所有细节、所有依赖关系之后再动手，心理上过于悲观，不想修复问题，出了问题都来在相关问题上。分析太多，腿都麻了，没法起步前进，故得名“分析麻痹”。

通过之前几年的实践，我发现理想和现实的差距往往会很大。比如在编译技术的大作业中，我提前计划好了要如何组织不同的文件和函数。但是在实际的操作过程中，由于之前没有想到的问题（或许是没有正确衡量一个功能的难度，或者是coding的太嗨就没顾上之前的设计又懒得重构等）。最后的成品和理想中完全不一样。对于软件工程的作业来说，我想可能会存在更多的不可控因素，那么如何合理的提出预期的计划呢？或者说最后的成果与计划如果存在一定的偏差的话，是否有一个范围是我们可以容忍的（就像物理实验中的误差）？

Q4: 教材P69

函数最好有单一的出口，为了达成这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以用，包括goto。

在这里我的疑惑主要在于在我大一的C语言课程中，对goto的态度是尽量不能不要使用，容易造成程序结构的混乱，使得程序难以理解和维护。在我的实践中，实际并没有使用过goto语句。我认为出现这种矛盾的原因是两本教材面向的人群不一样吧，一个成熟的程序员应该可以很好的掌握语言的特性方便开发。那么我应该如何合理的定位自己的能力水平呢？

Q5: 教材P131

阿超：这样做有什么好处？好处有两点：

（1）被授权的人会承担起自己对项目的责任，同时也期望同事们也同样对项目负责；

我的疑惑在于这样的表述是否过于理想化，仿佛成员得到授权之后就能自然承担起自己对项目的责任。本人虽然开发工作做得不多，但是做了很多的学生工作，从我的经验来看，能否把工作做好和得到充分的授权不是充要条件的关系，做好工作需要得到充分授权但不意味着得到充分授权就能做好工作，项目也是一样。我任务做好项目的驱动力在于个人对工作的重视程度和责任心。这种重视态度可能来于自己本身、负责的组长、课程的压力等。所以我并不十分认同上面的那句话。

Q6: 教材P173

软件工程师在长期的实践中，摸索出一套经验公式：实际时间话费主要取决于两个因素——对某件事的估计时间X，以及他做过类似开发工作的次数N。

$Y = X \plusmn X / N $

从公式中不难看出，如果一个人从来没有做过类似的工作，那么估计时间将会是无穷大。书中接下来也提到，从来没有做过网站的用户管理模块的果冻，在项目时间内压根做不了这个模块。这样来说，可能很多同学都没有做过完整的软件，那么在项目时间内根本做不完，那又如何是好呢？但是这种情况根本不会发生，我相信绝大多数的同学还是能在项目的规定时间内完成任务的，只不过过程可能痛苦了点或者质量低了一点。所以估计时间的时候难道不应该将人的学习能力也作为考量的指标吗？简单的除0似乎过于粗暴了。

源代码管理软件调研

本人主要使用过的源代码管理软件有github和gitlab,，因此主要针对这两款软件进行比较。

相同点：github和gitlab基于web的git仓库，二者都支持对源代码进行存储和版本控制、支持markdown编辑、问题跟踪等。

不同点：

gitlab允许免费设置仓库权限
github只支持本地服务器的个人github，gitlab可以搭建团队的gitlab供团队使用
gitlab允许用户设置project的权限

持续集成/部署工具调研

该网页对GitLab CI和GitHub Actions的异同做了一定的对比分析。

Gitlab CI与gitlab的工作流程直接集成，并提供了多种API供用户使用。GitHub Actions的特别之处是它提供了一个市场，可以选择他人编写的actions进行使用，合理利用的话可以减少开发人员的工作量。除此之外，GitLab CI在CI -CD管道中内置有安全扫描，GitHub Actions则需要安装插件。

我的使用感受是Gitlab CI配置写起来比GitHub Actions更加容易，因为Gitlab CI的配置相对来说更加直观。在我实际的编写过程中，使用GitHub Actions开始遇到了困难，后来认真查阅了GitHub的官方文档找到了对应的模版才成功解决（这也体现了模版的好用）。