软件工程个人博客作业

软件工程个人博客作业

软件工程个人博客作业

一、作业要求简介

项目	内容
本作业属于北航软件工程课程	博客园班级链接
作业要求请点击链接查看	作业要求
我在这门课程的目标是	系统学习软件开发理论和流程，通过实践积累软件开发经验
这个作业在哪个具体方面帮助我实现目标	了解软件工程及基本内容

二、正文

1.快速看完整部教材，列出你仍然不懂的5到10个问题

①关于goto使用的问题

函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。

书中第四章代码设计规范4.3.2中提到为保证函数出口唯一，可以使用goto，但是根据我在程序设计课程和面向对象课程中的学习来看，老师都是极力阻止我们使用goto，原因是goto打乱了代码的结构，不易于之后的阅读和调试，这里却说goto有助于程序逻辑清晰体现，这之间是否冲突？如果不冲突，如何在代码结构和程序逻辑之间找到一个平衡点？

②关于复审的问题

复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问题，复审者不必亲自调查每一件事，开发者有义务给出详尽的回答。

书中第四章4.4.2代码复审的步骤第6条如上，我并不觉得开发者必须详尽回答复审者每一个吹毛求疵的问题，因为很多时候不是开发者代码的问题而是复审者没有理解代码，如果复审者并没有仔细弄清楚代码的原理，自然会有很多不明白的地方，如果不自己研究而是每个问题都去问开发者，那会不断的打断开发者当前的任务，极大地拖慢开发者的进度，我觉得复审者还是应该有一定程度的调查之后，如果还有不明白的地方再去问开发者会更好。

③关于任务时间估计以及划分

软件工程师在长期的实践中，摸索出一套经验公式：实际时间花费主要取决于两个因素—对某件事的估计时间X，以及他做过类似开发工作的次数N。

Y = X ± X ÷ N //注：Y是实际时间花费。

——8.6

在项目开始之前，有很多队员还没有接触过编程语言（例如C#），导致PM在分配任务时很难用时间来衡量，就拿写一个Web Service这一模块来说，一个熟练的程序员可能只需要两个小时，而对于初学者来说，就得先花两天来理解Web Service的实现机制和原理。在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。这时应该怎么办？

阿超：对于这些队员，可以考虑在他们自己的任务估计值之上再乘以4。

——11.6

如果一个任务的估计时间太长（如超过16个小时），那么它就应该被进一步分解。

——6.1.2

按照书上给的时间估计方法，对于接触类似项目比较少的人来说，所估计的任务所需时间往往会很长，在书中敏捷开发流程中所讲，对于超过16小时的任务应该继续细分，像这样用时间划分任务往往不准确，会对项目的进度产生很大的影响，有没有更适合新手的任务划分方法？

④构建自动化验证测试的输入数据设计问题

顾名思义，构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。

书中第十三章介绍了构建验证测试，并提倡让验证测试自动运行，但具体的测试数据设计方面，并没有详细的说明。根据我在大二面向对象课程上的经历，写脚本来测试程序的正确性虽然方便，但确实存在弊端。设计输入数据时往往是根据自己对输入要求的理解来设计，其中难免会出现自己理解的误区和盲区，在自己写程序的时候理解错或没注意到的地方在设计测试数据的时候同样也没没注意，这就导致自己写的自动化验证测试无法测出自己程序的错误，虽然可以多个同学在一起相互测试，但是这种自动化测试只能测出一些基本的审题不当或者格式错误，对于程序中的一些小的逻辑错误，随机生成的测试数据可能一天也测不出一个问题，往往不及精心构造的数据效率高，所以如何才能自动的生成质量比较高的测试数据呢？

⑤关于创新与重构的问题

如何帮助创新软件工程中有没有一些做法是帮助创新的呢？当然有很多，例如：快速原型，持续重构，在每一个里程碑之后做总结，等等。

书中十六章创新16.6的第4问中提到持续重构能帮助创新，但是在面向对象课程的学习后了解到好的代码必须有很强的可扩展性，尽量避免重构。重构到底是好是坏？创新和好的代码架构是否有冲突？

2.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？

软件：

最早已知的记录是Tukey在1958年发表的论文"The Teaching of Concrete Mathematics"中包含了“ 软件 ” 一词。
Paul Niquette声称他最初是在1953年10月创造这个词的，尽管他找不到任何支持他主张的文件。

软件工程：

“软件工程”一词是1968年北大西洋公约组织 NATO 在联邦德国召开的一次会议上首次提出的。
Hamilton在早期的阿波罗任务中开始使用“软件工程”一词。

3.请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

Facebook创始人Mark Zuckerberg之所以创办Facebook是因为哈佛是一个“非常不友好的地方”，他希望所有的学生都能在网上自由交流。他之所以在Ivy学校最先推出Facebook，这是因为哈佛学生与这些学校的学生的交集面更大，而不是因为这些学校是名校的缘故。而令他意想不到的是，Facebook用户并没有因为自己的个人信息容易在网上被跟踪而去抱怨。

4.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些，各有什么优缺点？

Microsoft TFS
- 优点：是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言很有用。
- 缺点：搭建、维护TFS比较复杂，硬件要求也比较高。能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。
Git
- 优点：可进行分布式开发，切换分支灵活，本地操作可以不同步到远程。可离线工作，有良好的冲突处理机制。
- 缺点：git没有严格的权限控制，一般是通过系统设置文件的读写权限来做权限控制。工作目录只能是整个目录。git上手需要长时间学习。
Mercurial
- 优点：更轻松的管理，更健壮的系统，对网络的依赖性更低。简单易学、易于使用。轻量级，运行快速。可扩展性好，易于根据用户需求自行定义、扩展。
- 缺点：改写历史很麻烦，难以还原错误操作之前的状态，容易导致版本库混乱，也容易出错导致丢失历史。没有命名空间，一但和很多个版本库交流，很容易导致自己与别人的代码混成一团。市场小。
GitHub
- 优点：GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
- 缺点：可能不是捕捉创意过程和记录创意点子的最佳工具。
Bitbucket
- 优点：提供无限的免费私人仓库，提供5人以内免费合作开发账户，支持git。
- 缺点：搜索界面过于简单，项目不容易被人找到。
Trac
- 优点：有良好的扩充性，非常灵活，权限体制比较完备。
- 缺点：不支持多项目，需求和缺陷没有分离。中文化不完整，编辑文档门槛高，核心功能少。
Bugzilla
- 优点：不收费，支持中文。
- 缺点：只能管理缺陷。
Rational
- 优点：迭代开发过程、需求管理、基于组建的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面好。团队工作使用方便。
- 缺点：个人用户的功能使用不便。
Apple XCode
- 可以自动创建分类图表。自动提供撤消、重做和保存功能，无需编写任何编码。
- 缺点：更新版本后，某个插件可能会失效。