软工个人博客作业：阅读、提问与一些调研

这篇博客是一份课程作业。

Q	A
这个作业属于哪个课程	2020春北航计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	个人博客作业
我在这个课程的目标是	系统地学习软件工程理论知识与实践方案
这个作业在哪个具体方面帮助我实现目标	快速阅读教程并深入思考；了解软工历史；调研常见版本管理工具

快速阅读与提问

在博客
现代软件工程讲义 4 团队和流程
中，我看到下段文字

这个软件什么时候才最后完成呢? 下面几个条件满足一个即可:

• 时间到了
• 钱花光了
• 用户满意了（或者很不满意, 不再给钱了）

但是经常地，用户并不能清楚地描述自己的需求，甚至会不断产生新的需求，因而长久不能达到“满意”。这导致每两周一次的迭代可能被大量重复，中间大量旧需求被新需求取代，因而需要推翻旧代码，这变相拉长了整个开发周期并造成了人力物力的浪费。我认为或许需要进一步对“用户满意”加以进一步的规范与限制，使得已经陷入病态的软件项目可以被及时终止？

在博客
现代软件工程讲义4 Scrum/Sprint
中，下列论述使我产生了困惑

一个好的ScrumMaster 能在两种语境 (描述软件项目的商业语境，描述实现细节的技术语境) 自如地翻译和切换，事实上是一个强有力的PM，如果团队还要求她做全职的开发工作，这样的人就更难找了。

然而，就我所知，目前大学计算机专业的课程设置很少系统地涉及商业与管理学，而开发人员在正常工作中对这两方面的接触也较浅显。如果想要成为这种能在两种语境中自如切换的，应当如何规划自我提升的路线呢？

博客
现代软件工程讲义 7 开发 开发阶段的日常管理
中指出

要尽量减少非开发时间，不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。

但是另一方面，敏捷开发又鼓励日会制度，这两条经验似乎是冲突的。目前我实习所在的小组有周会汇报制度，主要内容也是总结工作，需要占用掉整晚的时间实现这种组内同步，并且为了准备会议材料实际上要耗费更久的时间——我理解的日会制度或许也会存在类似的问题。请问应该如何看待这种冲突，日会制度是否有反而降低团队开发效率的风险？

在这篇讨论绩效管理的文章
现代软件工程 10 绩效管理
中，关于价值观-产出二维评价的论述令我不解

如果业绩很好, 但价值观不太对路 (不太听话?), 则是一条野狗。 要坚决清除, 不然功高震主...

引入价值观作为考核指标是否会为企业带来潜在风险？纵然成员的价值观十分重要，决定了其是否能融入团队并切实为企业创造价值。但一方面，价值观难以客观评估，比如考虑这样的事实：很多开发人员不善于言辞，因此无法将自己认同的企业价值观良好地对外表述，而因此由“藏獒”沦为“野狗”而遭到解雇，这于员工和于企业都是损失。另一方面，一些“野狗”离职后可能为企业带来负面声誉，比如前段时间王垠面试阿里巴巴失败后掀起的舆论风暴就是可以参考的例子。

最后，依旧是有关会议制度的问题。在文章
现代软件工程讲义 11 项目管理 - 事后诸葛亮会议
中对总结会制度的介绍是

怎么开好一个 Postmortem 会议:

保持会议轻松愉快的氛围, 可以考虑换一个开会的环境, 有饮料, 零食, 音乐的帮助更好
当大官的最好不要出现, 让大家畅所欲言。 (即使出现, 也要夹着尾巴, 不要为自己以前的行为辩护, 作好听众)
坚持对事不对人的原创, 强调 - 如果再有一次机会, 会如何改进？ 而不是挖历史旧帐.
照顾到模板提及的各个领域, 可以深入团队最感兴趣的部分。
让所有人都有充分发言的机会。
有人记录发言要点, 最后列出所有改进意见
最后大家可以投票, 如果我只有三票, 投给哪些改进意见
大官们保证要采取行动, 执行票数最高的一些改进意见。

