软件工程个人博客作业

项目	内容
本作业属于北航软件工程课程	2020春季计算机学院软件工程（罗杰任建）
本作业的要求请点击链接查看	2020BUAA软件工程个人博客作业
我在这个课程的目标	提高自身的代码能力、学习团队协作开发的过程
本作业帮助我实现目标的具体方面	通过阅读教材了解软件工程的概念；了解源程序版本控制软件的使用方法

1.关于教材提出问题

问题一

教材的1.1章节客观地描述了软件工程中包括的各种内容：

1.1 软件=程序+软件工程

上面这些和软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关的内容，是软件工程的核心部分。广义上的软件工程也包括用户体验、用户界面设计（User Interface Design）等。所以，一个推论是：软件 = 程序 + 软件工程，一个扩展的推论是：软件企业 = 软件 + 商业模式当然，软件企业还需要各方面的支持工作，例如人员的招聘、绩效评估、升迁、淘汰等人力资源方面的工作。弄清楚这些概念，是进行所有与程序、软件、企业等相关的讨论的基础。回到本节开头的疑惑，答案就很清楚了，程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。

很显然，以上这些环节都是必不可少的，它们的技术难度有高有低，在实际的软件应用开发中薪资也有高有低。那么这些环节之间，哪个能对软件最终呈现的效果产生最大的影响？在学校中同学们都将学好程序技术作为第一目标，那是否在技术的基础上对软件工程掌握得越好就能开发出更好的软件？技术人员的重要性（地位）是否高于其他环节的工作人员？

问题二

教材的2.1.2章节在描述单元测试时这样写道：

2.1.2 好的单元测试的标准

单元测试要测试API中的每一个方法及每一个参数。单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

但是，根据我们的实际编程经验，发生的许多程序错误都是因为位于逻辑的死角，自己难以找到。在面向对象课程设计上我们也曾经学过测试方面的知识，就我当时的直观感受来说，这样仅仅是在测试已经考虑到的方面实现是否正确，对发现还未考虑到的方面没有太大的帮助。

在2.1章节的开头也这样写道：

2.1 单元测试

软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试就是一个很有效的解决方案。

就我的理解来说，单元测试是一个对自己所写模块负责任的过程，是一个明确和细化模块功能与定义的过程，主要是为了服务于软件工程团队协作的要求。这应该是为了实现在程序“逻辑性正确”之上的更高层次的要求，与我们平时泛泛而论的“debug”的目的并不完全相同。但我并不确定这样的理解是否正确。

问题三

教材在2.3章节的结尾提出了这样的一个问题：

2.3 个人开发流程

工程师有可能很高效地开发出一个顾客不喜欢的软件（例如用户界面很差，功能未能解决用户实际问题，等等），那么这位工程师还是一个优秀的工程师么？

我想尝试回答一下这个问题：我认为顾客对产品的评价不能代表工程师的水平。对工程师个人能力的评价和对团队能力的评价不能混为一谈。教材中提到了对个人开发过程进行评价的模型——PSP和能力成熟度模型（CMM和CMMI）软件能力成熟度模型，在后者中即纳入了包括需求管理在内的涉及软件项目管理控制方面的内容。

教材在3.1章节中这样写道：

3.1 个人能力的衡量与发展

在团队工作中，稳定、一致的交付时间是衡量一个员工能力的重要方面。软件项目的确需要创造性，需要一些意外，一些惊喜。但是，更多的是常规的、可重复的任务，软件工程的奠基人之一瓦茨·汉弗雷总结说，软件领域可以分为两个方面：一方面是技艺创新的大爆发；而另一方面是坚持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90%—95% 的比例。对于这些任务，一个成熟的软件工程师应该能够降低任务交付时间的标准方差。

结合以上内容，是否可以如此概括：工程师实现需求的效率和稳定性就是评价工程师能力的指标？

除此之外，我还想知道，这样的评价指标在实际工业界中推广和执行的程度如何？如何量化？

问题四

技能的反面是什么？教材在3.3章节中这样写道：

3.3 技能的反面

计算机人机交互领域的科学家比尔·巴克斯顿（BillBuxton）在1995年的一篇文章中提到了“The Op-posite of Skill”[注释10]： Before reading on, think for a moment, and tell me what is the opposite of skill? I'll even give you a hint： I'm not looking for "unskilled". 巴克斯顿说技能的反面是“Problem Solving”—“解决问题”，

就我对文本的理解来说，作者认为“解决问题”指的是“解决低层次的问题”，如果一个人需要不断去解决低层次的问题，那么这说明他对低层次的问题掌握并不熟练。只有一个人当将所有的低层次问题都不再当成问题，都变成自然而然的操作、都不再需要“解决”的过程，才能称为是掌握了技能。

我的问题是：什么样的问题能被称为是“低层次”的问题？计算机技术飞速发展，新技术层出不穷，一个人不可能完整地掌握所有技术，不可能掌握所有新技术中的“基础”部分。面对新技术，无论怎样的“高手”都要经历一个学习的过程。那么面对一个问题，如何找到它在书中讲述的“问题的层次”中的位置。

