| 项目 | 内容 |
|---|---|
| 本作业属于北航软件工程课程 | 博客园班级链接 |
| 作业要求请点击链接查看 | 作业要求 |
| 我在这门课程的目标是 | 成为一个具有一定经验的软件开发人员 |
| 这个作业在哪个具体方面帮助我实现目标 | 让我对自己目前的状况有一个更加清醒的认识 |
类型继承
1）仅在必要时，才使用类型继承
2）用const标注只读的参数
3）用const标注不改变数据的参数
我的疑惑点主要是在第1条原则。在上上学期的面向对象课程中，我们学到了类的继承是一个很实用的方法，它可以帮助我们减少代码之间的重复，并且体现出设计的层次感。但《构建之法》的意思似乎是在说，要尽量避免使用类型继承。在实际的工程中，类型继承是被提倡使用的吗？
结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作导致观察力和判断力下降。
前文中作者提到，结对编程可以类比于现实中的一些搭档关系：越野赛车（驾驶、领航员）、驾驶飞机（驾驶、副驾驶）。但是在这些领域中，搭档的职务往往是固定的，这是因为两个人往往在不同的岗位上有不同的经验，让在某一个岗位具有更丰富经验的人去担任这一职务，比两个人交换岗位、在自己不熟悉的领域工作，要合适的多。因此，结对编程中驾驶员和领航员经常角色互换，是否是一个合理的选择？
我同意第一印象很重要，但是当用户已经是第N次使用你的产品时，你的UI能否为这些用户提供方便呢？
软件开发、尤其是面向大量用户的软件开发，一个很困难的问题就是如何定义“方便”以及“好用”这种很主观的概念。以最近微信发布的7.0.0版本为例，整个微信的界面底色由黑色变成了白色，这一改动在用户的评论当中毁誉参半，一部分人（比如我）认为这个版本的审美比之前的不知高到哪里去了，而另一部分用户则认为新版微信亮得晃眼睛。作为PM、开发人员、UI设计师，该怎么权衡不同用户对于同一套UI的相反评价？
一个软件有很多可能的输入和环境参数，我们没有能力穷举所有的可能，也没有必要。我们可以运用不同的设计测试用例的方法，有效地生成测试用例。
我在做软件测试的时候，遇到的最困难的问题是如何处理有副作用的方法。这里的“有副作用”代表该方法与外界有交互，比如从控制台读入一行字符串，又或者是连接一个数据库。如果我想对这些方法进行测试，就需要模拟出一整个环境，这在紧张的快速开发中是难以做到的。因此，在设计单元测试用例时，我往往会选择跳过这些有副作用的方法，只测试那些纯函数。但软件的Bug往往是在这些与系统有交互的地方产生的。所以我想知道，该如何为这些方法设计完备的测试用例，尤其是当方法的副作用很复杂、环境难以模拟的时候？
软件开发过程中的可见性（ Visibility）
我们看这个项目开发过程中的场景：
领导：进度如何？
答：可能快了。
问：能看看演示吗？
答：嗯，不知道。可能到了项目的最后一天才能看......
上面的对话不能说明软件的功能如何（也许最后发现功能非常惊艳），项目的可见性是非常差的。不但是小规模、业余项目会出现这样的情况，大规模的专业团队也是如此。
上面的场景是我在项目开发中经常遇到的实际问题。很多时候，我编写的软件是偏后台的，甚至只是一个命令行交互程序，不像Web开发和GUI开发那样具有非常好的可见性。还有一些情况是，我的软件是高度模块化的，只有当最后一个模块完成的那一刻才能够组合在一起，在此之前无法单独展示。把项目做成可展示的形式需要花费大量的时间，尤其是编写用户交互界面更是一件费时费力的事情。而项目展示要求的是美观和易用，这就给项目的可见性带来了更多的压力，因为许多开发人员都不愿意去写界面，更不愿意去给一个单独的模块写GUI，有这时间的话他们宁可去完善功能。但是项目的展示又是非常重要的，项目的投资者往往会很看重开发过程中的展示。在实际的工程开发中，该如何做好项目的可见性？
历史上出现的有关软件工程有趣故事并不多，我只能在此写一个前不久发生的事情，即”产品经理和程序员打架“事件。该事件于此链接中有详细描述，下图是事情经过的精华加工版。
这让我想起一则笑话：
- ”为什么计算机领域没有民科？“
- ”当然有，不然你以为产品经理是哪儿来的。“
这只玩笑，但产品经理是软件工程中一个重要的岗位，产品经理提出的需求往往很大程度上影响了软件产品的最终质量。因此，在软件工程中，一个团队里产品经理和技术人员的沟通就显得尤其重要，这也是我在软件工程课程中应该注意的事情。
现有的版本控制软件如下图所示。
流行的版本控制软件的用户数如下图所示。
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. 流程无法定制 |
转载于:https://www.cnblogs.com/zhouyufei/p/10471800.html
