软件工程第一次作业

文章概要

项目	内容
北航22春软工	课程社区
作业要求	作业要求
我在这个课程的目标是	学习软件工程的相关知识，从整体上了解软件开发的流程与内容，并亲身实践参与到其中，提高自身的开发水平
这个作业在哪个具体方面帮助我实现目标	从整体了解软件开发的流程与内容，角色分工等，重点了解了敏捷开发相关的知识

阅读提问

1 现代软件工程讲义 2

软件设计工程师们在做代码复审的时候，是看“重复字”的多少, 还是程序的艺术性?

在阅读到这里的时候，结合前文提到的诗句评审，我个人仍对于普适的代码的”好与坏“标准不是很明确。我个人感觉所谓”重复字的多少“指的应该是程序的冗余程度，而”艺术性“指的是代码的新颖程度。如果是这样的话，个人感觉在软件工程领域，程序的正确性与安全性才是第一要素，而”艺术性“的代码很难满足上述条件，也就是我们应该优先考虑更加朴素的方法来实现需求？

2 技能的反面-魔方和模仿

那怎么才能考察出一个人“精通”魔方呢? 我想了这样一个办法:
a)   给面试者一个各面打乱颜色的魔方
b)   要求他把六面还原
c)   如果还原了, 要求他把魔方恢复成我最初给他那个混乱的局面, 必须一模一样。 
精通魔方的同学, 来吧。

这里的c选项该如何去理解呢？前文所提到魔方的最高层次为”能够设计出新型的魔方，或者创新的玩法“，但是这里还原为最初的局面似乎与创新或者熟练掌握魔法技巧无关。

3 软件工程 敏捷的酒后问答

要记住, 有许多最佳实践在各个开发方式下都在使用， 所以各个开发方式并不是井水不犯河水, 老死不相往来的那种关系.

对于这句话的理解应该是在软件开发的过程中，不同的模块可以采用不同的开发方式，还是不同的阶段采用不同的开发方式呢？如果是前者，我们该如何在项目开始前对不同的模块进行分类（比如通过需求分析来确定），而如果是后者，敏捷是否可以在某种程度上视为不断更改计划的计划驱动类型开发？

4 现代软件工程讲义4 Scrum/Sprint

Self-managing: 以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次sprint 结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自我管理”不等于“没有管理”
Self-organizing: 以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
cross-functional: 以前spec 由PM 来写, test 由测试人员来做, 现在每个人都全面负责，自己搞定spec, 和别人沟通, 同时自己搞定测试。

此处讲到要想实现Scrum的模式，需要每个人都进行自我提升并进行全面负责，这种方法在现实中如何落实呢？因为每个人在项目中负责不同的内容，若想要进行全面负责势必要投入大量的时间，很有可能影响到项目进度，同时产生分工不明确的情况。

5 现代软件工程讲义7 用户界面和用户体验

文章中提到了用户体验与产品质量冲突时的选择

1990年代, 韦尔奇注意到核磁共振机器的通道特别狭窄， 在长达几十分钟的检查过程中, 病人常常有得了幽闭恐惧症的感觉。 杰克做过类似的检查, 深有体会。他问, 能不能把通道做得大一些?  专家说那样会降低扫描成像的质量。
他又问, 对于那些不需要太多精度的检查, 能否牺牲一些成像质量, 换取用户的良好体验呢? 专家说, 他们会考虑的… 然后就没有下文了。
不久, 日本的日立公司推出了宽通道的扫描设备, 并夺取了大量的市场份额。 GE 被动迎战, 花了两年时间才赶上对方。

对于硬件设备来说，根据用户体验来更改产品是一件较为困难的事情，但是对于软件来说，自选模块组成自己想要的软件似乎相对简便。以微信为例，我在日常使用微信时，所用的功能在绝大部分情况下只有微信聊天，公众号以及朋友圈，而其他功能例如购物等从来没有使用过。我们在进行开发时，是否可以实现一个功能高度自由化的软件，根据用户的需求进行选择。例如大部分代码编辑器就可以自选所需的内容。目前所使用的手机软件采用这种模式的较少，常见于PC端的工程类软件，其原因是什么呢

6 需求分析 项目建议 NABCD

文章中提到了B(benefits)与C(Competitors)，即项目构思时应该预先想好对开发者与用户的好处，以及不同项目组之间的竞争

