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

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

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

1.第一章第7页

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

1. 根本不考虑
2. 若是没时间实现这个功能，就算了
3. 作了，可是不用告诉用户
4. 作了，并且不厌其烦的告诉用户如何使用

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

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

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

以上是个人问题和观点，欢迎讨论。

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

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

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

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

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

3.TDD（测试驱动开发）

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

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

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

4.风险管理（第九章）

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

第九章结尾的这句话，我对于本身的理解不太肯定，下面是个人理解：

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

1. 项目人员没有风险意识，因此才会说没有风险，这种没有意识到风险的风险才是一个项目中最大的风险。
2. 对于已知的风险，咱们是能够去应对的，可是对于未知的风险（也就是没有风险的状态），咱们是没法作准备的，因此这才是最大的风险。

5.结对编程（第四章）

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

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

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

• “软件”一词最先在工程背景下是由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. 中文支持还不够好。

参考资料

[1]https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities

[2]http://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29

[3]http://en.wikipedia.org/wiki/John_Tukey