软件工程第一次阅读作业

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

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

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

11. 类型继承

    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. 流程无法定制