<tbody>
<tr>
<td>这个作业属于哪个课程</td>
<td><a href ="https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ">https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ</a></td>
</tr>
<tr>
<td>这个作业的要求在哪里</td>
<td><a href ="https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/2625">https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/2625</a></td>
</tr>
<tr>
<td>我在这个课程的目标是</td>
<td>熟悉软件工程，锻炼自己的能力</td>
</tr>
<tr>
<td>这个作业在哪个具体方面帮助我实现目标</td>
<td>看完《构建之法》，更有助于加深对软工的理解</td>
</tr>
</tbody>
| 项目 | 内容 |
|---|
一、快速看完整部教材，列出你仍然不懂的5到10个问题
1.1 第四章 结对编程适合于所有项目吗？
在结对编程的模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排地坐在一台电脑前，面对同一个显示器，使用过同一个键盘、同一个鼠标一起工作。
初次看到这里的时候其实就已经有了疑问：在这样的情况下，那写代码的效率是不是特别低呢？于是我又接着往下看。书的后面给我解释了一开始的疑问，在结对编程中，因为随时有复审和交流，所以写出来的代码的质量会高很多。但是我的另一个疑问又来了，虽然代码的质量高，项目有难易之分，一个不算复杂的项目让两个人结对编程（相当于减少一个人的工作量）合算吗？或者说，结对编程不适合的项目如何又有什么新方法来改进其缺点呢？
1.2 第四章 代码规范
代码设计规范。牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。
看到代码规范的时候我就想起了困扰了我很久的问题，是我好久以前在博客上看到的观点，就是在头文件里定义全局变量是很业余的行为，所以我想问一下，这是否是真的业余呢？或者说，如何避免使用全局变量呢？
1.3 第四章 goto语句的使用
第四章4.3代码设计规范部分谈到goto语句的时候，说为了达到使函数有单一出口的目的，可以使用goto。但自从我开始学习c语言来，就听说了很多“goto”无用论以及很多老师都反对我们用goto，所以我不认同书中此处的说法。
1.4 第五章 团队开发的模式
团队开发的模式有：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。
如上引用，团队开发的模式有如此之多，而且不同的模式适合不同的项目。既然有这么多模式存在，也就是说我们在开始一个项目之前，都需要根据我们的项目首先选择适合自己的模式吗？还是说团队开发模式只是一个抽象概念，用于后续的总结而不需要在开发前选择。
1.5 第九章 项目经理的作用是不是被夸大了？
第九章主要讲述了PM的职责以及其重要性。但是综合来讲，PM既不懂开发也不懂测试，而对一个项目来说，开发和测试才是最重要的，也就是说PM在其中或许只是一个穿针引线的作用？我们是不是夸大了他的重要性？
1.6 第十六章 创新和构思
在“现代软件工程”课上，许多同学也提出了不少宏大的创新想法，但是到了课程结束后时，什么也没做成，只剩下一个空的构想。
其实我读到这里的时候在想，为什么这些宏大的创新想法没有被付诸实践呢？是老师没有鼎力支持还说学生自己没有持之以恒，或者是因为学生自己的想法太天方夜谭？
1.7 第十六章 是选择冒险还是从众呢
迷思之八：创新者就是冒险家
现在计算机方向很火的就是机器学习，在实验室可以选择利用前人的一些现成的研究来进行新的研究（也就是调用现成的包来进行实际应用），也可以选择进行一些基层的研究（机器学习更深层的理论），前者更容易出成果，毕竟很多结论都是现成的，意味着不用走弯路，后者的话相比之下不容易出成果，但是如果长期进行该方向的研究的话应该是有帮助的，所以应该如何选择呢？
二、请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
- “软件”是由图灵在1935年提出的。但是博客给出的链接中提到人们认为“软件”第一次正式提出是在John Turkey的论文中。
- “软件工程”是1968 年北大西洋公约组织在前联邦德国开会提出的。
三、请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
现在的视频游戏已经成为了最受瞩目的程序开发成果，然而历史上第一款数字计算机游戏则遭遇巨大失败。第一个电脑游戏出现于1962年，由麻省理工学院的计算机程序员Steve Russell与其团队一同编写，这款名为《太空大战》的游戏耗费了他们近200个小时。该游戏允许两名玩家分别控制两艘飞船，目标是击中并摧毁对方飞船，并且玩家还需要躲避屏幕中代表星球的小白点。如果玩家撞上这些星球，则游戏失败。虽然Russell和他的团队从未在这个游戏说的任何收益，但必须承认如果没有这一突破我们可能永远不会拥有如今蓬勃发展的视频游戏产业。
图像处理算法中使用最广的一幅图片来自《花花公子》杂志，40年来，这幅被应用为图像处理方案中的泛用性标准测试素材，还被程序员们亲切称为Lena的图片。但大多数人都不知道，它是来自《花花公子》杂志1972年11月刊的插页。
四、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
Microsoft TFS:
- 优点：是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。
- 缺点：能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。
Git(Github、Gitlab)：
- 优点：GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
- 缺点：可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
- 用户数量：31,000,000(GitHub) + 100,000(GitLab)
Mercurial:
- 优点：有reset，扩展性，append only的存储结构
Bitbucket：
- 优点：支持 git 和 hg； 支持私有。
- 缺点：开源项目不多
- 用户数量：5,000,000
Trac：
- 优点：Trac做一个SCM配置管理平台，意味着它有良好的扩充性
Trac的权限体系是比较完备的设计
非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。 - 缺点：不支持多项目，
需求和缺陷没有分离，
用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，
中文化不完整，美术人员接触起来困难重重，
不显示中文名，本地化做得很差，
核心功能很少，不安装插件基本上没法用。
Bugzilla:
- 优点：BUGZILLA不收费,
BUGZILLA现在有中文版支持 - 缺点：BUGZILLA只能管理缺陷
Apple Xcode:
- 优点：可以自动创建分类图表。
自动提供撤消、重做和保存功能，无需编写任何编码。 - 缺点：更新版本后，某个插件可能会失效。