[BUAA软工]第一次博客作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 北航软工 |
| 这个作业的要求在哪里 | 第1次个人作业 |
| 我在这个课程的目标是 | 学习如何以团队的形式开发软件，提升个人软件开发能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 督促我阅读《构建之法》，了解软件开发的具体含义及流程 |
快速看完整部教材，列出你仍然不懂的5到10个问题
如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？
书的第一章使用民航飞机的安全功能举例，虽然这个功能的使用率不足百万分之一（可以理解为飞机出现事故的概率？），但是却十分重要，并且如果没有的话就不能让乘客安心乘坐。书用这个例子类比商业软件开发，意在告诉我们，虽然对于一个软件来说，某个功能的使用概率是百万分之一，但是仍要设计实现、并教会用户使用。
对于民航飞机的例子来说，我无比赞同；对于商业软件开发中，实现利用率极低的功能的重要性的阐述，我也能理解。但是，我不明白这两者之间关联的必要性。如果说，这个功能是保护用户的核心数据（类比民航飞机的安全系统保护乘客的生命安全），且没有别的手段与之相配合，那么这样的比喻我可以理解。但是，这样的说明却在例子的描述中看不到。如果没有这样一个重要的前提假设，我就无法理解实现这样一个利用率可不计其数，且并不是非它不可的功能的说明了。
在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。
书的第四章，谈到了结对编程。以Intuit公司的两位程序员的60小时极限马拉松编程为例子，提出了两个人分别作为领航员和驾驶员的完成程序实现的模式。
这样开发的模式，确实与我们传统完成代码实现的过程不同。但是，书中的例子中的两位程序员是别无发他的举措，这样做在不处于那样的窘境中的时候还是必要的么？既然未来软件团队都是以团队的形式做开发，我们又为什么要学习两人结对的模式呢？
并且，书中提到的两个人肩并肩的开发，在现在的条件下并不现实。就那我举例，我的同伴白天要去公司实习，所以只能晚上编程。而我晚上会做一点兴趣方向的研究，所以只能白天编程。这样的话，我们的编程模式就变成了，经共同探讨后，一个人先敲一部分，另一个人理解了之后，再敲一部分。两人的编程过程却无法沟通。
杀手功能/外围功能
书中谈到，要按重要性划分功能，再决定进行不同的处理。具体的例子中， 提到了核心功能是OCR的文字识别，而外围功能是界面皮肤。但是，当下的市场中，消费者往往对于“外围功能”有些执着。比如VIVO，OPPO等手机厂商，当而皇之的将使用次当硬件配置，却着重宣传手机美图、颜值等的手机卖一线旗舰机的价格。与之对应比的是小米等厂商，用一流的硬件配置。但是，两者的用户群体是不同的，前者主要偏重于年轻女性，后者主要偏重于年轻的男性。
这样来看，是不是产品的功能核心与否也要取决于用户？
迷思之三：好的想法会赢
书中使用键盘键位虽不合理却不更新，以及美国仍在使用英制衡量制度的例子说明，光有一个好的创意是不行的，也需要与之配套的描述。
但这里美国仍使用英制衡量制度的例子，我觉得的有些不恰当。并不是只有美国曾经使用过英制衡量制度，最起码英国使用过的。但是现在却只有美国仍在使用。说明别的国家经过讨论，决定更改。而美国不仅自己的国会经过了讨论，并且也知道别的国家的更改制度理由。可以理解为美国接收到了“创新的宣传”，但仍未做出更改。所以，我认为，这里的例子并不能很好地说明观点。
迷思之五：要成为领域的专家、才能创新
这句标题与文中的例子未免都有以偏概全的嫌疑。对于无数的创新过程，书中仅仅以几例就驳倒创新与领域专家之间的关系。而标题更是忽视了可能存在的反例。对于这部分信息，我更想知道的是对于不同的领域，专家和创新之间的关系，是计算机领域的独特性质（早期待发展的部分很多）导致了这种现象么？还是这是一个普适的结论？
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件
软件（英语：software）是一系列按照特定顺序组织的计算机数据和指令，是计算机中的非有形部分。计算机中的有形部分称为硬件，由计算机的外壳及各零件及电路所组成。计算机软件需有硬件才能运作，反之亦然，软件和硬件都无法在不互相配合的情形下进行实际的运作。软件一词，最早于1953年在Richard R.Carhart的备忘录中被使用使用。
软件工程
软件工程（英语：software engineering），是软件开发领域里对工程方法的系统应用。
1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。
1993年，电气电子工程师学会（IEEE）给出了一个更加综合的定义："将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中"。此后，IEEE多次给出软件工程的定义。
在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件、嵌入式系统、人机界面、办公包、操作系统、网页、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，提高人们的工作效率，同时提升了生活质量。
【附加题】：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
Git 诞生背后的小故事
同生活中的许多伟大事件一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。
很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。
Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？
事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！
为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。
不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。
开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标：
- 速度
- 简单的设计
- 对非线性开发模式的强力支持（允许上千个并行开发的分支）
- 完全分布式
- 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
最后实际情况是这样的：Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以感受一下。
Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。
历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。
参考资料：Linux， Linux创始人，CVS， SVN， BitKeeper， Git
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
优缺点对比
RCS
- 简单
- 使用 Lock 机制防止多个开发人员对同一个文件同时进行修改
CVS
- 使用单一的主代码树,而不像 RCS 那样依赖多个目录
- 多名开发人员可以同时对一个文件进行修改.允许合并，实现并发开发。
SVN
- 目录的版本控制 CVS 只能对文件进行版本控制，不能对目录进行版本控制。
- CVS 只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操 作，因此也很容易使文件历史轨迹丢失。
- SVN 可以原子性提交。
- 当任何原因造成批量操作的中断时（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的状态
Git
- 采用了分布式版本库的方式，不必服务器端软件支持，使源代 码的发布和交流极其方便。
- 速度很快。
- 拥有合并跟踪（merge tracing）能力。
- 适合分布式开发项目
使用人数对比
| Name | Users | Projects | Alexa rank (lower = more popular) |
|---|---|---|---|
| Assembla | Unknown | 526,581+ | 37,451 as of 25 December 2018 |
| Bitbucket | 5,000,000 | Unknown | 869 as of 25 December 2018 |
| GitHub | 31,000,000 | 100,000,000 | 61 as of 25 December 2018 |
| GitLab | 100,000 | 546,000 | 1,885 as of 25 December 2018 |
| GNU Savannah | 93,346 | 3,848 | 67,386 as of 25 December 2018 |
| Launchpad | 3,965,288 | 40,881 | 7,481 as of 25 December 2018 |
| OSDN | 54,826 | 6,294 | 6,429 as of 25 December 2018 |
| Ourproject.org | 6,353 | 1,846 | 794,540 as of 25 December 2018 |
| SourceForge | 3,700,000 | 500,000 | 377 as of 25 December 2018 |