项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2022年北航敏捷软件工程 |
这个作业的要求在哪里 | 个人阅读作业-阅读和调研 |
我在这个课程的目标是 | 学习到软件工程的方法论,了解整个过程,并进行亲自实践 |
这个作业在哪个具体方面帮助我实现目标 | 对软件工程整体有一定的了解,对 git 和 CI/CD 更加熟悉 |
《构建之法》阅读
这本书的内容感觉非常丰富,不能立即消化完,希望在本学期的软工课程中通过"Learning by doing"体会其中的奥秘吧。下面是读后提出的一些问题。
问题一:有关课程的设计
在课程教学方法-教学手段中,提出了进行人员流动的方法,用以模拟真实的裁员和跳槽。
所以,我们在团队项目的 alpha 阶段后,强制所有团队必须有一个人离开。 这个人要自己找能接纳自己的团队(不是原团队),经过新团队的同意,双方谈好了责任/权利/义务/报酬,就可以在一个团队工作了。
我不认为在不到8周一个项目的时间下,强制同学们交换团队是一件非常有意义的事情。
首先这对于大部分学生们来说,软件工程课程是第一次完整经历整个开发流程的过程,需要让学生们能在这个过程中完整经历一遍开发的流程,专注于一个项目才有助于让同学们学习到更多的知识。其次,由于每一版项目的开发时间只有不到8周,同学们在进入新团队之后需要花1到2周去融入和适应新环境,那为团队贡献的时间就将压缩的更少。因此,我的建议是可以将强制交换变为允许交换,这样也能让工作能力更强的同学有更多展示的空间。
问题二:有关代码复审
在代码规范和代码评审部分,提出了可以通过代码评审来提高代码质量,同时增加团队成员对于代码和项目的熟悉程度。但是究竟要如何控制代码评审的频率和范围?以上学期数据库大作业为例,我们采取了代码评审机制来提高代码质量。但是在项目刚刚开始创建的情况下,此时由于项目整体框架还不完善,因此这时需要写大量的代码。如果每个提交我们都进行团队复审,那开发效率会大打折扣,这对于前期需要推进度来说是致命的问题。而如果我们以功能为单位进行代码复审,要如何把管理好提交与功能之间的关系?
问题三:有关结对编程的思考
在两人合作部分,提出了结对编程这一概念。
在结对编程模式下,一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起工作。他们一起分析,一起设计,一起写测试用例,一起编码,一起单元测试,一起集成测试,一起写文档等。
在两个人Pair的情况下,互相督促防止摸鱼共同完成代码的编写。但是,结对编程能完全提高效率吗?我对这个持否定态度。
首先,两个人之间并不一定是完全 match 的。在博客中男女跳舞的例子中,两个人最终可能走向“解体阶段”。日常生活中谈恋爱也是相同的道理,身边有很多朋友都有自己的伴侣,但不是所有情侣都能走入婚姻的殿堂,甚至结婚之后都有可能继续离婚。两个人可能会因为各种各样的事情产生矛盾,进而最终破裂。结对编程的过程与谈恋爱是类似的,大家的目标是共同完成一个项目。但是如果两个人的性格本身是合不来的,那最终的结果很大概率会是不欢而散的。
其次,结对编程也要求两个人的技术水平/思维是相当的,当然不要求技术栈是重合的,互补有时更能有奇效。但是如果两个人能力差距过大,其中一方不能特别好的 get 到另一个人的想法,需要他停下来去讲,那么结对编程的效率将大打折扣。
问题四:有关 MSF 的问题
在软件工程的方法论中,比较著名的有微软提出的 MSF 原则:
- Foster open communications
- Work toward a shared vision
- Empower team members
- Establish clear accountability and shared responsibility
- Focus on delivering business value
- Stay agile, expect change
- Invest in quality
- Learn from all experiences
但是 MSF 原则下,要如何处理团队的冲突问题呢?虽然作者也说明了 MSF 没有掩饰利益冲突这件事情,但是也并没有给出解决的方法。在 MSF 原则下,由于给出了足够的授权,导致并没有所谓的“隶属关系”,大家互相是属于平等的成员。同时由于 MSF 团队对于分工比较明确,因此团队的成员数量较多。在这种状况下非常容易出现比较激烈的冲突且不好解决。在没有一个严格意义的“领航人”的情况下,团队有可能出现卡顿现象。
问题五:有关 Bug Bash 的问题
在微软中,为了提高大家的测试的熟练程度,展开了 Bug Bash 活动。
一般是安排出一段时间(一天),所有测试人员(有时也加入其他角色)放下手里的事情,专心找某种类型的小强。然后结束时,统计并奖励找得最多和最厉害的小强的员工。
在很多其他互联网公司比如网易也同样有这样的活动,那要如何安排好活动的规模和频率呢?公司开展这样的活动,主要目的一个是更好的提高大家的测试能力,二是更快的找到系统的 Bug 。因此活动不能过于频繁,这样大家对于该活动的兴趣感和动力将下降。同样如果离软件发布时间过近则开发人员将没有足够时间去修复这些 Bug 。同样活动也不应该过分强调奖励,更重要在于技术分享,让大家学到更多的知识才是这个活动初衷。
问题六:科研与创新的关系
在介绍 IT 行业的创新时,作者引用了杰弗里·尼科尔森的话:
科研是将金钱转换为知识的过程,创新则是将知识转换为金钱的过程。
这里我不是很同意他的观点。首先科研与创新两个词本身就不算是并列的一类词语,科研是去做研究,而创新是一种思维方式,在科研中需要努力去创新。其次,现在的研究一般都会有对应的产品。比如在计算机视觉中的YOLO,作者在研究模型的过程中,还创办了对应的web页面可以用于识别和分类,就可以产生商业价值。个人认为,这里将科研与工程相并列是一种好的类比:
科研是将金钱转换为知识的过程,工程则是将知识转换为金钱的过程,科研与工程中都需要创新。
问题七:有关课程的分数评定
在课程的教学方法中,提出类似于市场机制的给分模式:
由于软件市场有 ”赢者通吃” 的规律 (第一名会占据 50% 以上的份额), 我们在训练中也要体现这一规律。
我认为在真实市场中其实是接近零和博弈的状况的,但是对于学生来说学生们之间并不是完全零和博弈的状况,比如保研我们并不是只有前几名才能拥有保研名额(市场份额),而后面所有人都没有机会,所有并不是完全一样的。这样同样会导致非常内卷的情况(因为真实市场中就是一种非常卷的状况)。
调研源代码版本管理软件
各软件的功能对比如下图所示:
Feature | GitHub | Gitlab | Bitbucket |
---|---|---|---|
私有仓库 | 免费 | 免费 | 免费 |
公有仓库 | 免费 | 免费 | 免费 |
集成CI功能 | 需要第三方库 | 支持 | 支持 |
分支管理 | Pull Request | Merge Request 不能方便的查看分支的区别 | Pull Request |
文件存储 | 提供大容量存储 | 提供大容量存储 | 提供大容量存储 |
开源性 | 不开源 | 完全开源 | 不开源 |
集成性 | 可以集成第三方库 | 可以集成第三方库 | 可以集成第三方库 |
搜索引擎 | 可以搜索其他库 | 可以搜索其他库 | 不能搜索其他库 |
项目分析 | 不提供项目分析 | 提供项目分析和燃尽图 | 提供项目分析和燃尽图 |
调研持续集成和持续部署
持续集成和持续部署
持续集成(CI):将不同分支的代码合并到同一个存储库中,并在合并过程中进行代码的测试和构建。
持续部署(CD):将集成好的存储库中的代码部署到开发环境中,用于产生产品。
动手实践
Gitlab CI
使用项目
编译技术课设,实现了一个C语言子集的C++编译器。
项目地址
CI代码
build-job:
stage: build
script:
- echo "Hello, $GITLAB_USER_LOGIN!"
- ls
test-job1:
stage: test
script:
- echo "This job tests something! Only for test...."
- java -version
- sleep 5
test-job2:
stage: test
script:
- mkdir target
- ls
- cp -r ./data/* ./target
- cd target
- g++ ../main.cpp -O2 -o main
- mkdir test
- cp -r ./testfiles/* ./test
- python3 checker.py > log.txt
- cat log.txt
deploy-prod:
stage: deploy
script:
- echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
- g++ main.cpp -O2 -o main
- mv main compiler
artifacts:
name: compiler
paths:
- compiler
expire_in: 30 days
屏幕截图
图片中间的triggered 51 minutes ago by Jiyuan Chen可以证明我的身份。
Github Action
使用项目
依然是编译技术课设,实现了一个C语言子集的C++编译器。
项目地址
CI代码
name: GitHub Actions
on: [push]
jobs:
github-action:
runs-on: ubuntu-latest
steps:
- name: Start CI/CD
run: |
echo "^v^ Welcome to Zergling's Compiler!"
echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
- name: Check out repository code
uses: actions/checkout@v2
- name: List files in the repository
run: |
ls ${{ github.workspace }}
- name: Make target directory
run: |
cd ${{ github.workspace }}
mkdir target
- name: Test target directory
run: |
ls ${{ github.workspace }}
- name: Copy the data
run: |
ls
cp -r ./data/* ./target
cd target
mkdir test
cp -r ./testfiles/* ./test
- name: Compile the compiler
run: |
cd target
g++ ../main.cpp -O2 -o main
- name: Test the testcase
run: |
cd target
ls
python3 checker.py > log.txt
cat log.txt
- name: Upload the artifact
uses: actions/upload-artifact@v3
with:
name: ZerglingCompiler
path: target/test/compiler
屏幕截图
图片中间的ZerglingChen3是我的github账号,与gitlab账号名相同可以证明我的身份。
CI对比
相同点
- Gitlab CI 和 Github Action 都是基于 yaml 文件触发 CI/CD 的。
- Gitlab CI 和 Github Action 都可以应用于自动测试、自动部署。
不同点
- Github 的集成部署代码是可以只需要指定机器类型,可以直接在 Github 的服务器上跑 CI/CD 代码。而 Gitlab 需要 Gitlab-Runner 客户端并指定部署机器。
- Gitlab 包含完整的内置 CI 配置,但是 Github 需要依赖于第三方库。
- Gitlab 没有建立关于 CI 的配置市场,Github 建立了有关 Action 的配置市场。
- Gitlab 提供了团队协作的安全性面板,可以更方面的进行合作,Github 没有提供类似的 feature。
适用性
总体来说,由于 github 本身做为大的开源社区,比较适合程序员自己配置个人项目,或者比较小的团队进行配置。
而 gitlab 整个平台是一个开源项目,也可以自主配置 gitlab-runner ,灵活性非常高,可以自己搭配环境。适合一些学校内部课程平台或者公司内部进行代码和数据的管理。