软件工程第1次阅读做业

软件工程第1次阅读做业

---

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

《构建之法》中的问题

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

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

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

2. 第4章 结对编程 P69

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

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

3. 第4章 结对编程 P81

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

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

4. 第6章 敏捷流程 P11六、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