BUAA软工第二次作业

项目	内容
这个作业属于哪个课程	2020春季计算机学院软件工程(罗杰 任健) (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	个人博客作业
我在这个课程的目标是	实现自己在软件工程方面的个人素质的飞跃
这个作业在哪个具体方面帮助我实现目标	通过阅读教材和查找相关资料快速并系统了解软件工程
作业正文......	见下
其他参考文献...	邹欣老师的博客园讲义 英文维基-software 百度百科-hello world 参考博客1 参考博客2 英文维基- Comparison of source-code-hosting facilities

看完教材仍然不懂的问题

这里阅读的教材是邹欣老师的《构建之法》。由于还没买到书，只在北航图书馆中找到了第一版的电子书（下面的章号也对应第一版章号），所以结合 邹欣老师的博客园讲义 进行阅读。

1.关于增量编程，如何解决增量到一定程度后系统过于臃肿的问题？（第6章）

如果是做网页前端代码的开发，增量编程还是比较容易的。但如果是做计算机组成课设、编译原理实践这样系统本身逻辑复杂，又经常提出增量要求的系统开发，前期可能还有比较清晰的代码结构，到开发后期便变得越发臃肿，这样的项目在开发模式上应该如何保证在后期也能有比较高的开发效率呢？

2.关于开发与测试的对立（第7章）

开发与测试不是对立的，道理上大多数人应该是懂的。但到实际层面，在很多计算机课程的学习中，都实行“学生写，OJ/老师/其他学生测”的模式。虽然课程设计的初衷是让学生自己同时完成写和测的实践，但学生往往完成了“写”的工作（即实现基本功能并进行功能性验证）后，没有足够的精力与心情完成比较深入的“测”（进行比较复杂的测试工作），在代码提交后被测出bug并被扣分。所以我在想，导致开发与测试对立的根源，是不是在计算机学习过程中缺乏二者的结合呢？

3.关于bug hell的设定（第11章）

比如假设一名程序员的代码中出现了16个bug，而bug hell的入狱阈值为15，这时程序员进入bug hell，那么他应该只处理掉一个bug就可以出狱（但这样的话他之后写程序只要出现1个bug就又要入狱），还是强制其处理更多的bug才能出狱呢？

4.关于“小强大扫荡”，如何确定bug的数目（第13章）

是从测试者的角度，发现的一个问题就算一个bug（可能会有很多由同一个问题导致的bug被统计很多次），还是从开发者的角度，一处代码改动修复的所有问题都算同一个bug（如何定义代码修复的量是一个问题）？

5.关于软件工程师的职业道德（第17章）

书中最后一章提到软件工程和护士职业一样，也有一份要求普遍遵守的道德准则。相比治病救人的医生护士，开发软件的过程中牵扯到更多资本与利益，有时还会出现企业之间或者企业内部资本间的冲突和对立。这种情况下，软件可能被要求开发出并不“道德”的功能（如运行时强制要求对立方程序停止运行），这时软件工程师应该服从上级要求，还是遵循自己的道德准则呢？

“软件”和“软件工程”的起源

”软件“（Software）一词的起源：根据英文维基中的介绍，”software“一词最早出现在出版物中，是在1953年8月Richard R. Carhart发表的一份兰德公司的研究备忘录中；1995年，Paul Niquette声称他于1953年10月首先创造该词，尽管他没有任何资料支持自己的说法。

”软件工程“（Software Engineering）的起源： 数学与电脑科学先锋，一个自学程序设计，并且当上 MIT 软件工程测试实验室主任（也就是为美国太空总署 NASA 开发电脑系统的单位）的女性——Margaret Hamilton，在阿波罗登月计划期间，首先提出了“软件工程“一词。

一点冷知识

“Hello, world" 这个例程在Brian Kernighan 和Dennis M. Ritchie合著的《The C Programming Language》使用而广泛流行。因为它的简洁，实用，包含了一个该版本的C程序首次在1974年Brian Kernighan所撰写的《Programming in C: A Tutorial》出现。实际上将“Hello”和“World”一起使用的程序最早出现于1972年，在贝尔实验室成员Brian Kernighan撰写的内部技术文件《Introduction to the Language B》之中。

最初的"hello, world"打印内容有个标准，即全小写，有逗号，逗号后空一格，且无感叹号。不过目前，完全遵循传统标准形式的反而很少出现。 （来自[百度百科]( [https://baike.baidu.com/item/hello world/85501?fr=aladdin](https://baike.baidu.com/item/hello world/85501?fr=aladdin) )）

目前流行的源程序版本管理软件和项目管理软件，及各自优缺点

参考博客：[1] [2]

软件名	优点	缺点
Microsoft TFS	贯穿需求，开发，测试，发布各个流程，提供自动化工具	TFS原生的源代码管理不如git
GitHub	基于web，允许使用git的源代码管理功能；公开项目免费；开源的程序更容易被别人看到	GitHub for Windos不好用；不适合用于产品设计
Trac	面向进度模型的里程碑式管理；有良好的扩充性	需要Python环境支持
Bugzilla	免费使用；有中文版支持	安装过程复杂；只能管理缺陷；已经停止更新
Apple Xcode	可以自动创建分类图表；自动提供撤消、重做和保存功能，无需编写任何编码	更新版本后，某个插件可能会失效
Bitbucket	同时支持hg和git；完全免费的闭源项目；支持中文	大多数时候用GitHub即可满足要求；网页仓库不如GitHub好用

按热度排名如下：

数据统计来源于 英文维基- Comparison of source-code-hosting facilities

尝试使用其中的一些软件

使用git log查找之前的提交记录：

使用GitHub进行分支间的对比：

使用bitbucket创建一个分支：

Git的GUI并不理想，这使得大部分程序员倾向于使用CLI进行Git版本控制，这提高了Git的入门门槛。但Git强大的功能是有目共睹的。

使用GitHub，可以很方便地创建开源项目并进行源代码的管理。作为最多人使用的项目管理工具，GitHub就像是程序员的SNS，在面试时也会作为一个重要的参考依据。相比之下，使用到bitbucket的次数没那么多，但它更适合于私人或敏感的商业项目。

追加内容：对Git GUI的使用与评测

应助教要求，这里追加对Git GUI的使用与评测内容。评测的对象是Git下载时附带的Git GUI，和TortoiseGit，也就是下图中右键菜单里的两个。

在正式开始评测之前，我回想起来之前觉得Git的GUI不好用的原因：当时了解到Git，还是在大二寒假搞冯如杯时，队内大佬教我们用GitHub，并且让我们下载TortoiseGit。当时在大佬的指导下成功克隆了我们的项目，但没记住操作流程。后来在那个寒假，我想从一本书上给的GitHub仓库网址上克隆书中代码，复制链接后直接点“确定”尝试克隆，结果失败了。但对着TortoiseGit上的一堆当时还看不懂的Tag，根本不知道怎么操作。

后来才知道其实就是因为网络原因克隆失败了，但当时没有搞明白，结果对着URL和目录底下的东西一堆乱调也没成功，直接Download ZIP。（我好菜呀.jpg）

下面是一些评测的内容：

首先尝试使用两个UI将本地代码push到远程：

再尝试使用GUI浏览版本历史，这时GUI的优势应该说是体现出来了，以列表形式展示版本信息非常浅显易懂：

顺带一提，TortoiseGit还可以直接将版本状态体现在文件/文件夹的图标上，可以很方便地确认文件版本状态，有时候也能逼死强迫症。

这次对Git GUI的评测，也让我对其的印象有了一定程度上的改变。不过总体上说，还是在学习了包括Git的暂存区，版本控制等相关知识后，才能明白GUI里的各个元素的含义和作用，这些内容在OS课上也占了一大节。而这些内容的学习是结合CLI中的一条条指令的，用惯了CLI，就有GUI麻烦又找不到重点的感觉，况且这次评测的两个GUI又不算美观。对比Visual Studio，它的UI层次就比较分明，即使是小白，也能比较容易地找到“调试”按钮所在的位置，如果出错就会出现比较详细的错误讯息，可以按图索骥地修改错误，而不去调一些无关的设置选项。

说到底，正如助教所说，Git 本身的开发目的其实就是一个命令行工具。