软工个人阅读作业#2

项目 内容
这个项目属于哪个课程 2021春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里 个人阅读作业#2
我在这个课程的目标是 提升个人的软件工程能力和团队意识
这个作业在哪个具体方面帮助我实现目标 学习软件工程相关内容,熟悉常用的工具

Part 1 提问

Q1:关于商用软件和爱好者写的程序的区别

​作者在文中提出:

​ 说到商用软件和爱好者写的程序的区别,我们还可以看看这个例子:

​ 如果一架民用飞机上有一个功能,用户使用它的概率是百万分之 一,你还要做这个功能么?

你会选择: 1. 根本不考虑

  1. 如果没时间实现这个功能就算了

  2. 做了,但是不用告诉用户

  3. 做了,而且不厌其烦地告诉用户如何使用 你会如何选择呢?

    选择之后,这个功能究竟是什么呢?谜底是飞机的安全功能

作者想要强调商用软件和爱好者写的程序中最主要的一个区别就是商用软件会考虑一切用户可能用到的功能并加以实现,然后教用户如何使用。

​但是拿飞机上的安全功能来举例似乎有些不妥,首先飞机的安全功能之所以重要是因为它会涉及到乘客的生命安全,即使飞机出事的概率很小,但是出事后的风险很大,这样一来飞机上的安全功能就显得极为重要。

我感觉真正对于一个商业软件来讲,需要实现的部分应该是该部分内容在软件中的重要性,而作者在原文中写的这一段话却似乎在强调使用概率这一点,让我有点困惑。

Q2 关于单元测试

作者在文中提出:

单元测试必须由最熟悉代码的人(程序的作者)来写。代码的作者最了解代码的目的、特点和实现的局限性。所以,写单元测试没有比作者更适合的人选了。

​作者是最熟悉代码的人,但是这可能也会导致作者会无法对自己的代码做出全面的审查。一直以来有句话叫“当局者迷,旁观者清”,作者可能会因为正是自己写的代码,导致无法看清自己代码的全貌,从而无法对一些复杂的模块写出完整的单元测试。

​作者后续又写道:

单元测试不能解决所有问题,不必期望它会发现所有的缺陷。

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

​单元测试只是一个覆盖测试,让旁观者来从旁观者的思路把代码重新梳理一遍后写出的单元测试可能会有不一样的效果吧。

Q3 关于goto语句

​作者在文中提出:

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

​goto语句一直是有争议的话题,在过去编程学习的时候就被老师和助教一直提醒要少用goto。在网上查阅后得到:

主张从高级程序语言中去掉GOTO语句的人认为,GOTO语句是对程序结构影响最大的一种有害的语句,他们的主要理由是:GOTO语句使程序的静态结构和动态结构不一致,从而使程序难以理解,难以查错。去掉GOTO语句后,可直接从程序结构上反映程序运行的过程。这样,不仅使程序结构清晰,便于理解,便于查错,而且也有利于程序的正确性证明。

​但是同时也说到:

尽管如此后来的c#还是支持goto语句的,goto语句一个好处就是可以保证程序存在唯一的出口,避免了过于庞大的if嵌套

​和文中一致。

​于是最后有人采用了折中的说话,提出不加限制的goto语句会导致程序难以预测,但是有些时候却能让程序更加简明清晰、提高程序效率。我的问题是:对于我们这些编程的新手来说,又该如何判断什么时候该用goto语句呢?这些表面上看起来让程序更加清晰的goto语句是否会在程序中埋下一些隐藏的危险呢?

Q4 关于结对编程

​作者在文中提到:

在结对编程模式下,一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起工作。他们一起分析,一起设计,一起写测试用例,一起编码,一起单元测试,一起集成测试,一起写文档等。

​同时,作者也提出了结对编程的疑问和好处。关于疑问中的“ 我习惯一个人写程序,不喜欢被人盯着工作,这样我不自在,无法工作”这一点我深表赞同。同时,我感觉每次我高效编程的时候会进入某种状态,能让我全身心的集中在眼前的屏幕上,周围人的打扰反而会让我脱离这种状态。

​当然我目前还没有经历过结对编程,只是对于是否所有人都适合进行结对编程,结对编程对于效率真的能比其他的合作方式来的高吗表示疑问。

Q5 关于创新

​作者在文中提到:

最近几年,我们整个社会似乎对创新很感兴趣,媒体上充斥了创新型的人才、创新型的学校、创新型的公司、创新型的城市、创新型的社会,等等名词。有些城市还把“创新”当作城市的精神之一,还有城市 要批量生产上千名顶级创新人才。

​就如文中所说的,创新是我们这个时代和社会所需要的,虽然人人都能进行创新,但是能创造出有价值的“新”的真的不多。文中也提到了一大堆对于创新反对意见,其中夹杂着很多乱七八糟的个人情绪、政治因素在里面。同时,受限于当今社会膨胀的信息量和个体有限的阅历,创新的难度似乎也因此越来越大了。我之前看到一句话,类似是说:“每当你想到一个非常棒的能改变世界的idea,那只能说明你看的paper还不够多”。虽然是一句带点玩笑意味的话,但也说明了目前创新的一些尴尬局面。

​近年来,创新的实例很多,但是真正在我们生活中留下痕迹的idea,和庞大数量的创新者相比,真的很少。对于我们这些普通人而言,在创新的要求越来越高的当下又该怎么做呢,一昧地鼓吹创新真的好吗。

Part 2 调研源代码版本管理软件

​这里主要关注GitHub和GitLab之间的异同。

​相同点:GitHub和GitLab都是基于Git开发的产品,二者都提供了分享开源项目的平台,为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所。同时,由于都依托于Git,两者都具有拉取请求、代码审查、内联编辑、问题跟踪、Markdown支持、双向认证、高级权限管理、托管的静态网页等功能。

​不同点:

  • GitHub 是第一个供“用Git进行版本控制系统的软件开发项目”使用的基于Web的代码托管服务,是目前全球最大的开源社交编程及代码托管网站。GitHub 于 2008 年 4 月 10 日正式上线,除了基本的服务以外,还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱(报表)、代码片段分享(Gist)等功能。
  • GitLab 是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托管的 Git 项目仓库,可通过 Web 界面进行访问公开的或者私人项目。

Part 3 调研持续集成/部署工具

GitLab-CI

​以之前OO的pre2task1为基础,重写成maven工程形式,代码仓库

​提交到gitlab上后的效果:

GitHub Actions

​代码同Gitlab-CI,仓库地址

​运行Actions后的结果如下:

使用CI/CD工具后的感想

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发的问题

​在使用CI/CD工具的时候,我们可以将众多的流程提前预设完毕,让包括简单的单元测试在内的一系列操作能够在push代码之后自动化完成,对于持续集成开发提供了相当大的便利。

​相比于GitLab-CI,GitHub Actions对于.yml文件的要求更为严格,但是GitHub Actions提供了丰富的Market,能够让我们直接调用很多现成的Actions,这点十分便利。

posted @ 2021-03-16 20:22  yokies  阅读(123)  评论(2编辑  收藏  举报