[BUAA软工]第一次博客做业---阅读《构建之法》

[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

来源：Wikipedia : Comparison of version-control software