软件工程第一次阅读！

项目	内容
本次做业所属课程	北航软件工程
所属做业	第0次做业
课程目标	尽可能作吧QAQ
做业回报	熟悉构建之法和一些奇怪的冷知识

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

问题1.用户满意度的定义是否欠缺考虑？

1.2.4 用户满意度：用户在使用时发现了软件的不少问题，影响了用户使用软件的效率。

我认为这里的用户满意度不只仅和软件是否实现用户需求、是否高效率运做有关，还和软件是否实现更高层面的需求有关。用户的需求不是固定不变的，一个软件不只仅要面对用户的基本需求，还须要注意用户的发展性需求，甚至能够主动创造需求去教育用户“这才是大家想要的”。而书中对满意度的描述还局限在基本需求这块。

问题2.灵感和激情在团队工做中重不重要？

3.1 团队对我的的指望： 理性地工做：软件开发有不少我的的、感情驱动的因素，可是一个成熟的团队成员必须从事实和数据出发，按照流程，理性地工做。

在软件开发领域也是有不少创造性开发项目的，好比一种业内从未出现过的功能开发，一种全新的游戏开发，我认为事实和数据只能做为软件开发出发点的一部分。一方面软件开发不是一个死板的过程，工程自身也须要成员灵感的碰撞；另外一方面团队成员做为人类个体，灵感和激情不只仅能够保证工做效率，还能够创造出问题一中“发展性需求”的实现。并且不少空白或者接近空白的领域中，事实和数据都是极其有限的，只有具备灵感和感性目标的团队才能更有可能到达目标。

问题3：命名规则是否是有待商榷？

4.2.6 避免过多的描述。例如游戏开发中最后出现的“大boss”，不用写“theFinalBattleMostDangerousBossMaster”，能够直接写boss。

一方面即便namespace在大部分语言中都有运用，可是在项目里面看到“boss”这样过简的描述也容易歧义，另外一方面对于一些无namespace概念的语言来讲确切的命名更是必须的。

问题4.goto真的适合在软件工程中使用吗？

4.3.2 只要有助于程序逻辑的清晰体现，什么方法均可以使用，包括goto。

goto对程序可读性的破坏是一个方面，另外一方面咱们也须要考虑到大部分程序员对goto是很陌生的，甚至大部分人从业至终也没有写过一条goto语句，用goto语句行为自身就不存在“规范”可言。

问题5.结对编程的相互督促是否合理？

4.5.3 结对编程的过程也是一个相互的过程，每一个人的一举一动都在别人的视线以内，全部的想法都要受到对方的评价？

我认为结对编程的督促应该是每过一段时间同步交流一次，以时间刻度来看好比过几分钟交流一次或者观察一次，事无巨细地观察和交流很容易让双方抛出不成熟的见解给对方，这既不利于软件开发地效率，由于双方会空耗时间在大量的突发性想法上，也不利于团队双方的磨合，对于对方的开发风格和实力会产生紊乱和质疑。

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

根据维基百科的介绍Richard R. Carhart最早将工程的概念引入软件领域

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.

--引用自维基百科

3.你们知道了软件和软件工程的起源，请问软件工程发展的过程当中有什么你以为有趣的冷知识和故事？

关于谷歌软件大牛Jeff Dean的冷"知识"

1.The rate at which Jeff Dean produces code jumped by a factor of 40 in late 2000 when he upgraded his keyboard to USB 2.0.
在2000年后段，Jeff码代码的速度忽然激增了40倍，缘由是他把本身的键盘升级到了USB 2.0

2.gcc -O4 emails your code to Jeff Dean for a rewrite.
gcc的-O4优化选项是将你的代码邮件给Jeff重写一下

3.Unsatisfied with constant time, Jeff Dean created the world’s first O(1/n)algorithm.
Jeff对常量的时间复杂度并不知足，因而他创造了世界上第一个O(1/n)的算法。

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

如下图片资料均来源于维基百科

主流的源程序版本管理软件和项目管理软件包括：

使用人数分布状况：

VCS	优势	缺点
Git	适合分布式开发，强调个体。公共服务器压力和数据量都不会太大。速度快、灵活。任意两个开发者之间能够很容易的解决冲突。离线工做。	模式上比SVN更加复杂。代码保密性差，开发者把整个库克隆下来就能够彻底公开全部代码和版本信息。
SVN	对目录的组织的管理更加方便。保证提交操做的完整性。SVN容许一个文件有任意多的可命名属性，功能十分彻底。	不能离线工做。不能恢复到历史版本。提交、更新、浏览历史的速度慢。
Microsoft TFS	任务版上能将需求、项目进度尽收眼底。能有效实现 SCRUM，能与 VS 无缝接合。	搭建、维护tfs比较复杂，硬件要求也比较高。整个系统是用 asp 实现的，用浏览器访问较慢。
Mercurial	能够一键彻底恢复到历史版本的某一个切面。hg的版本库不须要维护。封装好。相比git，hg不多暴露一些实现内的细节。	分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。