【软件工程】个人博客作业
| 项目 | 内容 |
|---|---|
| 课程 | 2020春季计算机学院软件工程(罗杰 任建) |
| 作业要求 | 个人博客作业要求 |
| 我的课程目标 | 章握软件开发的方法论和诸多技术，与同学合作开发出好的软件 |
| 本次作业的作用 | 速读教材，带着问题开启接下来的学习。了解项目管理软件。 |
· 问题：单元测试的编写者
在2章中，作者认为，单元测试必须由程序的作者来写，理由是：
代码的作者最了解代码的目的、特点和实现的局限性。
但在相对复杂的单元中，有些bug是由于作者本身在机制上忽略了一些情况而导致的。此时，作者在编写单元测试时很可能由于既有的思维而编写“自认为覆盖全面的测试”，而他所认为的”全面“恰恰缺少了某些情况。之前的面向对象课就有发生过经过自己详细的测试后被同学的样例测出bug的情况，后来才意识到是思维上的漏洞。是否在明确定义单元代码功能后由各位成员一起编写测试用例进行黑盒测试，或者专门针对复杂模块编写样例生成器，用海量样例暴力测试更有利于全面地找出bug？
· 问题：goto&异常处理
在之前的学习中，goto一直被认为是有害的，应避免使用。但在书中4.3.2节的例子中，Goto的确通过将一些分支引向函数出口从而简洁地保证了函数出口的单一性。是否可以说，使用goto时应保证其跳转到本单元内？另外，在本例中为了使函数出口单一而将异常在函数内部处理。但在之前的学习中，我们被鼓励自建异常处理类，发生异常时将其实例化后抛出。请问异常处理是否有统一的方式？在什么情况下需要保证函数的单一出口而在内部解决异常处理？
HERSULT HrDoSomething(int parameter)
{
//parameter check and initialization
//processing part 1
If (SomeCode() != ok)
{
//set HR value
GOto Error;
}
//processing part 2
If (SomeCode() != ok)
{
//set HR value
Goto Error;
}
Error:
//clean up free resource, reset stat, etc
return hr;
}
*from《构建之法》代码清单4-2
· 问题：why agile？
书中表6-3已经给出了各种软件开发方法的适用条件。我想了解的是，如今敏捷开发是否仍然是一种非常主流的软件开发方法，以及有什么著名项目是通过这种方式开发的呢？
· 问题：Sprint过程中需求的变化
书中第6章描述在Sprint过程中团队专注于满足根据需求制定好的计划，在此期间不响应需求的变化。图6-5给出的一个例子中，Sprint可以持续一个多月的时间。是否在Sprint开始前需要和客户沟通好这个开发模式以约束其在Sprint过程中不变更需求扰乱Sprint的过程？
· 问题：创新的迷思
第16章中，作者描绘出时兴的创新氛围：
媒体上充斥着创新型的人才、创新型的学校、创新型的公司、创新型的城市、创新型的社会等名词。有些城市还把“创新”当作城市的精神之一，还有城市要批量成产上千名顶级创新人才。IT行业也充斥了很多创新的新闻和掌故。
而后披露了一些关于创新的似是而非的观点，指出“并非所有人都喜欢创新”，“好的想法未必赢”，“成功的团队未必靠创新”等。请问该如何看待这种矛盾的现象？对此我们该如何调整心态？这对于我们的软件开发有何启示？
二、请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
· Software
根据维基百科词条，John Tukey在1958年的“The Teaching of Concrete Mathematics”一文中最先使用“software”这个词。1995年Paul Niquette声称他发明了这个词，然而并没有依据。而软件这个词最早在工程语境中出现是在1953年兰德公司（RAND Corp.）的工作便签中。
· Software Engineering
“软件工程”的概念是1968年第一次提出来的。
——《构建之法》P4
按章后的引用，找到了NATO的1968年报告SOFTWARE ENGINEERING，其中记载：
In late 1967 the Study Group recommended the holding of a working conference on Software Engineering. The phrase ‘software engineering’ was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.
“软件工程”的提出被用来促进一种“软件制造需要吸收传统工程的特点，基于严谨的理论基础和实用性原则”的认识。这应该是“软件工程”第一次在国际大会上得到承认，而“软件工程”的提出可以追溯到1965年Margaret Hamilton在Apollo计划的实践中提出的概念：
The concepts developed became the building blocks for modern "software engineering", a term coined by Ms. Hamilton, and immediately found use beyond Apollo on Skylab and Shuttle.
——The NASA Heritage Of Creativity
（神似TBBT中的Amy Farrah Fowler）
三、软工冷知识——Let It Crash
程序崩溃（Crash）很多时候是我们所尽力避免的。听说在上届的面向对象课中，如果你没有接住异常而使程序崩溃，难么你会被“恭喜得到0分”。然而这却是Erlang的编程哲学之一。Let it Crash告诉我们不要让程序“带病运行”，而是尽管让其崩溃——然后解决bug。当然，我们很难想象Margaret Hamilton会认同这种哲学。但可以说，只要能保证系统能快速崩溃（fail fast）并快速恢复（recover fast），我们仍然可以乐观地看待它。
四、流行的源程序版本管理软件和项目管理软件的优缺点及用户数量调查
· Microsoft TFS
优点：由数据库存储源码，性能较高；与开发工具集成度高；源码管理无存储限制。
缺点：搭建、维护复杂；对硬件的要求较高。
· Git
优点：分支能力强大；支持离线提交；分布式推送拉取。
缺点：子模块管理不完善，多repo继承困难。
· GihHub
优点：基于web的版本管理；对Markdown有着很好的支持。
缺点：不易学，入门较慢。
· Bitbucket
优点：免费支持私有仓库；同时支持hg/git；
· Trac
优点：权限体系完备。
缺点：不支持多项目；中文化不完整。
· Bugzilla
优点：不收费；中文版支持。
缺点：只能管理缺陷。
· Apple XCode
&emsp优点：编译速度快；原生支持撤销、重做和保存功能。
缺点：版本更新后时常导致插件失效。
· 用户数比较
| 名称 | 用户数量 |
|---|---|
| GitHub | 31,000,000 |
| Bitbuket | 5,000,000 |
| Launchpad | 3,965,288 |
| SourceForge | 3,700,000 |
| GitLab | 100,000 |
五、源程序版本管理软件实践
对比Git和Mercurial两种版本管理软件的简单版本控制过程——创建一个文件，然后将其删除。
· Git
· Mercurial
可以看到，它们最基本的版本控制流程都是：修改文件->添加至暂存区->提交形成本地版本。二者使用皆比较顺畅，且可以用过log中的历史版本信息回退至任意版本。基本不需担心误删的情况。
