第一次个人博客作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 提升团队编程能力，掌握软件工程基础 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，初步了解和思考软件工程相关概念 |
一、阅读后提出问题
- 关于第二章2.1（P22）中介绍的单元测试，如何进行藕连模块的单元测试
单元测试的作用是保证模块的稳定和正确。但在实际情况中存在模块之间的藕连，例如游戏中的跳跃模块和技能模块会出现藕连——比如某些技能需要依托跳跃释放。这种情况下如何设计单元测试？
查阅之后得到的结论是主要有有全测（即测试覆盖所有模块）和全不测（即假设所关联模块是正确的）两种处理方法。而我的想法是能否根据模块间的关系将不同模块分组后设计一个大的组合单元测试来验证藕连模块之间的正确性。
- 关于第六章6.2（P117）中提到了几种敏捷开发会遇到的问题与应对情况，那么如何应对会议时间过长这个问题
我在实习时发现每日例会占用了敏捷开发极大的时间，这个问题在策划层尤其明显，由于需要对接各个功能团队的工作，例会就包括了每日的对接会议。而另一方面决策会议往往一次无法有效的讨论出结果，这个问题无论是在小团队开发还是在大公司开发都会出现，即一个会议讨论了半个甚至一个小时以上都始终在争论一些细节的始末，从而无法有效推动会议进程。而这两点的结果往往是一天6小时的工作时间有两到三小时是在开会中度过的，极大的降低了开发效率，我想知道这种敏捷开发中遇到的问题要如何应对。
- 关于第八章8.1（P157）软件需求中提到了软件需求主要由用户需求与技术性需求组成，由此我思考创新需求是否也是软件需求要考虑到的需求
举个例子，随着iPhone等智能手机的推出，手机游戏的市场越来越大，而暴雪这家主要用户都是PC用户的公司想要向手游进军，但由于此公司长期开发PC游戏，手机游戏方面经验匮乏，需要开发一些手游来积累经验。此时出现了一种矛盾，暴雪的用户需求是新的PC游戏，而此时暴雪的创新需求（我自定义的需求）是手机游戏。作为一家互联网公司肯定不能墨守陈规而不积极求变，但是求变所需的创新与尝试又会与公司已经积累的用户的需求产生矛盾，这种矛盾是否需要考虑到软件需求中去，如果考虑进去，又该如何平衡这种矛盾？
- 第十五章15.1（P330）提到了几种面对软件发布DDL处理bug的方法，但却跳过了延期发布，我想知道什么时候应该选择延期
书中关于延期发布的原文如下
有人会举出世界著名的公司为了“完美”而不惜推迟发布时间的例子，例如苹果公司的一些产品，著名的游戏“永远的会面公爵”，等等...请问：iPhone的第一个版本是完美的么？它连复制/粘贴的功能都没有，但他还是发布了
但其实这段话更在于强调产品发布时不可能完美而不是延期发布的方法不可行，不过后文也未将延期发布作为一种应对处理临近发布事态的一种办法进行介绍，而现实中有不少的产品均会选择在发售日期来临前延期，因此我想知道什么时候该选择延期而什么时候该选择按原计划发布。
- 第十六章16.2（P362）指出过早的提出一些在业内人士看来优秀的创新无法被大众所接受，我在思考过早的创新也是有意义的
即虽然创新不能被用户接受，但却能很好的启发同行，具有非凡的意义。例如世嘉于1999年发布的游戏《莎木》，虽然在当年却只有十分惨淡的销量，但是这款游戏在当年作出的电影式叙事方法和QTE系统等创新在如今无一不被主流游戏所频繁使用。而对于接受了这款游戏的创新的用户而言，这款游戏是完美的。这些用户的体验使得其他游戏公司看到了这些创新的价值并付诸实践，最终证明了《莎木》的游戏模式是具有时代意义的。可以说有些创新虽然无法取得商业成功，但也能具有推动行业发展的价值，所以过早的创新（超前于同行的创新）也是具有实现价值的。
二、“软件” 和 “软件工程” 这些词汇是如何出现的？
关于“软件”即“software”一词的来源，维基百科上解释是
the first theory about software prior to creation of computers as we know them today was proposed by Alan Turing in his 1935 essay Computable numbers with an application to the Entscheidungsproblem (decision problem)
即在1935年图灵的一篇题为“Computable numbers with an application to the Entscheidungsproblem”的文章中第一次使用并解释了“software”一词及其相关理论
而“软件工程”一词根据《构建之法》中所述是在1968年Margaret Hamilton于阿波罗计划期间发明创造出来的
三、软件工程发展的过程中有什么你觉得有趣的冷知识和故事
- flash的衰败与乔布斯的决定
flash曾经凭借其以极小体量（几百KB~几MB）所能提供的在当时极为精致的矢量图形的能力和免费、安装便利的特点盛极一时，遍布于几乎所有网页之上。然而flash却在其最辉煌的时候迅速没落了。
给风头正盛的flash当头一棒的是当时才刚刚起步的苹果。在乔布斯决定所有苹果相关产品均不会支持flash后，几乎所有人都对这个决定表示不认可，而作为flash技术的持有者，Adobe更是称苹果此举是“反竞争”，而后者回应称“flash会带来性能和安全上的噩梦”。之后乔布斯在2010年4月罕见地发布了一篇名为《关于Flash的说明》的1500字长文一一反驳了Adobe的论点，解释了为什么iPhone永远不会支持flash。而至于乔布斯强烈拒绝flash的真实原因，则是Adobe在先前苹果关于flash的询问中态度敷衍，未能给出令人信服的其能够解决flash安全问题的凭据。最终iPhone的成功宣布乔布斯赢得了这场与Adobe的论战。很快安卓也放弃了支持flash，自此，在web上红红火火的flash再无可能进军移动端。
而之后flash爆出的重大安全漏洞成为了压断骆驼的最后一根稻草，chrome，火狐等浏览器相继放弃flash，连那些依靠flash起家的软件如facebook、twitter也开始使用html5作为替代，flash迅速成为了时代的眼泪。
四、源程序版本管理软件和项目管理软件
- Git
- 优点：开源且使用人数众多，开源项目可以免费托管，在GitHub，用户可以十分轻易地找到海量的开源代码。作为一个分布式的版本控制系统，可以方便灵活的进行版本管理和修改，有效支持多人编辑版本。
- 缺点：上手有一定难度
- Mercurial
- 优点：Mercurial的文件对于新手来说相对完整与容易阅读，易于上手。Mercurial是使用Python开发，在Windows下执行流畅。资料库易于维护。
- 缺点：与Git相比功能性有所不足
- Trac
- 优点：有良好的扩充性，权限体系设计比较完备
- 缺点：不支持多项目，需求和缺陷没有分离，中文本地化做的不好
- Bugzilla
- 优点：免费且中文支持良好
- 缺点：只能管理缺陷
五、软件使用实践
- SVN
之前在做项目时使用过SVN，对其了解还算全面。SVN拥有用户界面，用起来比较方便，上手也很简单。但是SVN的功能非常不灵活，比如当在你提交的内容与当前的版本冲突了的时候你得一个一个文件确认冲突，非常麻烦。对于文件很多的项目来说是致命的，一个一个去确认还不如保存修改更新版本后在修改上去来的快。总的来说SVN将一些常用的功能进行了易用化，但无法满足过多的需求。
- git
由于之前课程普遍都要求使用git，所以我对git接触的时间比较久，git的功能很强大，而且由于开源的原因资源也很丰富，git的主要问题是比起它的用户界面，命令行使用起来明显更加方便，但这也就导致了上手难度很高，有许多的命令需要去记。
