| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 作业要求 |
| 我在这个课程的目标是 | 提高自己工程能力和团队写作能力，能成为一名有一定经验的软件开发人员 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，初步认识软件工程 |
快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上
问题1 单元测试一定要有最熟悉代码的人(程序的作者)来写吗
在教材2.1.2好的单元测试的标准一节中，作者认为单元测试一定要有最熟悉代码的人即程序的作者来写。可我对此感到疑惑，诚然，最熟悉代码的肯定是写代码的这个人，但是根据我上面向对象课程和打比赛时的经验，你的代码是按照你的思路来完成的，你的测试能保证你的思路被很好的实现了，但是并不能保证你的思路是正确的或者说完备的。你的思路以及按照这个思路实现的代码可能仍有一些你自己都没有想到的漏洞，一些在设计时欠缺的考虑就容易被忽略。这个时候由别人，也能起到一个模拟各种奇奇怪怪的用户的效果，来写一些单元测试会不会更好呢？毕竟以前debug的时候队友还是帮我发现过不少盲点。
问题2 我们是否应该使用goto
在教材4.3代码设计规范一节中，作者提到函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰题现，什么方法都可以使用，包括goto。在我的印象中，所有的老师和同学给我说的都是不要使用goto，因为我觉得它会扰乱我的代码逻辑，而我到现在也确实没有使用过，作者这句话引起了我的思考，于是去查阅了相关资料。
1968年，E·W·代克斯特拉首先提出goto语句是有害的论点，向传统程序设计方法提出了挑战。主张从高级程序语言中去掉goto语句的人认为，goto语句是对程序结构影响最大的一种有害的语句，他们的主要理由是：goto语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。去掉goto语句后，可直接从程序结构上反映程序运行的过程。这样，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。持反对意见的人认为，goto语句使用起来比较灵活，而且有些情形能提高程序的效率。若完全删去goto语句，有些情形反而会使程序过于复杂，增加一些不必要的计算量。
我认为，不加限制的滥用goto语句势必会导致程序逻辑不清晰，它是一个无条件的跳转语句，可能会导致难以查错。但是像作者说的情景，保证函数只有一个出口，此时使用goto并不会导致逻辑混乱，反而会更清晰，你所有的goto都指向函数的唯一出口，一看就明白什么意思。
经过思考后，我赞同作者的观点，只要有助于程序逻辑的清晰题现，什么方法都可以使用，反驳goto的理由是认为它会导致逻辑混乱，但是只要我们用的好，避免了这个问题，为什么不能使用呢？我想老师可能是因为怕同学们作为写代码的新手滥用goto给自己带来麻烦才推荐我们不使用它的吧。
问题3 为什么要进行结对编程？
教材4.5节中提到了结对编程，在结对编程模式下，一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。但是这也给我带来很多疑惑，两个人写一份代码怎么才能像作者说的取得更高的投入产出比呢？我个人感觉投入更多产出更少了。如果不喜欢被盯着工作会不会影响效率呢？如果领航员在领航时划水效率不就更低了吗？
作者说在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。那么我让水平较高的那一位做不就好了吗？这样结对编程看起来更像是给人表演自己写代码。假设(A)和(B)结对编程，(A)水平更高，他写代码的时候需要(B)领航吗，(B)能起到领航的作用吗？(B)写代码的时候会不会出现理解不了(A)想表达的一些意思的情况呢？如果两个人水平差不多，我们分开写两份代码不会产出更多吗？
从我个人的经历来讲，有时候比赛时写代码对某部分代码没有太多把握我会让队友看着我写，但是更多时候我们约定好变量名，函数名之类的，然后各自写一部分。不过我想有这么多成功的结对编程案例也一定有他的道理，在开始结对编程之后一定会有新的体会。
问题4 要成为领域的专家才能进行创新吗？
在教材16.1.5节中，作者提出了这个迷思。统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外的。，之后他举例HTTP和阿里巴巴的诞生来佐证他的观点。
我不是很同意这个观点，你如果对一个领域没有一定的了解怎么可能做出创新呢？就说马云，1994年和来自西雅图的外教比尔让他决定开始寻找机会创业，1995年年初在比尔的带领下去西雅图第一个ISP公司VBN参观。1995年4月成立了第一家物联网公司，一路波折到了1999年3月开始开发阿里巴巴。这一段时间他难道没有做相关准备吗，难道能说没有学习相关知识吗？要是都没有一定程度的了解我想他不可能把阿里巴巴做得这么好。举个更现实的例子，Invest AB副总裁蔡崇信听说阿里巴巴后，飞赴杭州洽谈投资，在和马云谈了4天后，决定辞职加入阿里巴巴，要是马云没有一定水平能吸引到这种程度的人才？答案显然是否定的。
我想那些所谓拿手领域之外，是没有本行那么擅长，但是和本行有一定关系的领域，他们有一定程序的了解，但是没有行业内的专家了解的深，从而思维会比较容易发散一点，少一些惯性，可以从一些不同的角度来看问题，从而比较容易做出一些创新，正所谓当局者迷，旁观者清吧。
问题5 如何衡量一个人在团队中的绩效？
教材17.4节讲了衡量绩效的问题，这是个很现实也很难的问题。在上一学期，有很多门课程都是需要组队完成一个大作业，既然有组队就势必会有一个得分分配的问题，索性的事我在的小组大家分工都比较明确，而且对自己最终的成绩都很满意。但是以后团队的人只会更多，怎样分配才能尽可能的让更多人满意呢？作者举得几个例子都有各种各样的问题，按代码量，重构的怎么算？按行数，那我空行算吗？按工作时间，大家都开始比谁走的更晚了。软件工程这门课是按照第二组团队的例子对于浮动分数，可以通过每个职位对于团队的贡献来添加。队友之间根据各自的贡献给出排序，最后汇总得分。但是队友不一定能很清楚的知道你的贡献，不过我想这个方法在我们这个小团队，最终目的也只是一些分数的情况下还是很不错的。那么以后到了一个大团队中，利益涉及到了你的工资，这个时候怎样衡量绩效才比较好呢？我还不知道答案。
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
Software这个单词最早出现在出版物中是由Richard R. Carhart于1953年8月出版的书籍。2000年，耶鲁法学院的图书管理员Fred Shapiro发表了一封信，这封信揭露了其在对JSTOR的电子档案的搜索中，发现在由美国数学家Tukey于1958年发布的论文"The Teaching of Concrete Mathematics"中，提到了对于单词software的用法。1995年，Paul Niquette声称他在1953年十月最初创造了这个词，虽然他没能找到任何资料支持他的说法。
从邹欣老师的《构建执法：现代软件工程》一书中得知，软件工程的概念是1968年第一次提出的。 在一篇专访Margaret Hamilton的报道中，通过Margaret Hamilton对记者的回答可以知道，“软件工程”一词是他在阿波罗计划期间发明创造出来的。
大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
听起来可能觉得难以置信，第一款数字化电脑游戏从未带来任何利润回报。
现在的视频游戏已经成为了最受瞩目的程序开发成果，然而历史上第一款数字计算机游戏则遭遇巨大失败。第一个电脑游戏出现于1962年，由麻省理工学院的计算机程序员Steve Russell与其团队一同编写，这款名为《太空大战》的游戏耗费了他们近200个小时。该游戏允许两名玩家分别控制两艘飞船，目标是击中并摧毁对方飞船，并且玩家还需要躲避屏幕中代表星球的小白点。如果玩家撞上这些星球，则游戏失败。虽然Russell和他的团队从未在这个游戏获得任何收益，但必须承认如果没有这一突破我们可能永远不会拥有如今蓬勃发展的视频游戏产业。
不过我想这也和当时电脑技术还有限，计算机成本还很高有很大的关系。
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
| Name | Users | Projects | Alexa rank (lower = more popular) |
|---|---|---|---|
| Assembla | Unknown | 526,581+[45] | 23,052 as of 9 September 2019[46] |
| Buddy | Unknown | Unknown | 73,518 as of 9 September 2019[49] |
| CloudForge | Unknown | Unknown | 339,271 as of 9 September 2019[50] |
| Gitea | Unknown | Unknown | 209,697 as of 9 September 2019[51] |
| OW2 Consortium | Unknown | Unknown | 610,052 as of 9 September 2019[66] |
| Rosetta code | Unknown | Unknown | 62,045 as of 9 September 2019[67] |
| SEUL | Unknown | Unknown | 1,268,571 as of 9 September 2019[68] |
| GitHub | 31,000,000[52] | 100,000,000[52] | 65 as of 9 September 2019[53] |
| Bitbucket | 5,000,000[47] | Unknown | 989 as of 9 September 2019[48] |
| Launchpad | 3,965,288[59] | 40,881[60] | 12,344 as of 9 September 2019[61] |
| SourceForge | 3,700,000[69] | 500,000[69] | 407 as of 9 September 2019[70] |
| GitLab | 100,000[54] | 546,000[55][k] | 2,146 as of 9 September 2019[56] |
| GNU Savannah | 93,346[57] | 3,848[57] | 100,244 as of 9 September 2019[58] |
| OSDN | 54,826[62] | 6,294[62] | 8,529 as of 9 September 2019[63] |
| Ourproject.org | 6,353[64] | 1,846[64] | 1,191,954 as of 9 September 2019[65] |
| Name | Users | Projects | Alexa rank (lower = more popular) |
根据wiki百科的数据可以看出，使用最多的是GitHub，其次是Bitbucket，Launchpad，SourceForge，这四个管理软件的用户数量都十分庞大。
Microsoft TFS
优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪等多个功能。
缺点：能应用起来的极少，搭建、维护都比较复杂。
Git
优点：适合分布式开发，强调个体。公共服务器压力和数据量都不会太大。速度快、灵活。任意两个开发者之间可以很容易的解决冲突。
缺点：学习周期相对而言比较长。不符合常规思维。代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
Mercurial
优点：学习门槛较低、部署相对容易。对网络的依赖性更低。
缺点：分支管理不灵活，功能相对较弱。
GitHub
优点：功能设计简洁实用，可用性好；有良好的分支机制；对 Git 版本库提供了完整的协议支持，支持 HTTP 智能协议、Git-daemon、SSH 协议。提供了在线编辑文件的功能
缺点：国内访问速度较慢；对中文不友好；学习曲线陡峭。
Bitbucket
优点：对于小团队使用可以使用无限量的免费存储库，不限容量；功能丰富，专为团队开发设计。
缺点：团队人数有限；系统不够稳定；不如Github受欢迎，功能也不如Github丰富。
Trac
优点：非常灵活，可以随心所欲控制可以和SVN集成。
缺点：功能不够强大，不支持多项目，需求和缺陷没有分离。
Bugzilla
优点：免费开源；有强大的后端数据库支持功能，功能强大。
缺点：界面不友好；本地化不够好。
选择两个源程序/项目管理软件进行实践
git
（图片背景为本次作业）
git用起来确实很方便，但是开始学习的时候也确实有一定的困难。
github
（图片内容为个人项目对应的仓库）
不仅是一个git的网页版平台，还支持pull request，issue等功能，十分的方便，不愧为用户量最大的项目管理平台。