个人博客作业week7

没有银弹：

Fred Brooks 在他的文章《没有银弹》中指出，发掘卓越软体设计者的三部曲：

１．尽早尽可能地以系统化的方式发掘最佳设计人员。

２．给有潜力者指派生涯规划师，并谨慎地规划他们的职业生涯。

３．提供机会给正在成长的程序员，让他们能相互影响，彼此激励。

这里假定了某些人已具备成为卓越设计师的必要潜能；工作只是诱导他们前进。Alan Perlis 说得更简洁了，你可以教任何人学雕塑，但对米开朗基罗而言，要教他的反倒是有哪些事不要做, 卓越的程序员也一样。软件工程面临的问题在于我们已经清除了大部分的次要复杂度，而剩余的（主要复杂度）都无法改变。如果回顾一下软件领域中取得的最富有成效的三次进步，我们会发现每一次都是解决了软件构建上的巨大困难，但是这些困难不是本质属性，也不是主要困难。

 高级语言

勿庸置疑，软件生产率、可靠性和简洁性上最有力的突破是使用高级语言编程。大多数观察者相信开发生产率至少提高了五倍，同时可靠性、简洁性和理解程度也大为提高。

分时

大多数观察者相信分时提高了程序员的生产率和产品的质量，尽管它带来的进步不如高级语言。  分时解决了完全不同的困难。分时保证了及时性，从而使我们能维持对复杂程度的一个总体把握。批处理编程的较长周转时间意味着不可避免会遗忘一些细枝末节，如果我们停下编程，调用编译程序或者执行程序，思维上的中断使我们不得不重新进行思考，它在时间上的代价非常高昂。最严重的结果可能是失去对复杂系统的掌握。

统一编程环境

第一个集成开发环境——Unix和Interlisp现在已经得到了广泛应用，并且使生产率提高了5倍。为什么？它们主要通过提供集成库、统一文件格式、管道和过滤器，解决了共同使用程序的次要困难。这样，概念性结构理论上的相互调用、提供输入和互相使用，在现实中可以非常容易地实现。

大泥球：

是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。大泥球发生的主要原因可以归结为，1.一次性代码　　2.碎片式增长　　3.为了让软件不出问题　　4.Copy/paste导致问题转移（有问题的代码被复制到很多地方，不断蔓延）　　5.缺少前期设计　　6.应对需求和架构变化过晚。

伴随着软件越来越复杂，对软件的变更需求越来越频繁，更改所需求的花费越来越大。软件开发人员的悲剧就诞生了。软件的规模越大，各个部分之间的牵连越复杂，更改也就越难。如果软件简单并且规模小，更改还比较容易。但是随着用户业务复杂，几乎所有的软件的任务规模都会越来越大。危害难以想象。

瀑布模型：

有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如操作系统、编译系统、数据库管理系统等系统软件的开发。但是在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。在需求分析阶段，当需求确定后，无法及时验证需求是否正确、完整。

大教堂和市集：

大教堂模式和开放市集模式的比喻形象⽣动地将自由软件和商业封闭软件区分开来“一种是封闭的、垂直的、集中式的开发模式，反映一种由权利关系所预先控制的极权制度；⽽而另一种则是并行的、点对点的、动态的开发模式。”他在文中论证了⾃自由软件不仅仅是一种乌托邦的理想，而是在开发模式上真正代表着“先进生产⼒”，代表着历史发展趋势的必然。我们选用TFS进行代码管理，属于大教堂模式，另外以后可以用git进行管理。

敏捷开发：

 

Scrum 是一个敏捷开发框架，它由一个开发过程，几种角色以及一套规范的实施方法组成。它可以被运用于软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。在 Scrum 中，产品需求被定义为产品需求积压（ product backlogs ）。产品需求积压可以是用户案例，独立的功能描述，技术要求等。所有的产品需求积压都是从一个简单的想法开始，并逐步被细化，直到可以被开发。

精益软件开发模式是从丰田公司的产品系统开发方法中演化而来。它主要包括两个部分：一部分是核心思想及原则，另外一部分由一些在相应的工具构成。精益开发的核心思想是查明和消除浪费。在软件开发过程中，错误（ bugs ），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法制止。

动态系统开发方法（ DSDM ）是由快速应用程序开发（ RAD ）方法演变而来的敏捷开发模式。 DSDM 在普遍的敏捷价值和原则的基础上，定义了更加详细的流程，以涵盖更完整的项目生命周期。它们包括项目前期活动（pre-project activities ），项目可行性研究，功能建模，设计和开发，实施或部署，项目后期维护（ post-project maintenance ），等等。同时，每个过程都定义了诸如如何将每个功能模型转化为实际代码，如何将原型交付最终用户使用并审查，如何处理反馈信息等的详细步骤。因此， DSDM 相比于其它敏捷方法在过程上显得比较繁重。

特征驱动开发（ FDD ）是另一种敏捷开发方式，它将用户的功能需求划分成更小的功能特征，然后逐步地在每个迭代周期中开发实现这些产品特征。与 DSDM 方式一样， FDD 仍然会在项目初期对整个项目做较大的规划和建模，以获得对该系统的全面了解。但是相比较 DSDM 来说， FDD 在这些方面更简捷。