【软件工程】第一次阅读作业

项目	内容
这个作业属于哪个课程	软件工程（罗杰）
这个作业的要求在哪里	第一次阅读作业
本次作业要完成的目标	阅读《构建之法》，快速了解软件工程的相关知识和过程并提出疑问

读完《构建之法》产生的疑问

1.第一章第7页

如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？你会选择：

根本不考虑

如果没时间实现这个功能，就算了

做了，但是不用告诉用户

做了，而且不厌其烦的告诉用户如何使用

我看了上述这段文字，有这个问题：书上针对这个例子给出的答案倾向是4，但我认为这个地方这么说是不太妥当的，并且逻辑不够严谨的。

这是个关于需求的问题，于是我翻到了书的第八章——需求分析。在第八章我看到了需求分析的定位和优先级的描述（书本第163页），里面提到了功能的四个象限（杀手功能、外围功能、必要需求、辅助需求），也就是说在软件工程的需求分析过程中我们需要根据项目本身的特点和情况将需求进行划分，本例子如果从安全性上考量那么这个百万分之一使用率的需求必然是要做的（当然也并不一定是那么必然，还要考虑到该产业中其他公司所做到的程度或是其他因素）可是如果这个百万分之一的需求不是像安全性这样的需求呢？又会如何选择呢？。

针对这个问题，我认为这里至少应该给出两个答案，一个是书本上那个，另一个是相反的情况的，也就是这个需求并不是像安全性这么重要的需求，让同学们也能从商业性上进行考量，从而让同学们知道需求的确定并不是单一的，而是需要综合来看的，并且我觉得这样能够启发同学们更加全面的思考问题。

以上是我的问题和观点，欢迎讨论。

2.敏捷开发流程的疑问（P121）

书上P121页的表格列出了敏捷开发方法的使用范围，其中的客观因素中有这两点：

人员经验：有资深程序员带队；
需求变化：经常变化；

结合本课程的学习内容和对书本的思考，我有以下疑问：

敏捷开发方法需要有资深程序员带队，可是我们团队中大多都是小白（初级中的初级程序员），将如何更真实的体会到敏捷之道呢？其次我们在课程后期的团队项目中要如何保证需求的不断变化呢？如果这两点不能很好的满足是否能够达到本课程学习的目标呢？

3.TDD（测试驱动开发）

在看敏捷开发流程的时候，注意到了书上提到的一种敏捷开发的工程实践方法——TDD（测试驱动开发），这里想问一下：测试驱动开发将设计放在了什么位置（或是地位）？TDD在实践的时候先编写测试用例是严格遵守的吗？TDD实践过程中是小步前进，这个小步的大小该如何确定？

有人认为在实践中也可以先实现功能代码，然后再补写测试用例，但是必须在实现完成后马上补写测试（深度解读 - TDD）。我认为既然TDD的中心思想是测试驱动，那是否就应该严格保证测试用例的先行呢。

由于实践太少，并不能很好的把握理解这些方法。

4.风险管理（第九章）

“没有风险，就是最大的风险”

第九章结尾的这句话，我对于自己的理解不太确定，下面是我的理解：

在项目中可能会遇到各种各样的风险，很多情况下PM都是在尽可能的减少这些风险的存在，但是这些风险有时候也代表了一些机遇。这里的“没有风险”其实并不是真正的不存在风险，我认为有两层意思：

项目人员没有风险意识，所以才会说没有风险，这种没有意识到风险的风险才是一个项目中最大的风险。
对于已知的风险，我们是可以去应对的，但是对于未知的风险（也就是没有风险的状态），我们是无法做准备的，所以这才是最大的风险。

5.结对编程（第四章）

看完书上对结对编程的介绍，我发现其实在之前的编程实践中自己有践行过这种方案的，现在也是十分认同这种方式。书上给的结对编程的方式是领航员和驾驶员模型，在网上查看的结对编程和书上的观点也基本一致，这里我想问的是：

结对编程一定要两个人保持这样的方式工作，直到项目完成吗？是否可以在大多数关键代码上实行这种方式，而在简单的部分采用分开编码，从而提高编码效率，这里分开编码只是意味着不同的电脑，还要会保证及时的面对面交流的。

请问“软件”和“软件工程”这些词汇的起源

“软件”一词最早在工程背景下是由Richard R.Carhart在兰德公司研究备忘录中于1953年8月出版的。
“软件工程”一词第一次出现在1965年6月出版的计算机和自动化公司提供的服务清单中。玛格丽特·汉密尔顿（Margaret Hamilton）提出了将该学科命名为“软件工程”的想法，以此作为赋予其合法性的一种方式。

软件工程发展过程中的冷知识

埃达·洛夫莱斯原姓拜伦（Byron），是一位英国数学家兼作家，代表作是她为查尔斯·巴贝奇的分析机——机械式通用计算机——所写的作品。她是第一位主张计算机不只可以用来算数的人，也发表了第一段分析机用的算法。因此，埃达被公认为史上第一位认识计算机完全潜能的人，也是史上第一位计算机程序员.

目前流行的源程序版本管理软件和项目管理软件

几大流行版本管理项目的使用人数排名

1.GitHub: 大约31,000,000名用户
2.Launchpad: 大约3,965,288名用户
3.Bitbucket: 大约5,000,000名用户
4.SourceForge: 大约3,700,000名用户
5.GitLab: 大约100,000名用户

各项目管理软件的优缺点

GitHub

优点
1. 可以作为版本控制系统和协作工具，用它来发布工作。
2. 利用GitHub，可以将项目存档，与他人分享交流，支持多人共同完成一个项目。
3. 创建自己的项目，并备份，代码不需要保存在本地或者服务器。
4. 可以跟踪错误，Bugs可以公开，可以通过GitHub评论，提交错误。
5. 分支能力特别强大，体验特别好。加上支持离线提交，分布式推送拉取，使得代码层面的协作相当流畅。
缺点
1. 适合代码追踪，却不是最好的设计跟踪工具。
2. 需要较大的学习成本，不断实践。
Microsoft TFS

优点
1. 共享代码，跟踪工作，针对专业团队的开发人员工具的集成服务器套件。
2. 与现有IDE或编辑器集成，是跨功能团队可以在所有大小的软件项目上高效工作。
3. 版本控制，使用无限制专用存储库对代码进行存储并协作编写代码，管理权限和策略以保护你的存储库。
4. 通过积压工作 (backlog) 和可自定义的看板捕获和跟踪工作情况，并确定工作优先级。通过直接链接到代码和生成的工作项目，确保透明性和可跟踪性。
5. 通过持续集成 (CI) 版本在早期发现质量问题。使用发布管理自动化跟踪你的所有部署。使用我们广泛的测试工具组来维护较高的质量。通过重复使用代码和模块更快地交付程序包管理。
缺点
1. 搭建、维护TFS比较复杂，硬件要求也比较高。
Trac

优点
1. Trac做一个SCM配置管理平台，意味着它有良好的扩充性。
2. Trac的权限体系是比较完备的设计。
3. 非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
缺点
1. 不支持多项目，需求和缺陷没有分离。
2. 核心功能很少，不安装插件基本上没法用。
Bugzilla

优点
1. 优化的数据库结构可提高性能和可扩展性。
2. 出色的安全性以保护机密性。
3. 高级查询工具，可以记住您的搜索。
4. 可编辑的用户档案和全面的电子邮件偏好。
缺点
1. 安装过程比较繁琐，修改配置文件比较麻烦。
2. 中文支持还不够好。