因而我的理解是，这样的会议讨论要点无非：1. 回顾已经出现的问题并总结可能的改进方法；2. 汇总各种建议并决策是否执行；3. 要求全员积极参与。看起来与日会同步团队进度的功能并没有本质的差异，为什么一定要单独分离为一个阶段性会议而不将讨论内容并入时效性更强的日会呢？

---

术语发展历史

“软件”一词最早出现于The Teaching of Concrete Mathematics一文，该文发表于1958年，作者是John Tukey。其维基百科页面Statistical terms一节中叙述：

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.

“软件工程”一词则由时任MIT某实验室软件开发部主管Margaret Hamilton首次使用。见文章：What to Know About the Scientist Who Invented the Term "Software Engineering"

Indeed, Margaret Hamilton, renowned mathematician and computer science pioneer, is credited with having coined the term software engineering while developing the guidance and navigation system for the Apollo spacecraft as head of the Software Engineering Division of the MIT Instrumentation Laboratory.

---

软工小故事！

可能有点跑题，讲一个经典的程序员轶事

Max Howell是homebrew的开发者，后者是Mac OSX上最常用的软件管理器（类似Linux上的apt）。他去Google面试的时候，被要求在白板上写下平衡二叉树的旋转算法，很不幸由于写不出来这次面试被拒了。回到家后意难平的他在推特上写下了著名的吐槽：

“Google：虽然我们的工程师中有90%都在用你写的软件，但由于你无法在白板上旋转二叉树所以给我滚。”

这个故事对我们有如下几层启示

1. 再牛逼的程序员也会翻车，何况我等凡人。要对技术时刻抱有敬畏之心
2. 软件工程是复杂而立体的，不仅要求我们的工程能力，也要求我们的算法能力，这从现在FLAG和BAT面试必考算法题可见一斑。两者应该兼顾
3. 面试大厂前刷题还是有必要的

---

版本控制于项目管理软件汇总

工具	优点	缺点
Git	面向分布式开发的开源工具，借助树状结构可以处理复杂的非线性的社区开发模式；由Linus开发，内置于Linux系统并受到良好推广；有Github为代表的成熟的工作流	需要学习的概念晦涩繁杂：如工作树维护。对初学者不友好
Mercurial	面向分布式开发，高性能，充分可扩展性，能同时高效地处理纯文本和二进制文件，以及分支和合并功能，以此同时保持系统的简洁性	相较于Git功能更简陋；不支持命名空间
Trac	支持在Web页面上操作，自带修复内容管理，对Git、Mercurial等先前出现的工具兼容	功能单一
Bugzilla	开源的轻量工具，对不同开发环境支持较好	功能单一，只包含基本的追踪与测试功能
Microsoft TFS	高度支持常见的开发模型，如瀑布模型和敏捷开发模型，提供大而全的完整工作流	功能繁杂，难以使用，因而没有大规模推广

排名参考维基百科，其统计依据是Alexa Rank。

---

版本管理使用体验

Git的使用

对一个已经存在的项目，使用git对其代码进行版本管理，执行下列命令：

# view current working direction
pwd
ls

# init
git init
git add -A -v
git commit -m "init"

# checkout to a new branch
git checkout -b chore--my-branch

# change/add something ...
echo helloGit > hello.txt
touch another_new_file

# add all changes
git add -A -v

# commit changes
git commit -m "chore: add new files"

# checkout back to master and checkout to another new branch
git checkout master
git checkout -b chore--another-branch

# change and add
touch newfile
git add -A -v
git commit -m "chore: add a new file"

# merge branch A to master
git checkout master
git merge chore--my-branch

# rebase branch B for later merging
git checkout chore--another-branch
git rebase master
git checkout master
git merge chore--another-branch

# delete tmp branches
git branch -d chore--another-branch

# view remained branches
git branch
git branch -a
ls

在Windows CMD中输出如下：

D:homeworkgit_exp># view current working direction 

D:homeworkgit_exp>pwd
/d/homework/git_exp

D:homeworkgit_exp>ls
a_file.txt
git.log
test_git.bat

D:homeworkgit_exp># init 

D:homeworkgit_exp>git init 
Initialized empty Git repository in D:/homework/git_exp/.git/

