软件工程第一次作业
| 项目 | 内容 |
|---|---|
| 课程 | 软件工程 |
| 作业要求 | 个人博客作业 |
| 我的课程目标 | 开发“足够好”的软件 |
| 这个作业对我实现目标的帮助 | 阅读《构建之法》，在大量实践之前对软件工程有宏观理解 |
1.快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上
问题1 第一章 概论 提到一个软件企业有很多赚钱方式
- 有的交钱买断
- 有的“先试用再交钱”，有些软件也提供试用版、免费版和正式版，还有的类似期刊订阅，每年交钱
- 有的不但免费，连源代码也一并奉送，但是要求获得源代码的开发人员遵守某种协定
- 有的送硬件，但是软件要收钱
- 有的送软件，但是硬件要收钱
- 也有“免费用，但是要看我提供的广告”
- 还有“免费用，程序也不是我写的，如果有问题，给我钱，我就来提供咨询……”
世面上很少有软件是免费并且开源的，因为开源意味着软件的开发与实现不再是秘密，将使软件失去盈利的资本。那么发布开源软件的企业希望从中获取什么利益呢？
我查到著名的开源软件如下
| 软件 | 说明 |
|---|---|
| Linux | Linux 是一款开源的操作系统，它的内核由多名极客共同维护。Linux 是开源软件的经典之作、代表之作、巅峰之作。 |
| Apache | 世界使用排名第一的 Web 服务器软件。 |
| MySQL | 世界上最流行的关系型数据库，适合中小型网站。 |
| Firefox | 火狐浏览器。在 Chrome 推出之前，Firefox 几乎是最快速的浏览器，直到现在也是 Web 开发人员的调试利器。 |
| OpenOffice | 套跨平台的办公软件套件，类似 Microsoft Office。 |
| GCC | C语言/C++编译器。 |
| Java、PHP、Python | 开源的编程语言。 |
与其相对的是私有/专属软件，如很多来自微软和苹果的软件，很多用户对他们的收费软件甚至产生了依赖。支撑开源软件的仅仅是极客的信念吗？
问题二 第二章 好的单元测试的标准 一节，提到
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
我部分认同这个观点，但还有一些疑惑，就是一个“写出bug的人”是否是写“找出bug的单元测试”的最佳人选。代码作者对自己的代码有很大盲区，在编造单元测试时可能仍然没有意识到代码中的问题，而不能筛查出bug。
通过上下文的内容，我推测单元测试只是筛查bug的第一步，用于测试代码的基本功能。另外一些作者找不出来的bug，留给同伴复审代码的时候进一步找出。原文如下，
下面是验证单元测试好坏的一系列标准：单元测试应该在最基本的功能/参数上验证程序的正确性。单元测试应该测试程序中最基本的单元—如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成）。
问题三 第二章 好的单元测试的标准 一节，又提到
问：如果用随机数以增加测试的真实性，好么？
答：一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，则于事无补。我们还是要用随机数等办法“增加测试的真实性”，但不是在单元测试中。单元测试不能解决所有问题，不必期望它会发现所有的缺陷。
根据面向对象这门课的经验，写一个复杂程序并提交评测（比如表达式运算），由于评测机是黑箱测试，会出现很多顽固的bug很难人为地找出来。一般会构造复杂的测试集，甚至用评测机随机生成很长的测试样例。
我认为一个软件在颁布给用户使用前，也存在着很难发现的bug，如果直接推向市场广大用户会逐渐发现问题。根据教材，单元测试不能使用随机数，那么很难侦测这样的bug。我推测单元测试跟我刚才说的测试方式就是两个都要经历的不同的测试阶段吧。
另外我觉得不用担心随机数导致程序出错的无法复现，用日志记录下出错的样例就可以了。那多线程程序确实有无法复现的问题，怎么单元测试呢？
问题四 第十五章 设计变更 一节，提到了重构
重写或重构
小飞：我们的某某模块真是太烂了，我觉得必须重写，而且现在又有了新的技术叫“我佩服”（WPF）[或插入任一最近时髦的技术]，它能做很酷的效果，为什么不呢？
二柱：我们先要看看，原来烂到什么程度，现在是否能完成功能？你所说的问题有多严重？是功能不能实现？或者界面有问题？或者不能扩展（例如：不能支持更多用户）？
大栓：另外，是重构，还是重写？重构——在尽量保持原有界面的基础上优化部分代码。重写——重新实现原有功能，同时，要分清是全部重写原有功能，还是偷偷加上许多新的功能（Feature Sneak）？
重构的时机让我有一点困惑。我面临过重构的情况一般是，要求程序实现的功能增加了，原来的代码框架很难优美地加上这个功能，因此要重新组织代码。但重构的工作量很大，不改变代码框架硬加上新功能也可以。有时我把握不好该重构还是将就。
我认为遇到重构是因为原来的程序没有为拓展功能预留合适的接口，但有时未来需求是未知的，貌似预留前瞻性的接口不只是技术，还要靠运气。有什么无论如何拓展都通用的预留接口的原则，以减少重构次数？
问题五 第一章 谈到软件的复杂性，
软件可以说是人类创造的最复杂的系统类型。大型软件（操作系统、办公软件、搜索引擎）有超过百万行的源代码，上万个不同的文件。而软件工程师通常一次只能看到30—80行源代码（相当于显示器的一屏），他们的智力、记忆力和常人差不多。软件的各个模块之间有各种显性或隐性的依赖关系，随着系统的成长和模块的增多，这些关系的数量往往以几何级数的速度增长。
阅读百万行级的代码是很耗时的，参与研发的程序员都要通读百万行代码吗？超大型软件是否也依靠分层结构，解决某个问题的程序员只要读完对应层次的代码，其他层级对其是相对透明的呢？
2.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件
In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics"[10][11] contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.[12] This led many to credit Tukey with coining the term, particularly in obituaries published that same year,[3] although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim.[13] The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a RAND Corporation research memorandum.[14]
--Wikipedia
- John Tukey在1958年发表的论文"The Teaching of Concrete Mathematics"提出“software”一词，大家普遍认为是这篇论文首次提出这个术语，但他本人没有做出声明。
- Paul Niquette 声称他在1953年10月首次提出这个术语，但是没有找到支持文件。
- Richard R. Carhart在1953年8月的科研备忘录中也提出这个术语，被认为是发表物中最早出现的。
软件工程
Margaret Hamilton在二十世纪六十年代，主持阿波罗登月任务的软件程序计划的时候提出“软件工程”一词。
软件在阿波罗计划的初期完全不像其他工程学科，例如像硬件工程那样的受到重视，而且在大家的眼光中他像是艺术，而不是一门科学。Hamilton致力于为软件以及那些发明者争取应有的正统性与尊重，所以她开始使用“软件工程”这样的字眼来将之与硬件还有其他工程学类做出区别。
3.知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
互联网的成功，可从“Internet”这个术语的大、小写分化窥知一二。最初，互联网一词代表那些使用IP协议架设而成的网络，而今天，它已引申泛指各种类型的网络，不再局限于IP网络。于是以小写的互联网（internet，开头的“i”是小写字母）为任何分离的实体网络之集合，这些网络以一组通用的协议相连，形成逻辑上的单一网络。而大写的互联网（Internet，开头的“I”是大写字母）专指前身为ARPA网，后使用IP协议将各种实体网络连接成此单一逻辑网络。大写的互联网是小写互联网的其中一种形式，反过来却不然。
2002年起，有学者开始提议将“internet”一词用小写表示，理由是互联网已经成为人类生活的一部分，失去了专有的意义；2016年，美联社认为“互联网”已和“电话”一样成为一件一般的事物，不具有专属商标的意义，于是开始在其格式手册中规定“internet”和“web”一词全部小写，纽约时报也随后跟进，但同时亦有媒体提出不同意见。
4.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
版本管理软件分类
Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode
Microsoft TFS
优点：
- 任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用集成了项目管理、版本控制、BUG 跟踪。
- 能有效实现 SCRUM能与 VS 无缝接合。
缺点：
- 搭建、维护tfs比较复杂，硬件要求也比较高。
- 整个系统是用 asp 实现的，用浏览器访问相当慢。
git
优点：
- 适合分布式开发，强调个体。
- 公共服务器压力和数据量都不会太大。
- 速度快、灵活。
- 任意两个开发者之间可以很容易的解决冲突。
- 离线工作。
缺点：
-
资料少（起码中文资料很少）。
-
学习周期相对而言比较长。
-
不符合常规思维。
-
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
Mercurial（hg）
优点：
- 学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。
- 可以一键完全恢复到历史版本的某一个切面。
- 封装好。相比git，hg很少暴露一些实现内的细节。
缺点：
- 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。
GitHub
优点：
- 免费且开源。
- Git支持分支功能（branch）。
- 支持离线工作。本地提交可以稍后提交到服务器上，不用和集中的代码管理服务器交互。 只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。
- Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。
- 简易的初始化。对于随便写两行代码就要放到代码管理工具里的人来说，再合适不过。
缺点：
- 学习成本大。由浅入深的过度很漫长，需要大量时间的投入。
- Git版本库需要频繁的手动维护。
bitbucket
优点：
- 提交大文件速度很快。
- 私人项目免费。
- 不限容量。
缺点：
- 不开源。
- 系统不稳定。
Trac
优点：
- 有良好的扩充性。
- 权限体系是比较完备的。
- 非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
缺点：
- 不支持多项目。
- 需求和缺陷没有分离。
- 用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了。
- 中文化不完整，美术人员接触起来困难重重。
BUGZILLA
优点：
- 不收费。
- 现在有中文版支持。
缺点：
- 只能管理缺陷。
Apple XCode
优点：
- 可以自动创建分类图表。
- 自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：
- 更新版本后，某个插件可能会失效。
5.尝试使用一些版本管理工具
Git
Mercurial
使用感想
创建仓库，提交更改等基本命令是相似的，但-option有区别；
Mercurial的命令更少；
Mercurial的分支管理相比Git不太方便。
