读《构建之法》后的所思所想
| 项目 | 内容 |
|---|---|
| 本次作业所属课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 本次作业要求 | 个人博客作业 |
| 我在本课程的目标 | 学习软工的思想方法，写出好的软件并维护 |
| 本次作业的帮助 | 第一次通读《构建之法》，对于软件工程的各方面有了一些认识与感受 |
一.通读全书后的一些问题
1.软件设计思想和软件工程思想是什么？
在书P-45写到，一个初级的软件工程师的成长有一条即使对软件设计思想和软件工程思想的理解。但书中没有明确给出其定义，那么究竟怎么理解这两种思想？
2.何时用goto是好习惯？
函数最好有单一的出口，为了达到这一目的可以使用goto。只要有助于程序逻辑的清洗体现，什么方法都可以使用，包括goto。
-- 《构建之法》P-69
在大一时学习c程序设计时老师建议我们不要使用goto，因为goto会让可读性会变差（一段代码一会儿看上面一会儿看下面是很难受的一件事，虽然机器不在乎，可人受不了）。那么为何还要用goto呢？书下面所举的例子完全可以把这些goto error；替换成 return hr；这样人们在第一次读的时候不用去找error是什么，不是反而提高了可读性？
同时另一个问题就是，函数有单一的出口有什么好处？
3.关于结对编程
结对编程的过程也是一个互相督促的过程，每个人的一举一动都在别人的视线之内，所有的思想都要受到对方的评价。这种督促的压力，使得程序员更认真地工作。
-- 《构建之法》P-81
我不太认可这种压力是一种动力。每个人的思路是不一样的，当我一段时间在当领航员另一段时间在写代码，就会导致有些混乱，我总认为两个人负责同一部分交替写出来的代码会有一些四不像。另一方面，我每写一点队友都会进行监督，就导致每一模块都可能会出现意见分歧，想要讨论出一个最好的写法。然而事实是，很多情况下每一种写法都各有千秋，那么这样的监督反而会降低效率。
因为没有切身试过这种模式，观点可能有些主观，望指正。
4.顾客需要帮助
用户体验是非常重要的一部分，也是很多人评价一个软件是否好用的出发点。正如书上所提，用户需要帮助，但也没有那么笨。当我们第一次使用一个软件时，我们很希望他能给我们一些操作示范让我们能快速上手，而这些帮助多了会让人不耐烦，不停地跳出提醒影响使用的效率，但是少了呢，又会让人无从下手。因此我认为一个适度的帮助是有用的，也是一个好的软件应该具备的。但是我在使用目前大家口碑非常好的git时，我却没有感受到他对新手的帮助，而且很多同学都有一样的感受，在新手阶段非常的难受，很多地方不懂得只能自己百度。然而这却不影响它成为一个优秀的软件。大家对它的评价都不错，这样看来是否只要软件的功能质量够强大，就可以忽略新手用户的不适？
5.软件开发过程的可见性究竟怎么做？
在本书P-304页提到，软件工程的质量体现在几个方面，其中软件开发过程的可见性就是其中之一。软件开发过程的可见性，顾名思义，即在开发过程中可以向他人展示。这样确实可以吸取他人的意见，在开发过程中就更新思想并改进程序。但是我们知道，软件的每一模块其实单独展示出来可能就是个黑色的运行框，当他们合起来时便以一整体示人。可能我们看到某一部分时觉得不理想，但最终的结果确是惊艳的，那么我们作为旁观者，在看别人软件的每一部分时如何从部分看整体来提出有建设性的意见？作为开发者，又该如何展示自己的代码呢？
二.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
1."软件"
"软件"，即”software“，最早在1953年Richard R. Carhart在备忘录中使用software一词。
2."软件工程"
”软件工程“ 1968 年北大西洋公约组织在前联邦德国开会时提出的。1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念。
三.软件工程发展的过程中有什么你觉得有趣的冷知识和故事
1.宰赫兰导弹事件
在1991年2月的第一次海湾战争中，一枚伊拉克发射的飞毛腿导弹准确击中美国在沙地阿拉伯的宰赫兰基地，当场炸死28个美国士兵，炸伤100多人，造成美军海湾战争中唯一一次伤亡超过百人的损失。
在后来的调查中发现，由于一个简单的计算机bug，使基地的爱国者反导弹系统失效，未能在空中拦截飞毛腿导弹。当时，负责防卫该基地的爱国者反导弹系统已经连续工作了100个小时，每工作一个小时，系统内的时钟会有一个微小的毫秒级延迟，这就是这个失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位，因而时间的精度也只限于24位的精度。在长时间的工作后，这个微小的精度误差被渐渐放大。在工作了100小时后，系统时间的延迟是三分之一秒。
对一般人人来说，0.33秒是微不足道的。但是对一个需要跟踪并摧毁一枚空中飞弹的雷达系统来说，这是灾难性的——侯赛因飞毛腿导弹空速达4.2马赫（每秒1.5公里），这个”微不足道的”0.33秒相当于大约600米的误差。在宰赫兰导弹事件中，雷达在空中发现了导弹，但是由于时钟误差没有能够准确地跟踪它，因此基地的反导弹并没有发射。
2.火星气候探测者号的星际迷航
火星气候探测者号在1997年发射，目的为研究火星气候，但是它没有能够达成这项花费3亿多美元的使命。
探测者号在太空中飞行几个月以后，由于导航错误，最终在火星大气层解体。探测器的控制团队使用英制单位来发送导航指令，而探测器的软件系统使用公制来读取指令。这一错误大大改变了导航控制的路径。最后探测器进入过低的火星轨道（大约100公里误差），在过大的火星大气压力和摩擦下解体。
四.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
1.使用人数
| 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] |
-- 引用自维基百科
2.优缺点
| 项目管理软件 | 优点 | 缺点 |
|---|---|---|
| Microsoft TFS | 支持对于同一文件，多个用户并发的去读；高可用；高性能；高可扩展 | 只支持小文件的应用，大文件应用是不支持的；比较占用内存；对用户没有提供POSIX接口 |
| GIT | 适合分布式开发，强调个体；公共服务器压力和数据量都不会太大；速度快、灵活；任意两个开发者之间可以很容易的解决冲突；离线工作。 | 学习周期相对而言比较长；不符合常规思维；代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。 |
| Mercurial | 易于学习，上手很简单；支持windows，在windows系统下仍很流畅；记录不容侵犯 | 功能有些简陋；跨平台性能较差，容易出现编码问题；没有命名空间，容易导致自己代码与别人的混淆；提供多种分支模式，但却各有诸多缺点 |
| GitHub | 功能设计简洁实用上手很快，可用性好；良好的分支机制，可以让主干代码保持干净；Git对程序源代码进行差异化的版本管理，代码库占极少的空间。易于代码的分支化管理。 | 国内访问速度太慢；不能很好的解决GB2312/GBK，对中文不够友好；对于企业开发者需要购买套餐的用户来说，价格过于昂贵 |
| Bitbucket | 私有仓库无限制；功能丰富，专为团队开发设计 | 速度慢；代码闭源 |
| Trac | 有良好的扩充性；权限体系完备；灵活，可随心定制 | 不支持多项目；用 wiki 来替代 Word 等工具编写文档入手难度大；不显示中文名，对中文不友好；核心功能很少，不安装插件基本上没法用。 |
| Bugzilla | 完全免费；支持中文版本 | 只是一个缺陷跟踪系统，对其他方面不涉及 |
| Apple XCode | 自动提供撤销重做和保存功能；编译速度极快，每次操作都很快速和轻松 | 更新版本后，某个插件可能会失效。 |
五.调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践，对每个软件的要求如下：
1.github
提交个人作业到github远端仓库。
github的可用性很高，而且使用起来不是很复杂，而且由于branch系统的存在可以很方便的控制分支，不会让主干代码混乱。但是由于完全使用这种命令行的格式，对于新手会有一些的不适应；不支持中文也是让人头大，有时它的错误提示需要看百度才能明白在说什么。
总体来说github还是很好用的，也是我使用率最高的软件。
2.Gitlab
创建了一个新仓库Intersect并从本地提交代码至gitlab远端
一个页面类似GitHub的代码仓库管理工具。它可以建立开发小组和各种仓库，可以对各个仓库里的开发分支，基线tag等进行保护等，大大地简化了我们日常代码管理工作。它相对于github的缺点是github这么多年来使用人数远大于gitlab，导致github上的可读的开源代码数量高于gitlab；而gitlab的优点是可以搭建免费的私人仓库，而这方面github是要收费的。