D:homeworkgit_exp>git add -A -v 
add '.gitignore'
add 'a_file.txt'
add 'test_git.bat'

D:homeworkgit_exp>git commit -m "init" 
[master (root-commit) 0debe77] init
 3 files changed, 49 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 a_file.txt
 create mode 100644 test_git.bat

D:homeworkgit_exp># checkout to a new branch 

D:homeworkgit_exp>git checkout -b chore--my-branch 

D:homeworkgit_exp># change/add something ... 

D:homeworkgit_exp>echo helloGit  1>hello.txt 

D:homeworkgit_exp>touch another_new_file 

D:homeworkgit_exp># add all changes 

D:homeworkgit_exp>git add -A -v 
add 'another_new_file'
add 'hello.txt'

D:homeworkgit_exp># commit changes 

D:homeworkgit_exp>git commit -m "chore: add new files" 
[chore--my-branch 5733e4a] chore: add new files
 2 files changed, 1 insertion(+)
 create mode 100644 another_new_file
 create mode 100644 hello.txt

D:homeworkgit_exp># checkout back to master and checkout to another new branch 

D:homeworkgit_exp>git checkout master 

D:homeworkgit_exp>git checkout -b chore--another-branch 

D:homeworkgit_exp># change and add 

D:homeworkgit_exp>touch newfile 

D:homeworkgit_exp>git add -A -v 
add 'newfile'

D:homeworkgit_exp>git commit -m "chore: add a new file" 
[chore--another-branch 604c163] chore: add a new file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 newfile

D:homeworkgit_exp># merge branch A to master 

D:homeworkgit_exp>git checkout master 

D:homeworkgit_exp>git merge chore--my-branch 
Updating 0debe77..5733e4a
Fast-forward
 another_new_file | 0
 hello.txt        | 1 +
 2 files changed, 1 insertion(+)
 create mode 100644 another_new_file
 create mode 100644 hello.txt

D:homeworkgit_exp># rebase branch B for later merging 

D:homeworkgit_exp>git checkout chore--another-branch 

D:homeworkgit_exp>git rebase master 
First, rewinding head to replay your work on top of it...
Applying: chore: add a new file

D:homeworkgit_exp>git checkout master 

D:homeworkgit_exp>git merge chore--another-branch 
Updating 5733e4a..5151263
Fast-forward
 newfile | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 newfile

D:homeworkgit_exp># delete tmp branches 

D:homeworkgit_exp>git branch -d chore--another-branch 
Deleted branch chore--another-branch (was 5151263).

D:homeworkgit_exp># view remained branches 

D:homeworkgit_exp>git branch 
  chore--my-branch
* master

D:homeworkgit_exp>git branch -a 
  chore--my-branch
* master

D:homeworkgit_exp>ls
a_file.txt
another_new_file
git.log
hello.txt
newfile
test_git.bat

Gitlab使用体验

Fork、merge request、Issue等常用功能略，实验作业已经具体涉及

除了与GitHub相似的基于Git的远程代码库相关功能，Gitlab还提供了以gitlab-runner为核心的CI/CD工具（当然也可以像Github一样支持第三方CI/CD，如Jenkins）

使用时只需要在项目根目录下提供配置文件.gitlab-ci.yml

例如：

image: "registry.xxx.com/xxx/xxx-image:pytorch0.4.1"

before_script:
  - gcc --version
  - nvcc --version
  - nvidia-smi
  - python -c "import torch; print(torch.__version__)"
  - python -c "import nart_tools; print(nart_tools.__version__)"


# TODO
#style:
#  stage: build
#  script:
#    - pip install flake8
#    - flake8 .


test:
  stage: test
  script:
    # TODO remove it
    - pip install torch==1.2.0+cpu -f https://download.pytorch.org/whl/torch_stable.html
    - pip install -r requirements.txt
    - python -m py.test test

在为该项目提交commit时，

会自动显示CI的运行情况（成功/报错失败），reviewer不需要将代码下载到本地运行测试就能大致了解其质量。因此可以将测试、部署等琐碎工作高度自动化地集成入工作流中。

gitlab的CI管道运行界面：