构建之法-个人阅读作业#2
项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2021年春季软件工程(罗杰 任健) |
这个作业的要求在哪里 | 2021年软工-个人阅读作业#2 |
我在这个课程的目标是 | 初入软件工程 |
这个作业在哪个具体方面帮助我实现目标 | 了解软件开发的基本流程和团队协作,了解 CI/CD 的使用与部署 |
第一部分:阅读提问
比较粗略地阅读完了《构件之法》,对于一款软件的开发,对于一个团队的形成,对于一款产品的发布,算是有了一个大概的框架,有许多地方开阔了自己的眼界,打破了定式思维,比如一款软件的开发需要大量的测试,不同维度的测试,采用典型用户来确定软件的开发目标等。
Q1:单元测试必须由最熟悉代码的人来写吗?
“代码的作者最了解代码的目的、特点和实现的局限性。所以,写单元测试没有比作者更适合的人选了。”
——2.1.2 好的单元测试的标准《构建之法》
之前对企业招聘的岗位中的测试岗不是很了解,在查找相关资料的时候看到了这样一则趣话:
- 一个测试工程师走进一家酒吧,要了一杯啤酒
- 一个测试工程师走进一家酒吧,要了一杯咖啡
- 一个测试工程师走进一家酒吧,要了0.7杯啤酒
- 一个测试工程师走进一家酒吧,要了-1杯啤酒
- 一个测试工程师走进一家酒吧,什么也没要
...
测试工程师们满意地离开了酒吧
然后一名顾客点了一份炒饭,酒吧炸了
从这则趣话中,我们可以看出测试人员常常会因为因为软件的适用范围而局限了测试范围,而用户却不一定会按照软件的要求来进行操作,如果进行了要求之外的操作,没有按照开发者的意图来操作,往往很容易出 bug。
所以如果是代码的作者来对代码进行测试,会不会因为正是对代码的目的、特性和实现有着充分的认知,才更容易导致单元测试的局限性?
关于这点,我大概从第13章 软件测试部分找到了答案。单元测试是对最基本的功能/参数上验证程序的正确性,而像其他功能,会有场景测试,Alpha/Beta测试等来进行全面的测试,可能就不需要再单元测试中覆盖了?
Q2:充分授权和信任的边界
“在一个高效的团队中,所有的成员都应该能得到充分的授权,他们有权在职权范围内按照自己的承诺完成任务,同时,他们也充分信任其他同事能实现各自的承诺。”
——7.2.3 充分授权和信任《构建之法》
充分授权和信任固然是对人的自信和成长有着关键的作用,但是更经常存在的问题应该是人对自己的能力有着错误的估计(规划谬误),或许长,或许短地估计了自己对于项目的把控。
如果仅仅是根据团队成员的自己承诺来充分授权,在一两个成员没有按照要求完成任务的情况下领导还是可以进行督促和帮助的;但若整个团队都对项目有着错误的把握,那么这种基于成员自己承诺和评估的授权和信任还是值得奉行的原则吗?
我认为可能需要从第三方的角度来评估能力,并进行授权和信任,第三方可以是其他团队开发的时间进度作为参考,也可以是长期与团队成员合作后,他的进度完成达标率来作为参考,并且制定对应的规则和每周或者每日的指标,在充分授权和信任成员去独自完成的同时,更需要定期的检查或者对应的规则。
Q3:如何评价不符合“用户满意度-投资力度”曲线的产品?
“功能变好,用户满意度就高,功能质量和用户满意度有一个线性的关系...”
——8.5 功能的定位与优先级 《构建之法》
关于这类产品,我认为钉钉应该是一个比较典型的例子,使用的双方一般在团队中有着明显的监管关系。对于产品本身的定位,是一个企业沟通软件,这个产品方便了监管者对被监管者的管理,在这点上它做得很好;但是从另一方面来说,使用这款软件的更多是普通的员工,也就是被监管者,在一些功能(如Ding功能,如果长时间没有读通知,那么就会直接发送短信或者电话告知)做得更好,质量更高的同时,用户的满意度却也更低了,更多的使用者的体验没有被考虑。
当一个产品是属于“对立”双方使用的时候,如何更好地去评价产品和产品的功能是否很好地服务了用户呢?
Q4:顾客真的知道他们想要什么吗?
“MSF强调产品团队与顾客的交流与合作,并不是产品团队拿到合同之后,就闭门造车,直到产品完成才告诉用户,给他们一个惊喜(通常“惊”大于“喜”)。”
——7.2.9 与顾客合作《构建之法》
顾客对于一款具体的产品,所能够提出的需求一般是产品的基本功能,或者随着主流的功能,他们真的能够提出“杀手功能”吗?或者团队将“杀手功能”与顾客交流时,他们真的能够预见这个功能在未来的使用情况吗?如果顾客对于此功能给予了否定的答案,产品团队是否还要继续开发这个功能?产品的“杀手功能”,产品的创新到底是顾客的需求作为主导,还是团队的创新和尝试作为主导?
Q5:结对编程在企业中是否真的有得到很好地应用?
4.5.4 如何结对编程《构建之法》
现在的开发流程已经有着完善的设计,开发,复审,测试等流程,结对编程是否是对测试(复审)部分流程的重复?并且企业需要高强度工作,也就是我们常说的996,已经有着如此重的开发任务,还让两个开发人员结对编程,是否会让结对双方更加劳累,这种开发方式是否已经不适用于企业中了?
第二部分:调研源代码版本管理软件
平台介绍
GitHub 是第一个供“用Git进行版本控制系统的软件开发项目”使用的基于Web的代码托管服务,是目前全球最大的开源社交编程及代码托管网站。
GitLab 是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托管的 Git 项目仓库,可通过 Web 界面进行访问公开的或者私人项目。
BitBucket 是 2008 年创建的源代码托管网站,采用 Mercurial 和 Git 作为分布式版本控制系统,同时提供免费账户和商业计划。
相同之处
三个平台都有提供关于团队协作和项目管理的基本功能:
- 拉取请求
- 查看分支之间的变化差异
- Markdown 编辑支持,内联编辑,问题跟踪等
- 支持丰富的第三方集成工具
- 一键合并和删除源分支
不同之处
- Github:是最流行的代码管理工具,在上面有着全世界最大数量的公共开源项目,在上面可以搜索需要的开源项目,用于私人项目托管的费用更贵
- GitLab:相较于 Github 和 Bitbucker 有着更少的内置集成,但是它是开源的,可以自定义代码的任何部分,提供免费的私人代码仓库(只有在团队变得更加专业时才开始需要付费)
- Bitbucket:被 Atlassian 收购,与 Atlassian 的其他服务(Git GUI SourceTree、HipChat、Cloud)等顺利集成,并在购买托管服务的方案中提供了产品定制功能,提供免费的私人代码仓库(只有在团队变得更加专业时才开始需要收费)
第三部分:调研持续集成/部署工具
1. Gitlab CI
使用了 OO 课程的第一单元的第一次作业作为实验项目,配置 Gitlab CI/CD,进行了输入输出测试。
.gitlab-ci.yml
的配置如下:
image: local-registry.inner.buaaoo.top/image-dev/java:8u201
stages:
- build
- test
before_script:
- java -version
- javac -version
- mvn -v
mvn-build:
stage: build
script:
- echo "Build TAKS1 PROJECT"
- mvn compile
mvn-test:
stage: test
dependencies:
- mvn-build
script:
- echo "RUN TEST"
- cd target/classes
- echo "x**3+x**2" > test.txt
- cat test.txt | java task1.MainClass
2. Github Actions
使用了 OO 课程的第一单元的第一次作业作为实验项目,配置 Gitlab Action,先进行了语法检查,然后进行了输入输出测试。
deploy.yml
的配置如下:
name: deploy
on:
push:
branches:
- master
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Build Maven
run: |
echo "Build Project"
mvn compile
- name: Test Maven
run: |
echo "Test Project"
cd target/classes
echo "x**3+x**2" > test.txt
cat test.txt | java task1.MainClass
3. 使用CI/CD后的感受
- CI/CD 感觉类似软件产品正式发布前的一次检查,在具体的配置情况下进行发布测试,能够更早地帮助开发者发现问题,降低修复问题的难度和时间
- 部署的每一个步骤都可视化,能够更好地看到部署的具体细节
- 关于个人使用体验,我觉得 Gitlab 的 CI/CD 需要指定镜像,但是部署和测试的每一步都简单清晰;而在 Github Action 上,在环境配置上更加便利,有着现成的环境可以直接调用,单只在部署的步骤描述上相对麻烦。总体来说,二者在部署的流程上都很简单,在使用上也十分方便
- 在使用的场合上,我觉得二者都比较适合中小型的项目部署测试,大项目不太适用于这种 CI/CD 的部署测试(从资源使用和花费的时间上来说)