北航软件工程 2022 阅读与调研作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2022年北航敏捷软件工程社区-CSDN社区云 |
| 这个作业的要求在哪里 | 个人阅读作业-阅读和调研-CSDN社区 |
| 我在这个课程的目标是 | 见下 |
| 这个作业在哪个具体方面帮助我实现目标 | 本作业主要能让我对软件工程有一个较为宏观的认识，同时了解持续集成/部署工具 |
课程目标（摘自教学大纲）
- 了解和掌握软件工程的基本概念、基本原理和基本方法，以及软件开发的一般过程，树立工程化开发软件的理念；
- 具有通过常用用户调查方法进行需求获取以及需求分析的能力，注重软件创新思维的培养，具有基本的软件计划能力；
- 掌握软件需求规格说明、软件设计说明书的撰写，具有基本的软件系统分析设计能力；
- 具有通过代码规范、代码复审和单元测试等方法来保障软件质量的能力；
- 掌握项目开发计划的撰写，具有运用软件开发过程管理、源代码版本管理、Bug 管理等现代化软件工程支持工具进行项目管理的能力；
- 具有获取和理解新技术、算法和开源代码，并将其应用于软件开发的能力；
- 具有根据规格说明书和实现代码设计测试用例的能力，掌握测试大纲、测试计划、测试总结的撰写，并能够对软件进行功能测试、场景测试、性能测试、压力测试等；
- 掌握在团队内进行沟通和协作的方法，具备团队协作软件开发的实践经验，具有在团队协作中提升和改进个人软件开发技能和团队软件开发能力的能力；
- 了解当前软件工程技术和方法的发展趋势和应用情况，认识软件工程的热点问题，具有持续可发展的能力。
阅读提问
随着课程的进行，对书中内容可能会有更深入的理解和更新的问题，后续也许会有修改和补充。
1. 单元测试必须由最熟悉代码的人（程序的作者）撰写么？
书中第 25 页说：
代码的作者最了解代码的目、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
我认为作者说得太绝对了。程序的作者可能有很多情况都没有考虑到，如果他写单元测试的时候仍然没有考虑到，那就测不出这方面的问题。
2. 不包含调试信息的“Release”版本程序是如何分析效能的？
作者在第 31 页附近以使用即时编译的 C# 为例介绍了基于“抽样”的效能分析方法。但对于直接编译为机器码并经过优化的 C/C++ “Release” 版本程序，有些函数被内联，效能分析程序如何能跟踪栈帧并采样得到函数的调用情况？
3. 如何体现出解决“小问题”的工作量？
作者在第 51 页说：
解决大问题固然让人感觉美妙，但是把小问题真正解决好，也不容易，我们回头看看博客园、CSDN 等 IT 认识云集的网站，每天都有很多宏大的新想法、惊世骇俗的评论冒出来，争论美女/张飞/巨石的重构问题，对一些通用的框架/平台发出一些人云亦云的评论等。这些文字，大多数会转化为墨水，把扇面涂黑，让后人在上面写下金字。
这段话写得很好，但实际情况中，如果只是解决一个“小问题”，老师可能会质疑你的工作量。比如一个三分钟的答辩，评委自然是不会太关心项目的实现细节的，比如你的手册有多详细，代码有多规范，错误处理有多稳健等等。但如果从宏观上看只是解决了个“小问题”，怎么能出类拔萃？
4. 书中介绍的微软的那一套代码规范是否值得推荐？
作者是微软人，当然免不了“夹带私货”。但我感觉 Win32 的代码由于函数的“抽象泄露”和变量的匈牙利命名法是格外的难懂（也有人这么认为但我忘了出处）。ANSI C 风格的代码感觉更为普遍，我也更喜欢。而苹果更是设计了现代的 Swift 语言，让代码就像文档一样易懂。我觉得“代码即文档”能够真正提高效率。
5. 结对编程是否会对效率产生负面影响？
根据个人经历，如果实际写代码的人（“驾驶员”）已经有了清晰的设计，而由于结对过程中，“领航员”要经常提问，在这种情境下“驾驶员”有时也会自言自语，这些对效率可能会产生负面影响，并且未必会随着时间的流逝而消除。
调研源代码版本管理软件
注：以下不区分“版本控制系统”和“源码控制管理”，而统称为“版本管理软件”，尽管它们有些区别。
版本管理软件千千万，我只取 Git 一瓢饮。正如这篇让我第一次接触 Git 的教程所说，Git 接口因抽象泄漏（leaky abstraction）而有些丑陋，但是它的底层设计和思想却是非常优雅的。这个精心设计的基于有向无环图的模型，使其能够支持版本控制所需的所有特性，例如维护历史记录、支持分支和促进协作。由于后续基本只会用 Git 进行版本管理，此处仅列出几个版本管理软件和部分特点。
| 名称 | 类型 | 开源 |
|---|---|---|
| Git (git-scm.com) | 分布式 | 是 |
| Mercurial SCM (mercurial-scm.org) | 分布式 | 是 |
| Bazaar (canonical.com) | 分布式 | 是 |
| Apache Subversion | 集中式 | 是 |
| CVS - Open Source Version Control (nongnu.org) | 集中式 | 是 |
| Rational ClearCase | IBM | 集中式 | 否 |
| Perforce | 应用程序开发解决方案 | 集中式 | 否 |
| BitKeeper | Git 的前身 | 是 |
而基于 Git 又诞生了很多平台/服务，对比如下。GitHub 和 GitLab 的详细对比请见 GitHub vs. GitLab | GitLab。
| 名称 | 开源 | 协作 | 免费计划 |
|---|---|---|---|
| GitHub | 代码开源，平台本身不开源 | find + follow | 允许托管无限的公开仓库，无限合作者，每月不超 2000 分钟的 Actions，500 MB 包存储，项目不超 1 GB，单文件不超 100 MB |
| GitLab | 社区版开源 | find | 不超过 5 人，公私有仓库不超过 1 GB，每月传输不超 10 GB，每月 CI/CD 时间不超 400 分钟 |
| Gitee | 代码开源，平台本身不开源 | find + follow | 私有仓库合作者不超过 5 人，仓库不超过 5 GB，单仓库不超 500 MB，单文件不超 50 MB，附件总容量不超 3 GB |
| Bitbucket | 不开源 | find + follow | 不超过 5 人，仓库数量无限，单仓库不超 10 GB |
调研持续集成/部署工具
一图胜千言，CI/CD 简介见下图。
总体对比如下，GitHub 和 GitLab 的详细对比请见 GitLab CI vs GitHub Actions | GitLab。
| 名称 | 免费 | 可定制化水平 | 图形界面体验 | “一条龙服务” | 方便性 | 面向群体 |
|---|---|---|---|---|---|---|
| GitHub Action | 是 | 较高 | 一般 | 仅 CI/CD | 可复用 | 个人 |
| GitLab CI | 是 | 中等 | 一般 | 可定制 Runner | 需部署 | 团队 |
| Gitee Go | 否 | 较低 | 支持无代码操作 | 可定制辅助功能 | 简单 | 个人（中国） |
| Travis CI | 是 | 很低 | 一般 | 仅 CI/CD | 简单 | 个人 |
GitLab CI
下面使用 GitLab CI 对一份从 CS61A 积累的 Python 脚本做单元测试，仓库在 setest / tsq-ci · GitLab (buaa.edu.cn)。
.gitlab-ci.yml文件：
stages: # List of stages for jobs, and their order of execution
- test
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 "Running unit tests..."
- python3 -m doctest -v DataStructures.py
- echo "Test finished."
Runner 配置：
CI 结果：
GitHub Actions
下面使用 GitHub Actions 对上学期用 C++ 写的一个小编译/解释器进行构建和简单测试，计算 1000 位的 \(\pi\)。
进入 Actions 选项卡，已经看到 GitHub 推荐了 3 种模板，甚至支持 MSBuild，看起来非常高级。
首先使用 CMake 进行编译、运行、测试。
cmake.yml文件：
name: CMake
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
env:
# Customize the CMake build type here (Release, Debug, RelWithDebInfo, etc.)
BUILD_TYPE: Release
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Configure CMake
# Configure CMake in a 'build' subdirectory. `CMAKE_BUILD_TYPE` is only required if you are using a single-configuration generator such as make.
run: cmake -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}}
- name: Build
# Build your program with the given configuration
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}}
- name: Run
working-directory: ${{github.workspace}}/build
run: echo 1000 | ./Code
- name: Test
working-directory: ${{github.workspace}}/build
run: diff pcoderesult.txt pi.txt
结果：
然后使用 MSBuild 进行编译、运行、测试。
msbuild.yml：
name: MSBuild
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
env:
SOLUTION_FILE_PATH: .
BUILD_CONFIGURATION: Release
jobs:
build:
runs-on: windows-latest
steps:
- uses: actions/checkout@v2
- name: Add MSBuild to PATH
uses: microsoft/setup-msbuild@v1.0.2
- name: Restore NuGet packages
working-directory: ${{env.GITHUB_WORKSPACE}}
run: nuget restore ${{env.SOLUTION_FILE_PATH}}
- name: Build
working-directory: ${{env.GITHUB_WORKSPACE}}
run: msbuild /m /p:Configuration=${{env.BUILD_CONFIGURATION}} ${{env.SOLUTION_FILE_PATH}}
- name: Run
working-directory: D:\a\C-Subset-Compiler\C-Subset-Compiler\x64\${{env.BUILD_CONFIGURATION}}
run: echo 1000 | .\code
- name: Test
working-directory: D:\a\C-Subset-Compiler\C-Subset-Compiler\x64\${{env.BUILD_CONFIGURATION}}
run: cmd /c fc pcoderesult.txt pi.txt
结果：
发现 GitHub 无需像 GitLab 一样配置 Runner 就可以运行。但由于不熟悉配置文件的语法，查找编译出的目标文件所在的目录颇费了一番周折。
总体上看，GitLab 由于可以用本地的 Runner，环境配置起来更方便些。
