软件工程第一次阅读做业

项目	内容
本做业属于北航软件工程课程	博客园班级连接
做业要求请点击连接查看	做业要求
我在这门课程的目标是	成为一个具备必定经验的软件开发人员
这个做业在哪一个具体方面帮助我实现目标	让我对本身目前的情况有一个更加清醒的认识

1. 快速阅读完教材仍然不懂的问题

1. 第4章 两人合做 4.3.4 如何处理C++中的类

1. 类型继承

   1）仅在必要时，才使用类型继承

   2）用const标注只读的参数

   3）用const标注不改变数据的参数

个人疑惑点主要是在第1条原则。在上上学期的面向对象课程中，咱们学到了类的继承是一个很实用的方法，它能够帮助咱们减小代码之间的重复，而且体现出设计的层次感。但《构建之法》的意思彷佛是在说，要尽可能避免使用类型继承。在实际的工程中，类型继承是被提倡使用的吗？

2. 第4章 两人合做 4.5.3 不间断地复审

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

前文中做者提到，结对编程能够类比于现实中的一些搭档关系：越野赛车（驾驶、领航员）、驾驶飞机（驾驶、副驾驶）。可是在这些领域中，搭档的职务每每是固定的，这是由于两我的每每在不一样的岗位上有不一样的经验，让在某一个岗位具备更丰富经验的人去担任这一职务，比两我的交换岗位、在本身不熟悉的领域工做，要合适的多。所以，结对编程中驾驶员和领航员常常角色互换，是不是一个合理的选择？

3. 第12章 用户体验 12.1.3 软件服务始终都要记住用户的选择

我赞成第一印象很重要，可是当用户已是第N次使用你的产品时，你的UI可否为这些用户提供方便呢？

软件开发、尤为是面向大量用户的软件开发，一个很困难的问题就是如何定义“方便”以及“好用”这种很主观的概念。以最近微信发布的7.0.0版本为例，整个微信的界面底色由黑色变成了白色，这一改动在用户的评论当中毁誉参半，一部分人（好比我）认为这个版本的审美比以前的不知高到哪里去了，而另外一部分用户则认为新版微信亮得晃眼睛。做为PM、开发人员、UI设计师，该怎么权衡不一样用户对于同一套UI的相反评价？

4. 第13章 软件测试 13.3.2 测试工做中的文档 2. 测试用例

一个软件有不少可能的输入和环境参数，咱们没有能力穷举全部的可能，也没有必要。咱们能够运用不一样的设计测试用例的方法，有效地生成测试用例。

我在作软件测试的时候，遇到的最困难的问题是如何处理有反作用的方法。这里的“有反作用”表明该方法与外界有交互，好比从控制台读入一行字符串，又或者是链接一个数据库。若是我想对这些方法进行测试，就须要模拟出一整个环境，这在紧张的快速开发中是难以作到的。所以，在设计单元测试用例时，我每每会选择跳过这些有反作用的方法，只测试那些纯函数。但软件的Bug每每是在这些与系统有交互的地方产生的。因此我想知道，该如何为这些方法设计完备的测试用例，尤为是当方法的反作用很复杂、环境难以模拟的时候？

5. 第14章 质量保障 14.1.2 软件工程的质量

软件开发过程当中的可见性（ Visibility）

咱们看这个项目开发过程当中的场景：

领导：进度如何？

答：可能快了。

问：能看看演示吗？

答：嗯，不知道。可能到了项目的最后一天才能看......

上面的对话不能说明软件的功能如何（也许最后发现功能很是惊艳），项目的可见性是很是差的。不可是小规模、业余项目会出现这样的状况，大规模的专业团队也是如此。

上面的场景是我在项目开发中常常遇到的实际问题。不少时候，我编写的软件是偏后台的，甚至只是一个命令行交互程序，不像Web开发和GUI开发那样具备很是好的可见性。还有一些状况是，个人软件是高度模块化的，只有当最后一个模块完成的那一刻才可以组合在一块儿，在此以前没法单独展现。把项目作成可展现的形式须要花费大量的时间，尤为是编写用户交互界面更是一件费时费力的事情。而项目展现要求的是美观和易用，这就给项目的可见性带来了更多的压力，由于许多开发人员都不肯意去写界面，更不肯意去给一个单独的模块写GUI，有这时间的话他们宁肯去完善功能。可是项目的展现又是很是重要的，项目的投资者每每会很看重开发过程当中的展现。在实际的工程开发中，该如何作好项目的可见性？

2. “软件”和“软件工程”这些词汇是如何出现的？

• 化学家和统计学家约翰·图基（John W. Tukey）在1958年撰写一篇科学文章时，首次使用“软件”这一术语。据报道，他早在1953年就已经提出这个词，用来标记计算机程序（即“软件）与使用这些程序的计算机（或“硬件”）之间的区别。
• 1968年NATO会议上首次提出“软件工程”（Software Engineering）的概念，提出把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工做”转化。其基本思想是应用计算机科学理论和技术以及工程管理原则和方法，按照预算和进度，实现满用户要求的软件产品的定义、开发、发布和维护的工程。今后也诞生了一门新的学科——软件工程。

3. 软件工程发展的过程当中，出现的有趣的冷知识和故事

历史上出现的有关软件工程有趣故事并很少，我只能在此写一个前不久发生的事情，即”产品经理和程序员打架“事件。该事件于此连接中有详细描述，下图是事情通过的精华加工版。

这让我想起一则笑话：

- ”为何计算机领域没有民科？“

- ”固然有，否则你觉得产品经理是哪儿来的。“

这只玩笑，但产品经理是软件工程中一个重要的岗位，产品经理提出的需求每每很大程度上影响了软件产品的最终质量。所以，在软件工程中，一个团队里产品经理和技术人员的沟通就显得尤为重要，这也是我在软件工程课程中应该注意的事情。

4. 目前流行的源程序版本管理软件和项目管理软件及其优缺点

现有的版本控制软件以下图所示。

流行的版本控制软件的用户数以下图所示。

Git、Mercurial、Trac和Bugzilla的优缺点以下表所示。

软件名	优势	缺点
Git	1. 适合分布式开发，强调个体 2. 公共服务器压力和数据量都不会太大 3. 速度快、灵活 4. 任意两个开发者之间均可以很容易地解决冲突 5. 离线工做	1. 学习周期较长 2. 不符合常规思惟 3. 代码历史保密性差，一旦开发者把整个库克隆到本地，就能够彻底查看到全部的历史版本信息
Mercurial	1. 更简洁好用的命令行指令 2. 上手简单 3. 完善的GUI支持 4. 易于扩展	1.Mercurial的分支模型十分复杂，每一种分支方法都有不少缺点和不便之处 2. Mercurial改写历史很麻烦 3. 没有命名空间
Trac	1. 很是灵活，能够为所欲为地定制 2. 能够和SVN集成 3. Trac的权限体系是比较完备的设计	1. 不支持多项目 2. 中文化不完整 3. 核心功能不多，不安装插件基本没法使用
Bugzilla	1. 检索功能强大 2. 强大的后端数据库支持 3. 根富多样的配置设定	1. 安装须要Perl和配置MySQL数据库，过程比较繁琐2. 修改配置文件很麻烦3. 流程没法定制