我的博客做业 #4

•  No Silver Bullet

　　Fred Brooks在1987年所发表的一篇关于软件工程的经典论文《No Silver Bullet》中谈到:全部软件活动包括：

1. 根本任务—— 打造构成抽象软件实体的复杂概念结构；
2. 次要任务—— 使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。

　　其中软件工程师在次要任务上花费了过多的时间，然而次要任务占软件工做的比例有限，因此一味地从次要任务方面进行优化没法带来软件生产率数量级上的提升，须要开始关注软件的根本任务。

　　人们在软件开发中试图寻找一种可以使得软件可以像硬件中的电子管、晶体管那样指望每两年有两倍的增加。然而并不存在任何技术或管理上的进展，可以独立地保证软件在生产率、可靠性或简洁性上取得数量级的提升。这是由软件的自身特性决定的，可是却拥有一些使人振奋的革新。这些方法的规范化、持续地开拓、发展和传播确实可使生产率产生数量级的提升。由此，产生了如今的软件工程。

 

　　现代软件系统中有一些没法规避的内在特性：复杂度、一致性、可变性和不可见性。

1. 复杂度。软件实体可能比任何由人类创造的其余实体更复杂，软件系统的状态又比计算机的状态多若干个数量级，软件实体的扩展不只仅是相同元素重复添加，致使软件复杂度要比非线性增加多得多。

2. 一致性。软件工程师所要面对不少状况，好比：必需要遵循许多人为惯例。这些惯例随接口的不一样而不一样，然而，这些变化并非必需的，仅仅因为它们是不一样的人设计的结果。在这种状况下，软件的复杂性来自：须要保持与其余接口的一致性，对软件自身的任何再设计，都没法简化这一复杂特性。

3. 可变性。软件实体常常会遭受到持续的变动压力。功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了不少新用法的用户们。此外，软件必定是在某种计算机硬件平台上开发，成功软件的生命期一般比软件开发时所用的硬件平台要长。软件必须与各类新生硬件保持一致。
4. 不可见性。软件是不可见的和没法可视化的。软件的客观存在不具备空间的形体特征。所以，没有自身的几何表达方式。

 

　　在软件领域中取得的最富有成效的三次进步体如今对于次要困难的解决包括：高级语言，分时，同一编程环境。

1. 高级语言。软件生产率、可靠性和简洁性上最有力的突破是使用高级语言编程。大多数观察者相信开发生产率至少提升了5倍，同时可靠性、简洁性和理解程度也大为提升。  
2. 分时。分时在提升程序员的生产率和产品质量方面起到了很大做用，分时保证了及时性，缩短了系统的响应时间。随着它接近于零，超过人类能够辨识的基本能力—— 大概100毫秒时，所得到的好处就接近于零了。
3. 统一编程环境。集成开发环境经过提供集成库、统一文件格式、管道和过滤器，解决了共同使用程序的次要困难。这样，概念性结构理论上的相互调用、提供输入和互相使用，在现实中能够很是容易地实现。集成开发环境的普遍应用使生产率实现提升。

 

　　然而，如以前所述，一味地从次要任务方面进行优化没法带来软件生产率数量级上的提升，须要开始解决软件的根本而非次要问题，能够从如下几个方面来考虑：

1. 快速原型化系统的方法和工具。软件系统的快速原型对重要的系统界面进行模拟，并演示待开发系统的主要功能。
2. 增量开发—— 增加，而非搭建系统。这种开发模式对士气的推进是使人震惊的。
3. 卓越的设计人员。关键的问题是如何提升软件行业的核心，一如既往的是人员。

　　在咱们的团队项目中，咱们选择了C#，以及统一了VS开发环境，在次要任务上保证了软件开发效率，此外在主要任务方面咱们采用增量式的开发方式，在初步实践获得效果后，团队成员都特别兴奋，增长了对写一个相对完善软件的信心。

• Big Ball of Mud

　　大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，每每会致使不少错误或者缺陷。

　　在我的项目中，曾经出现过部分函数功能类似只有少许功能不一样，而后类似的功能直接采用代码复制，不只致使代码冗余度大，并且产生了许多潜在的bug，好比有少部分数组下标忘记修改致使结果偶发性错误，并且前期设计不够充分，以后使得系统愈来愈复杂，最终代码写了1000+，然而感受若是以前一个好的设计的话，代码最多400行左右。归纳总结避免大泥球的方法以下：在软件设计阶段首先须要关注软件的特性和功能，而后集中在架构和性能，使得软件设计之初就避免产生问题或者方向的误差。其次，在编写软件时要及时解决出现的小问题或者原型概念等等，这样不会使得问题堆积致使后期的没法修改。