问题五

正如教材在16.1章节中所说：我们的社会、教育都崇尚“创新”，对此他提出并讨论了几点迷思：

16.1 创新的迷思

16.1.1 迷思之一：聪明人的顿悟

这些故事很有意思，但是它们没有提到这些科学巨人在顿悟之前已经在相关学科打下了深厚的基础，同时他们也为这些问题进行了长时间的思考，那些看似神奇的时刻才会光顾他们。

不要一开始就想着找到并拼对所有的拼图块，以为能够打造一个巨大的创新。

16.1.2 迷思之二：大家都喜欢创新

一类创新是改良式的，但是，有些创新是颠覆式的，这些想法一旦出现，便会引起现有技术拥有者的极大不安

创新的想法一开始往往不被接受，而那些建立在前人基础上的“线性扩展”则往往有着更好的命运。

16.1.3 迷思之三：好的想法会赢

和行动相关的各个方面都在考虑：我能从中得到什么？（WIIFM）这个问题没有搞清楚，那再多的好想法都只会停留在口头。

16.1.4 迷思之四：创新者都是一马当先

其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。又如Apple的音乐播放器iPod，发布于2001年10月23日，在它之前市面上已经有很多同类产品了

作者的的确确从各种新颖的角度讨论了“创新”的本质。创新可以是领域专家长年思考积累之后的“顿悟”，也可以是一个人在他的非专业领域之外获得的成就。许多成功的创新产品不一定是真正的始创者，也可能是在一个新领域逐渐发展过程中脱颖而出的后来居上者。从这些方面看，创新其实并不是仅仅是“新”的问题，而是一个牵涉了方方面面的更复杂的问题。那么该如何衡量“创新”的成果呢？创新可以是技术上的发明创造，可以是科研的新成果，也可以是新应用、新需求的发掘。我们可以衡量它的直接创造的商业价值，也可以衡量它在历史上对后世产生的启发与影响。这些评价都应该就事论事、用统一的标准衡量在某个具体方面的影响大小。书中这样叙写未免有些故弄玄虚。

16.1.6 迷思之六：技术的创新是关键

大众通常把科研和创新等同起来，这也是不准确的。以发明即时贴（Post-It）闻名世界的3M公司的杰弗里·尼科尔森（Geoffrey Nicholson）对两者做了明确的区分，他认为“科研是将金钱转换为知识的过程”，而“创新则是将知识转换为金钱的过程”

科研当然不完全等同于创新，但若如上段文字所说，在16.1.1章节中阿基米德、牛顿发现新的科学规律，这算是科研还是算是创新呢？

2.“软件”和“软件工程”这些词汇是如何出现的？

软件

1953年 Richard R.Carhart 在研究备忘录中首次使用软件一词。

软件工程

Margaret Hamilton（美国著名女计算机科学家）在阿波罗计划项目中首次提到这个概念。
1968年，NATO在联邦德国举行的关于软件开发的会议上，首次提出了软件工程的术语，标志着软件工程作为一门学科的正式出现，至今已有40年的历史。

3.软工发展史上的冷知识

史上第一款电脑病毒，竟然是由防御技术专家Fred Cohen亲手设计出来的。

他创造电脑病毒的目的仅仅是为了证明程序对电脑感染的可行性，从未希望借此对电脑造成任何危害。但这款程序却能够对电脑进行感染，并且能通过软盘等移动介质在不同计算机之间进行传播，因而命名为病毒。后来，他又创造出一种主动式电脑病毒，主要目的是帮助电脑用户找到未受感染可执行文件。

来源：知乎

4.目前流行的源程序版本管理软件和项目管理软件的优缺点比较

各种工具优缺点比较

工具名称	工具介绍	优点	缺点
Microsoft TFS（Azure DevOps Server）	为 Microsoft 产品提供源代码管理、数据收集、报告和项目跟踪，而为协作软件开发的项目	任务版上能将需求、项目进度一览无余能有效实现SCRUM 能与VS无缝接合	搭建和维护比较复杂硬件要求比较高整个系统用asp实现，用浏览器访问相当慢
Git	一个开源的分布式版本控制系统	适合分布式开发，强调个体公共服务器压力和数据量都不会太大速度快、灵活任意两个开发者之间可以很容易地解决冲突离线工作	学习周期相对较长不符合常规思维代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息
Mercurial	一款由python编写的轻量级分布式版本控制系统	学习门槛较低，整体上比Git需要掌握的命令少可以一键完全恢复到历史版本的某一个切面封装较好，很少暴露实现内的细节版本库不需要维护	分支管理不灵活，不适合大型团队
GitHub	可以托管各种git库，并提供一个web界面	免费且开源相对于Git学习难度较低从另外一个项目进行分支非常简易	学习成本高，需要投入大量时间 Git版本库需要频繁的手动维护只能创建开源项目，私有仓库要收费
Bitbucket	Atlassian公司提供的一个采用Mercurial和Git作为分布式版本控制系统的基于web的版本库托管服务	支持私有免费项目，版本库数量不限可以与Atlassian的其他产品相集成	开源项目较少