北航软工个人博客作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 学习软件工程相关知识，提高自己团队项目的开发能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，加深对软件工程的理解，为接下来的进一步学习做好准备 |
快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上。
问题一：单元测试是否只能由程序的作者进行编写？
教材2.1.2中作者对于单元测试有下列论述：
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
诚然，没有比作者本人更了解代码的人，由作者写单元测试程序在效率上可能确实更高，但根据我的经验，单元测试的质量可能会有所下降。我自己在写代码时，常常会有一种思维定式，往往很难发现程序中的固有bug，而是要通过讨论以及与大家共同交流测试样例才能找出bug所在。如果完全由作者本人进行单元测试的书写，我认为很可能会陷入和我一样的困境，自己程序的正确样例会反复测试，而错误样例却一直很难发现，在这种情况下，由他人或者多人一起书写单元测试，集思广益，难道不是更高效且更具质量的做法吗?
问题二：只要助于程序逻辑的清晰体现，什么方法都可以使用？
在4.3.2中，作者有如下论述：
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
goto语句一直是人们争论的焦点，1974年，D·E·克努斯对于GOTO语句争论作了全面公正的评述，其基本观点是：不加限制地使用GOTO语句，特别是使用往回跳的GOTO语句，会使程序结构难于理解，在这种情形，应尽量避免使用GOTO语句。我深以为然，goto语句虽然功能强大，但会使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。去掉GOTO语句后，可直接从程序结构上反映程序运行的过程。这样，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。如果单纯为了书写时的逻辑体现而滥用goto，从而造成代码可阅读性的下降以及其他隐藏危害，我认为是得不偿失的。
问题三：关于结对编程方式的疑惑
作者在4.5.2中有如下论述：
在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等。
结对编程自然有很多好处，两人相互鼓励，相互监督，不容易偷懒，但我认为其也并不是没有害处的。根据我的经验，一个水平高的程序员和一个水平低的程序员一起编程的话，往往水平高的程序员会做更多的工作，在这种情况下，水平低的程序员可能不但无法贡献出自己的思想精力，还可能会拖整个项目的后腿，更别提作者在书中所描述的这种方式了，两个人共用同一个鼠标，同一个显示器，我认为这种结对编程的方式实在是太过于理想化且不现实。在我的理解中，结对的两人分开工作，可以定期进行交流讨论，在自己的空间中最大限度的发挥自己的才智，这才是结对编程的正确打开方式。
问题四：关于程序员和项目经理的交流
在第九章中，作者论述到项目经理最大最独特的贡献是带领团队达成最重要的目标，并保持团队平衡，但根据我的经验，实际情况可能会更加复杂。作为程序员，如何清楚的向项目经理表述自己的想法与能力？尤其是意见遇到分歧时，应该以什么作为优先考虑目标？如果项目经理制定了错误的或者是不切实际的目标，我作为程序员除了只顾编写自己的代码还有更好的解决方式吗？
问题五：作为软件开发公司如何平衡所谓的bug与改进空间
在第16章中，作者有这样的论述：当一个产品要发布的时候，通常都留有一些已知的bug而不去改。一方面原因是产品要即时发布才能有盈利，另一个原因是为下一阶段的产品迭代留有余地，团队会更有干劲。但是如何保证自己的bug不会对用户的体验造成影响呢？留什么bug才能最大限度的留住用户同时激励团队的开发干劲呢？
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件(Software)
“软件”这一词汇最早在1953年8月由Richard R.Carhart在RAND Corporation的研究备忘录中提出。2000年，耶鲁法学院图书管理员Fred Shapiro发表的信表明，在1958年由美国数学家John Tukey发布的论文"The Teaching of Concrete Mathematics"中，提到了对于单词“software”的用法。
软件工程(Software Engineering)
由NASA工程师Margaret Hamilton在阿波罗计划项目组中提出了。当时，软件不像硬件那样受到重视，大多数人把它看做魔术而不是科学，因此，Margaret Hamilton开始使用“软件工程”一词来为软件以及相关发明者争取应有的正统性与尊重。
参考资料
大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
- Google当初是因为拼错才会叫Google，原先的名字是Googol。
- Google的Chrome浏览器在断网的时候藏了一个小游戏——恐龙跑酷，这应该很多人都知道。游戏的控制方式则非常简单：电脑按一下空格键开始游戏，空格起跳，键盘上的下箭头则能让他蹲下，而使用移动设备的话，点一下那只龙就能开始游戏了。
Google在一次对开发者的采访中解释了游戏的起源：据设计师Sebastien Gabriel说，这个游戏的意思是了“断网”就像是回到了“史前时代”。当然，那时候还没有无处不在的互联网。虽然对于现在的年轻人来说，断网可能是件非常罕见的事情，但是回到从前，人们可都只是在特定的地点才能连上网的。这些地点可能包括了家里、学校、公司或者——“网吧”，那时候可是个生意兴隆的买卖。Chrome中的这个恐龙游戏代号“Project Bolan”，来自于1970年代的摇滚乐队T-Rex(霸王龙)，当时乐队的某任主唱叫做Marc Bolan。该游戏最早出现在2014年9月Chrome中。开发者们还夸下海口，说这个游戏能玩到海枯石烂。工程师Edward Jung说：“我们把游戏的长度设成了大约1700万年，大概就是霸王龙在地球上存活的时长，不过恐怕你的空格键存活不了那么久。”
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）。
流行指数
优缺点
Microsoft TFS
优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。
缺点：搭建、维护tfs比较复杂，硬件要求也比较高。
Trac
优点：Trac作为一个SCM配置管理平台，意味着它有良好的扩充性，Trac的权限体系是比较完备的设计，非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
缺点：不支持多项目，需求和缺陷没有分离，用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，中文化不完整，美术人员接触起来困难重重，不显示中文名，本地化做得很差，核心功能很少，不安装插件基本上没法用。
BUGZILLA
优点：BUGZILLA不收费，BUGZILLA现在有中文版支持
缺点：BUGZILLA只能管理缺陷
Apple XCode
优点：可以自动创建分类图表，自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：更新版本后，某个插件可能会失效。
GitHub
优点：免费且开源。用于敏捷高效地处理任何或小或大的项目。Git支持分支功能（branch）。如果你想开发一个新的产品功能，你可以建立一个分支，对这个分支的进行修改，而不至于会影响到主支上的代码。可拿Git做备份系统，或者同步两台机器的文档，很方便。支持离线工作。本地提交可以稍后提交到服务器上，不用和集中的代码管理服务器交互。 只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。Git中的每个工作树都包含一个具有完整项目历史的仓库。简易的初始化。对于随便写两行代码就要放到代码管理工具里的人来说，再合适不过。
缺点：学习成本大。由浅入深的过度很漫长，需要大量时间的投入。Git版本库需要频繁的手动维护。
Mercurial
优点：学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。可以一键完全恢复到历史版本的某一个切面。封装好。相比git，hg很少暴露一些实现内的细节。照顾 svn 的迁移用户。hg 的很多命令是迁移自 svn 命令的，目标其实是为了让 svn 用户更容易接受。这使得已经习惯 svn 命令的团队，几乎零成本的切换到 hg。hg 的 pull 更多的时候可以让你避免创建分支。hg 好比苹果系统，git 好比 Linux，前者在常用命令上更好用更易用，后者在功能上更强大更灵活。hg的版本库不需要维护。
缺点：分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。