软件工程第1次阅读作业

软件工程第1次阅读作业

---

项目	内容
这个作业属于哪个课程	2019春季计算机学院软件工程(罗杰)（北京航空航天大学）
这个作业的要求在哪里	第一次阅读！
我在这个课程的目标是	学习软件工程方法与相关工具，提升自己的工程能力，锻炼自己与他人协同开发以及开发较大项目的能力
这个作业在哪个具体方面帮助我实现目标	通过快速阅读书本了解了软工的概念与常用的方法论

《构建之法》中的问题

1. 第3章 软件工程师的成长 P49

过早扩大化/泛化…… 有些软件本来是解决一个特定环境下的具体问题，有的程序员一想，我们能不能做一个平台，处理所有类似的问题，这样多好啊！这样的前景的确很美妙，程序员的确需要这样的凌云壮志，但是要了解必要性、难度和时机。

我在阅读了以上部分后，认为的确从一开始就考虑泛化地编写程序的确难度较大，我不理解的部分是泛化的“必要性、难度和时机”具体应该如何确定？特别是在时机方面，我认为泛化的出现主要源于需求的增加，往往需要对原有的方法进行抽象，那么是当需求来临时才进行抽象还是在需求到来前某个“合适的时机”就自然向泛化的方向进发呢？

2. 第4章 结对编程 P69

4.3.2 goto ……只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto

以往学习的过程中老师都极力阻止我们使用goto，虽然我在知乎上查找了一番关于goto的问题后（知乎问题）我认为goto仅适合用于跳出多重循环，但正如某些答主所说多重循环有可能在设计上本身有改进的方案。因此我仍然对这里说可以使用goto持有怀疑的态度。

3. 第4章 结对编程 P81

结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作而导致观察力和判断力下降。

首先这一部分的内容的确与我想象的结对编程有所不同，在阅读这部分之前我认为结对编程就是在两个人确定编程的规范和计划后并行地进行工作，每隔一段时间后进行复核，类似于“两个驾驶员”的感觉。而书中介绍的结对编程实际上是一个人编码另一个人进行指导。我的问题是，如何解决结对时两人水平差距较大的问题？例如当我和某个大佬结对编程，大佬很快就能完成他的工作，而当轮到我时虽然有大佬指导，也很可能出现速度减慢质量变差的情况，可能出现大佬看我写代码甚至比他自己写还要累的情况。当两人差距过大时应当如何工作以缩小差距带来的影响？
本段话中驾驶员和领航员的比喻让我想起了前一阵的电影《飞驰人生》，我认为剧中的两个主人公实际上有点类似于我所说的水平差距较大的情况（在单纯的驾驶水平上）。大部分领航员可能对路况非常熟悉，但从驾驶车辆本身上讲领航员的驾驶水平可能比车手要差很多。因此此处对于领航员和驾驶员的比喻是否也有些不妥？

4. 第6章 敏捷流程 P116、117

如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其反。

虽然我相信班上一定有一些大佬接触过较大的项目，但大部分同学应该都是处于初步接触多人开发的阶段。在组队时从平均水平来说大概率会成为一个相对来说较弱的团队。这一点在我阅读第5章中关于主治医师模式时也有思考。

在一些学校的软工课上，这一模式往往退化为“一个学生干活，其余学生跟着打酱油”

这种情况的出现我认为是因为同学们的水平和对待课程的态度有所差异。我的问题是，对于我们刚学习软工的同学们而言，在面对敏捷开发方法方面如何起步，有哪些好的实践可以均衡这种模式导致的问题？

5. 第12章 用户体验 P260

牺牲质量去追求用户体验么，用户能接受么？（GE公司的例子）

我在读完这一部分后感觉这里的例子仅仅是说明有些时候牺牲质量追求用户体验是值得的。我的问题是如何权衡产品质量和用户体验的关系呢？有没有某些质量要求大于用户体验的情况？

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

"software"一词源于美国统计学家John W.Tukey，他在1958年1月9日的“具体数学教学”-美国数学月刊中发表了这一术语。需要注意的是Tukey将当时的"computer"称为“计算器”。彼时，"computer"这个词通常指的是人，并且"computer"这个词在机器上的使用刚刚开始流行使用。

"software engineering"的说法由Anthony Oettinger创造，在1968年被用作世界上第一个软件工程会议的标题，由NATO （北约） 赞助和推动。

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

首先我们应当明确版本控制软件和源代码托管服务的区别。前者指的是Git、Mercurial这类版本控制软件本身，而后者则指的是GitHub这样的服务。GitHub提供的服务基于Git，而我们也可以自己搭建Git服务器。

热门程度

对于版本控制软件而言，我使用Google Trends查找了五个较为热门的版本控制软件，分别是Git、CVS、SVN、Mercurial和Microsoft TFS。

（协作版本系统指CVS）
图中可以看出Git是当今最为热门的版本控制软件。CVS是最早热门的版本控制软件，但在2008年后此软件就再也没有更新过。SVN之后热门过一段时间但随着Git的兴起而逐步没落。同时我还查找了Trac、Bugzilla等相对小众的软件，但他们相比于以上五个来说搜索量小的可怜。

对于源代码托管服务，我从Wikipedia中找到了Comparison of source-code-hosting facilities，按使用人数排序如下

名称	用户数	项目数
GitHub	31,000,000	100,000,000
Bitbucket	5,000,000	Unknown
Launchpad	3,965,288	40,881
SourceForge	3,700,000	500,000
GitLab	100,000	546,000
GNU Savannah	93,346	3,848
OSDN	54,826	6,294
Ourproject.org	6,353	1,846

优缺点

• Git
  • 优点
    • 速度很快
    • 创建repo非常简单
    • 方便与GitHub对接（GitHub是最热门的源代码托管服务）
  • 缺点
    • 在Windows上体验不佳
    • 不能切换分支的一部分（不能checkout单个文件）
• Mercurial
  • 优点
    • 相对简单的学习曲线
    • 良好的Windows支持
    • 更加安全
  • 缺点
    • 功能不如Git强大
    • 扩展性差，插件只能用Python写，并且使用插件时容易带来问题
    • 回溯功能较弱
• Trac
  • 优点
    • 优秀的项目管理机制
    • 轻量灵活，可以与多种VCS集成
  • 缺点
    • 功能较弱，使用量较小
• Bugzilla
  • 优点
    • 最为知名的Bug跟踪系统
    • 使用简单，对没有相关系统了解的人也很友好
  • 缺点
    • 仅仅在Bug管理方面较强，而其他功能上较弱

（SVN和CVS相对古老，在此不再赘述）
Git pros and cons
Mercurial pros and cons
Mercurial for Git users
Trac - Wikipedia
Bugzilla