作为小型项目的开发者，B与C在项目设立的初期应该如何去考量，例如B的问题，对于没有宣发优势的小众软件，是否应该先不考虑对于盈利的需求，而更多关注用户体验。同时考虑到竞争压力，是去更加小众的赛道进行比拼（例如先前从文字阅读领域到视频领域的发展），还是应该在很多已有的成功软件的基础上进行某些特点方向的优化以提供高质量的服务（例如qq到微信的发展）。

源代码版本管理软件

Github, Gitlab, Gitee都是代码托管的平台，都支持git，可以方便地进行版本控制与团队合作，主要的手段为branch与merge，fork与request。

• branch与merge（参考文章）通过branch开启新的分支，例如develop分支，hotfix分支等，不同成员在各自分支中完成工作，随后合并到master分支即可。
• fork与request通过fork获取当前版本的仓库到自己的仓库，本地修改后push到自己的仓库，随后发起request，等待合并。下面就三个平台各自的特点进行简要介绍。

Github

Github是目前最大的平台，其上有最多的资源和开源项目，查询各种资料也较为方便，但是不支持私有仓库。

Gitlab

GitLab有完善的管理界面和权限控制，相比于github私有仓库收费，Gitlab提供了仓库的权限控制，因此一般用于在企业、学校等内部网络搭建Git私服。

Gitee

Gitee是国内的代码托管平台，同样支持私有仓库，但是只支持5人以下的私有仓库，同时平台上的开源项目较少

持续集成/部署工具

Github Action

Github Action采用yaml文件进行配置，其结构如下：

• workflow （工作流程）：持续集成一次运行的过程。
• job （任务）：一个 workflow 由一个或多个 job 构成，含义是一次持续集成的运行，可以完成多个任务。
• step（步骤）：每个 job 由多个 step 构成，一步步完成。
• action （动作）：每个 step 可以依次执行一个或多个命令（action）。

可以设置具体的工作流触发条件，运行服务器，所需的环境等，最后在action的run部分给出要执行的命令。

yaml样例

#持续集成
name: CI
#通过push或者request触发
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

#执行的jobs
jobs:
  #单一任务build
  build:
    #系统
    runs-on: ubuntu-latest

    #Steps
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2
      
      #配置java环境
      - name: set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      #执行测试，输入一个字符串，main函数会将其反转并输出
      - name: test
        run: |
          javac Main.java
          echo "hello world" | java Main  

执行结果

Github仓库地址

Gitlab CI/CD

Gitlab CI/CD同样使用yaml文件进行配置，大体的结构如下：

• pipeline：整体的流程称为pipeline，对应github action中的workflow
• stage：pipeline中的不同阶段，例如build，test，deploy等，对应github action中的jobs
• script：描述每个stage中的具体指令

Gitlab CI/CD与Github action最大的区别在于运行环境的配置，在action中可以如上文所示地使用github自带的服务器，而Gitlab中需要自行配置runner，即Gitlab CI/CD本质上是在自己配置的生产环境中运行。

yaml样例

stages:          # List of stages for jobs, and their order of execution
  - build
  - test

build-job:       # This job runs in the build stage, which runs first.
  stage: build
  script:
    - javac Main.java

unit-test-job:   # This job runs in the test stage.
  stage: test    # It only starts when the job in the build stage completes successfully.
  script:
    - echo "hello world" | java Main

Runner安装与配置
Runner需要在本地进行登记，登记结束会生成配置文件，可以修改runner的参数

修改完成后执行install和start命令即可开启runner

到此理论上应该可以正常运行pipeline，但是此处出现了一些问题，在运行时没有使用自定义的runner，而使用了默认的环境，只有ruby的配置，无法编译和执行java程序。但是根据token可以确定连接到的确实是本机的runner，目前还没有解决此问题。

Gitlab仓库地址

总结

• Github action在一定条件下可以免费使用，对于缺乏生产环境的学生党等人群较为友好，但是其缺点在于环境难以个性化进行定制，主要适用于开源且不涉及隐私的项目。
• Gitlab CI/CD的runner需要自己进行配置，因此比较适合有一定规模的开发，在租借服务器的情况下比较友好，同时一次runner配置即可多个仓库使用，在自己的服务器上运行也更为安全，主要适用于公司和团体等的开发。