• The Cathedral and the Bazaar

1. 大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每一个版本开发过程当中是由一个专属的团队所控管的。
2. 市集模式（The Bazaar model）：源代码在开发过程当中即在互联网上公开，供人检视及开发。

　　大教堂模式的软件开发让程式除错的时间大幅增长，由于只有少数的开发者可参与修改工做。市集模式则相反。

　　咱们的团队项目采用的是大教堂模式，因为咱们选用TFS进行代码管理，在必定程度上决定了代码只能属于大教堂模式，这样也就致使咱们的软件在开发过程当中只能由开发人员来保证软件质量，在必定程度上致使除错时间的增长，在以后的软件开发中能够考虑将代码由github进行管理，即时接受其余开发者的检视以及增量式开发。　

• A Generation Lost in the Bazaar

　　做者文中无情的揭示了集市模式致使的一个悲哀的现实：一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为什么物的所谓IT“专业人士”永无休止地复制着，粘贴着。这事儿放在今天你也许很难相信，但就是在这使人无比尴尬的混沌之下，沉睡着美轮美奂的Unix大教堂的遗迹，而Unix偏偏是以设计简约、功能实用、执行优雅而著称于世的。（世间荣耀就此消失……）咱们能够精确地指出Unix开始走向碎片化的时间点：1990年代初，AT&T抛弃Unix，将其商业化，抢走其架构师的那一刻。参考：有人负责，才有质量：写给在集市中迷失的一代。

　　而做者认为针对这一现象最有效的解决方式是：所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一我的，不能是几我的——二重奏除外。个人理解是针对软件的架构师必需要负责整个软件的生命周期，由于，软件的开发人员可能更迭，若是架构师不负责软件的维护，那么后续的开发人员对于软件很难有一个良好的把控，只能不明因此地沿用前人的代码，而没法对于已通过时甚至错误的代码作出适当的删改，致使软件的碎片化，以及文中指出的那样对于早已过期的Fortan编译器兼容性的检测。

　　咱们的团队项目采用增量式的方式进行开发，因为以前学长没有使用那些晦涩难懂的语法或者语言现象，咱们对于代码都可以清楚地理解和把握，因此咱们在团队开发中没有遇到相似的问题。我认为这是因为软件的规模所决定的，咱们的软件规模跟Unix这样的大型软件规模是无法相提并论的，软件的设计也只存在于开发者的头脑中，不存在架构师，这种问题也就相应地没有出现。

•  Waterfall Model

　　1970年WinSTon Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是惟一被普遍采用的软件开发模型。 

　　瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，而且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落，最终获得软件产品。

　　瀑布模型有如下优势：

1. 为项目提供了按阶段划分的检查点。
2. 当前一阶段完成后，只须要去关注后续阶段。
3. 可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增长更多的功能。每次迭代必须通过质量和集成测试。
4. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法能够在该模板下有一个共同的指导。

　　瀑布模型有如下缺点：

1. 各个阶段的划分彻底固定，阶段之间产生大量的文档，极大地增长了工做量。
2. 因为开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增长了开发风险。
3. 经过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。

　　在咱们的团队项目开发中采用的就是这种“瀑布模型”，因为咱们的用户需求相对固定，此外，瀑布模型给出了阶段的划分彻底可以适应咱们项目开发的模式需求，故而采用这种模式。

• Agile Methods

　　敏捷型方法的合理性，着重点并非放在其“轻重”上，而是于它们的适应性（adaptive〕性质和以人优先的理念。

　　多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix〕。设计过程充斥着短时间的、即时的决定，而无完整的规划。软件行业中最初的一场运动是要改变这种状况，而引入了“正规方法” （methodology〕的概念。敏捷型方法（agile methodologies）的发展是对这些工程方法的反叛。

　　敏捷型与工程型方法有一些显著的区别。其中一个显而易见的不一样反映在文档上。敏捷型不是很面向文档，对于一项任务，它们一般只要求尽量少的文档。 从许多方面来看，它们更象是“面向源码”（code-oriented〕。事实上，它们认为最根本的文档应该是源码。

　　文档减小仅仅是个表象，它其实反映的是两个更深层的特色：

• 敏捷型方法是“适应性”而非“预见性”。 工程方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划， 而后依计划进行开发。这类方法在通常状况下工做良好，但（需求、环境等）有变化时就不太灵了。所以它们本质上是拒绝变化的。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能容许改变自身来适应变化。
• 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 工程型方法的目标是定义一个过程，无论是谁用都工做。而敏捷型方法则认为没有任何过程能代替开发组的技能，过程起的做用是对开发组的工做提供支持。

