[BUAA软工]第1次阅读

本次作业所属课程: 2019BUAA软件工程
本次作业要求：第1次个人作业
我在本课程的目标熟悉和实践软件工程流程，适应团队开发
本次作业的帮助帮助理解《构建之法》

Task 1：快速看完整部教材，列出你仍然不懂的5到10个问题

[PASS]: 《构建之法(第三版)》P22, 代码清单2-1 的注释 // user email as user id 应该改成 // use email as user id 吧。

Q1：敏捷开发对于产品的可靠行要求不高？

P121, 表6-3: 表格中指出在产品可靠性要求不高容忍经常出错的时候最适用的方式是敏捷开发

我觉得没有软件会容忍经常出错，这个说法尚且值得商榷，敏捷开发同样要保证软件的基础功能的可靠性，敏捷开发确实适用于开发经常变动的软件，比如说文中提到的微博，微博对于可靠性的要求并不低，用户的信息丢失同样是很大的问题。我觉得敏捷开发最适合的是功能性经常变动的软件，而不是可靠性，像微博这种经常需要添加新的功能的应用，用敏捷能够保证可靠性的同时实现快速迭代。

Q2: 这本书适合作为教材吗？

书中多数是描述性的内容，我实在不好找问题，这个问题先凑个数

翻了半本书，觉得这本书确实有价值，但总给我感觉不是在看教材，是一本更加适合个人项目提升或者小组boss管理技能提升的书。粗略浏览就想要找问题实在是不科学，都第三个版本了，要仔细思考才会有有价值的题目可以提出啊。

Q3: 大学生如何创新？

P340，迷思之一：灵光一闪现，伟大的创新就紧随其后.

文中的观点是在相关学科打下深厚的基础，同时对于问题进行了长时间的思考，那些看似神奇的时刻才会光顾。但是在所谓大众创新的时代，学校、学院一直都是大力鼓励，甚至推着大学生去创新创业的，大学生本科的积累本身并不深厚，多数还是要靠学校的资源来推动好的想法，而创新创业的项目，能成功的屈指可数。

Q4: 如何评价软件的道德与否

P410, 问题6.刷课软件和刷票软件

软件本身是工具，道德与否在于使用者，但是对于开发者而言，很多时候并不能选择开发什么软件，开发完的软件最后被如何使用也是一个问题。

Q5: 软件说明书写的多详细为好？

> P214 , 规格说明书

做开发的时候，最烦的就是写文档了，但未来入职后肯定避免不了写文档，我希望在能表述清楚的情况下尽可能精简，不希望写很多很多无关紧要的内容。

Task 2 ：请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？

软件：1953年，Richard R.Carhart在公司的备忘录中首次使用这个词.

软件工程: 1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念。不过，据Margaret H.Hamilton，所说：

我致力于为软件以及那些发明者争取应有的正统性与尊重，所以我开始使用“软件工程”这样的字眼来将之与硬件还有其他工程学类做出区别。当我第一次使用这样的语词时，大家都觉得有些好笑，甚至有很长一段时间被当作笑话。他们常笑我极端的想法。但最终，软件学科确实得到了应有的尊重！

可以得知她认为她在阿波罗计划期间发明了软件工程一词。

Task 3：请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

找了好久终于找到一个我觉得比较有趣的（~~pass: 这种题目真的费时费力）~~，故事如下：

有人在github上给linux提交代码，linus回答说，不要在这里提交，我不接受github上提交的代码。然后他就解释了为什么他不接受github上提交代码，用一句话来说就是：github做的太差了，我已经向github说明了这个情况，但是github的人不听，我已经放弃了，你们可以给他们提bug了。然后呢，github巨搞笑，他们给Linus发了一份说明书，教他如何使用git，人家git这个软件就是linus写的，你发个说明书告诉作者应该怎么用，这就相当于让鲁迅做他写的文章的阅读理解，最后鲁迅把中心思想选错了一样。

摘自github和git当年被忘却的争吵,推荐一下绿帽子大学的栋哥，他有个网易云音乐的电台叫软件那些事儿，会讲一些软件相关的故事。

Task 4: 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些，各有什么优缺点？

4.1 目前流行的版本管理系统可以参考下图：（链接）(缩小界面，图片有点大)

4.2 而就人数来说的话，可以参考18年stack overflow 的开发者调查链接

4.3 下面讨论各种不同的版本控制系统的特点

参考 2019 Version Control Software Comparison: SVN, Git, Mercurial

CVS

CVS自80年代以来就已存在，并且一直受到商业和开源开发人员的欢迎。它是在GNU许可下发布的，并使用一个系统让用户“检查”他们将要处理的代码并“检入”他们的更改。

优点：

已经使用多年并被认为是成熟的技术

缺点：

移动或重命名文件不包括版本更新
符号链接到文件的安全风险
没有原子操作支持，导致源损坏
分支操作很昂贵，因为它不是为长期分支而设计的

Apache Subversion（SVN）

SVN是作为CVS的替代品创建的，它可以修复CVS系统中的一些错误，同时保持与它的高度兼容性。与CVS一样，SVN是免费的开源软件，不同之处在于Apache许可证而不是GNU。为了防止数据库中的损坏被破坏，SVN采用了一种称为原子操作的概念。要么应用对源进行的所有更改，要么不应用任何更改，这意味着没有部分更改将破坏原始源。许多开发人员已经切换到SVN，因为它是一种新技术，它采用了CVS的最佳功能并对其进行了改进。

优点：

基于CVS的较新系统
包括原子操作
更便宜的分公司运营
适用于IDE的各种插件
不使用点对点模型

缺点：

仍然包含与重命名文件和目录相关的错误
存储库管理命令不足
较慢的比较速度

GIT

最初由Linux的Linus Torvalds开发，Git采用了一种与CVS和SVN大不相同的激进方法.Git的最初概念是制作一个更快速的分布式版本控制系统，该系统将公开违反CVS中使用的约定和惯例。它主要是为Linux开发的，并且具有最高的速度。它也可以在其他类Unix系统上运行，而Git的本机端口可以作为msysgit用于Windows。

优点：

非常适合那些讨厌CVS / SVN的人
运行速度大幅提升
廉价分公司运营
完整的历史树可离线使用
分布式，点对点模型

缺点：

用于SVN的学习曲线
不适合单个开发人员
与Linux相比，Windows支持有限