　　不可预见过程的控制 － 迭代

　　对付一个不可预测的世界呢？最重要，也是最困难的是要随时 知道咱们在开发中的情形处境，这须要一个诚实的反馈机制来不断准确地告诉 咱们。这种机制的关键之点是“迭代式”（iterative〕开发方法。

　　虽然迭代式开发也可用于可见性环境，但它基本上仍是用做“适应性” （adaptive〕过程,由于适应性过程能及时地对付需求变动。需求变动使得长期计划是不稳定的，一个稳定的计划只能是短时间的，这一般是一个“迭代周期”（iteration〕。迭代式开发能让每一个迭代周期为下面的开发计划提供一个坚实的基础。

　　一些敏捷开发的方法

• XP（Extreme Programming －－ 极限编程〕

　　XP始于五条基本价值观（values）：交流，反馈，简洁，勇气和尊重（Communication, Feedback, Simplicity, courage, and Respect）。在此基础上细化出了十四条原则（principles）和二十四条实践法（practices）。其基本思想是： 实践是项目组的平常的具体活动，而价值观是根本性的知识和理念，其构成了该方法基石。没有实践法的价值观是难于应用的，或失之于过于宽泛而不知从何着手。没有价值观的实践法则是一堆杂乱无章的活动。价值观和实践法都是须要的， 但中间还有一个空档－－而原则正是用来链接价值观和实践的。许多XP的实践法都是之前就存在的并通过实践检验的，而经常被许多过程，包括那些计划型过程给忽略了。XP从新创建了这些准则，并把它们编织成了一个和谐的总体， 使得每一项准则都能在其余准则里得以强化。

　　XP有一个最具冲击力的是它对测试的极端重视。诚然，全部的过程都提到测试，但通常都不怎么强调。但是XP将测试做为开发的基础，要求每一个程序员写一段源码时都得写相应的测试码。这些测试片断不断地积累并被整合到系统中。这样的过程会产生一个高度可靠的 建造平台，为进一步开发提供了良好的基础。这种方法常被描述成 Test Driven Development(TDD)（测试驱动开发），它对许多不是彻底采用XP的方法都有很大的影响。

• SCRUM

　　SCRUM的着重点是在软件开发的管理方面。它把一个项目分红若干个为期三十天的迭代阶段，每一阶段称之为一“冲”（sprint〕。天天有一个短会， 称之为一个scrum，这样管理者能对项目有近距离的观察与控制。SCRUM对工程实践方面强调少一些，许多人在开发中把SCRUM的项目管理和XP的工程实践相结合。

• 水晶（Crystal）系列

　　全部水晶方法都有三个需考虑的优先因素（priorities）：安全性（safety） （项目的结果），效率（efficiency），和习惯性（habitability）（即开发人员 多大程度上愿意使用水晶方法）。其余共同特征有：频繁发布，反思改进，紧密交流 （Frequent Delivery,Reflective Improvement, and Close Communication）。

• 相关环境驱动测试（Context Driven Testing）

　　敏捷开发运动最初是由软件开发人员来推进的。可是，参与软件开发的其余方面 的一些人士也受到这个运动的影响。一个明显的群体是测试人员，他们一般是生活 在由瀑布式开发所限定的世界里。通常来讲，测试的做用是保证软件与开始的设计 相符合。而在敏捷世界里，测试人员的角色还很不清楚。这致使了一个称之为“相关环境测试”（context driven testing）的群体。

• Lean Development（精悍开发）

　　Lean movement（精悍生产运动）是由丰田公司（Toyta）Taiichi Ohno独创，并以 丰田生产系统（Toyota Production System）著称。精悍生产的理念对许多早期的 敏捷论者多有启发。

• （Rational）Unified Process

　　RUP最主要的特征是用例驱动开发（Use Case Driven）（即，开发是以用户可见 的系统功能特征来驱动的），迭代，和以架构为中心（须要优先考虑的一点是， 尽早设计出一个架构以贯穿项目始终）。

　　在咱们的团队项目中，对于需求变化以及其余的不可预见性采用了迭代的方式进行予以适应性的变化，采用的敏捷开发方式是scrum，总共进行了两次为期两周的冲刺。团队编程中也使用部分极限编程的思想。其中最重要的就是交流和反馈思想的使用，这使得在团队成员之间规避了许多理解上的分歧，从而少走了许多弯路。