个人阅读2

     首先我不得不说的是——全英文的阅读确实十分折磨人。

　1.no silver bullet 这篇文章作者以狼人和银色子弹引入，讲了当前软件开发没有便捷的途径，由于软件开发本身的复杂性，使其不可能像计算机硬件那样，一下子取得飞速的进展。我体会比较深的一点是，作者将软件创作概括为了本质性工作（essential task）和附属性工作（accidental task）。前者是去创造出一种由抽象的软件实体所组成的复杂概念结构，后者则是用编程语言来表现这些抽象的实体，并在某些空间和速度的限制之下，将程序对应至机器语言。

　　布鲁克斯认为，附加性的困难会随着工具的改善而逐渐淡化，反而是本质性的困难最难以解决，因为大部分的活动是发生在人们的脑海里，缺乏有效的辅助工具。依造布鲁克斯的说法有下列几项：

 

• 复杂性（complexity）：软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的。
• 隐匿性（invisibility）：尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难。
  
• 配合性（conformity）：在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难。
• 易变性（changeability）：软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。

　　但是就目前的软件开发来看，附属性工作仍然占到了软件开发的很大一部分工作，就像我们小组进行开发，首先要去搭建环境，然后连接到远程桌面，连接到数据库，进行各种配置等，占用了不少时间，包括学习如何使用数据库，建表，存储数据等等，真正用来思考算法或者去实现某项功能的时间很有限，我们大部分时间还是用在了前人已经做过的工作之上。当然可能是因为第一次进行软件开发，这方面的经验比较少，所以用的时间比较长。而且我个人觉得这个过程其实是比较重要的，我们需要经历这样的一个过程来熟悉自己要做什么，如果只是单纯的进行技术上的开发，可能会在一些细节上遇到麻烦。所以现在辩证的来看待作者说的这句话，或许以后随着技术的发展，那些所谓的附属性工作会减少，软件开发的效率会有一些提高，但是就我个人的观点，我觉得这种提高不可能是软件开发的银色子弹，个人觉得减少附属工作不具有成为银色子弹的基础条件。

　　软件开发的复杂性导致了这银色子弹的制作十分困难。作者在文中提到的分时技术，建立统一集成的开发环境的确实可以在一定程度上加速软件的开发。但是我觉得最有可能成为这发银色子弹的是面向对象编程的提出。面向对象程序设计（object-oriented programming）已被许多软件工程的学生寄予了更多的希望，Dartmouth 的 Mark Sherman 指出，有两个不同的概念我们必须小心地加以分辨，从名称上就可以看出这两个概念的不同：抽象数据类型和层次结构式类型。后者也被称为类型（class）。所谓抽象数据类型，其概念就是一个对象的类型应该由一个名称、一组适当的值和一组适当的操作方式来定义，而不是以它存储的结构来定义，这部分应该是要被隐藏起来的，例如Ada的包裹（package）（使用私有类型）或Modula的模块（module）。

　　为什么我认为面向对象编程会成为这发子弹呢。首先就我们进行学霸系统开发的过程可以感受得到，我们不需要再自己去设计什么复杂的代码，不需要从头进行开发什么强大的功能，那分词程序来举例，如果让我们在短短的十天之内完成一个比较准确的分词程序的书写，几乎是不可能的，但实现我们却很容易的借助当前已经存在的一些api，通过将其加入到我们的系统中，非常轻松的实现了这一功能。而这就是面向对象编程带来的便利。目前，网上存在着各种各样的免费的接口api，各种开源的源代码，当我们需要实现每个具体的功能时，不再需要自己一点一点的设计，书写，只需要去网上寻找类似的，一些团队曾经写过的项目，将其嵌入到自己的程序即可。而这在很大的程度上减少了我们软件开发的时间，让软件开发变得十分快捷。当前各种各样的大公司都有自己的程序包。微软的vs软件当中就有各种各样功能强大的安全的包供我们免费使用。我们不需要知道它的具体实现是什么，只需要知道输入和输出，直接调用就可以使用。

　　也许在不久的将来，当这些共享的接口达到一定的数量的时候，或许他就会成为软件开发的一颗银色子弹，让软件开发也变得简单。

 

2.There is a silver bullet。当读到这篇文章的时候，我发现这篇文章就是讲的我前面提到的面向对象编程的思想（窃喜）。

　　这篇文章的作者也认为面向对象编程可以成为软件开发的一颗银色子弹，作者举了哥白尼革命以及工业革命来佐证自己的观点，一些目前看似不可能发生的事情可能会因为一些事件的推动，瞬间变得轰轰烈烈起来，就像工业革命，将人类从农业时代带入了便利发达的工业时代，这在以前看来是不可能的，但它确实发生了，而面向对象编程就是软件开发的革命。可重用的软件组件就是一个很好的范例的关键测试能力揭示过去看似混乱的简化结构。 当然,传统技术与面向对象技术战斗,Ada战斗Smalltalk,objective - C,c++战斗和快速成型战斗的传统方法,如美国军用2167和洁净室。只有一个语言会被采纳到整个软件开发行业,每一个新的竞争者必须腾出手来和老的梦寐以求的冠军。 “不同级别的生产国和消费国的层次结构不能寻求专业工具和可重用组件的专业任务,技能,和利益,但必须适合自己的最新常用的万能药。 

　　通过专注于产品而不是过程,一个简单的模式出现,让人想起不同的集成水平的硬件工程。 卡片上的水平,可以把现成的卡片构建定制的硬件解决方案,而无需了解焊接烙铁和硅片。 芯片级,供应商可以建立卡片从现成的芯片,而不需要了解一门——和块级别的细节,他们的供应商必须知道构建硅芯片。 每个模块/绑定技术封装的复杂性,其消费者不必知道或关心组件实现了从一个较低的水平,但只有如何使用它们来解决眼前的问题。

　　通过阅读这篇文章更加坚定了我认为面向对象编程就是软件开发的银色子弹的观点。当然，我也期待着其他的银色子弹的出现。只是就目前发展来看，面向对象最有可能成为这发银色子弹。

 

3.big ball of mud.这篇文章主要从软件的架构方面介绍了软件开发。

　　大泥球的定义为，它是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。这样的一种系统结构不可避免有许多缺点，它无法使得系统内的信息得到更好的控制和共享，使得信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。而造成这种状况的原因有几个方面：

　　首先，程序员在编写程序或是系统时遇到问题后的解决方法，往往不是合适的或者最优的解法，而是方便修改的，变动最小的，这就为以后的系统架构的混乱甚至整个系统的奔溃埋下了隐患。其次，用户的需求或者编程的要求是在不断地变化的，任何一个已有的系统都随之会产生重大的变化，使得系统越来越复杂化，维护也越来越昂贵，另外编写人员的变动等等因素都会导致系统的退化，一步步变为大泥球。所以，可以将其产生的原因归结为：一次性代码，碎片式增长，缺少前期设计，应对需求和架构变化过晚，程序员的经验，技巧，眼界的限制。

　　当然这种大泥球是可以避免或者修改的。首先，程序员或者设计师为了在预算中并按时交付高质量的软件，就需要关注软件的特性和功能，然后集中在架构和性能，使得软件设计初步就避免产生小的问题或者方向的偏差。其次，程序员在编写软件时要及时的解决出现的小问题或者原型概念等等，这样不会使得问题堆积导致后期的无法修改。另外，应当及时处理用户需求的变化，由于需求往往会随着时间的推移而变化，所以应当逐步的解决，并且鼓励和积极面对变化而不是掩盖问题。另外，要保持一直工作的状态，不断地维护需求和系统。但不应当进行一次彻底的检查，这样很可能会破坏系统。当然，软件系统也是在变化的，但是不同的部分会以不同的速度变化，所以应当使得它们的变化率一致。最坏的结果就是代码已经下降到了无法修复甚至理解的地步，那么就扔掉，重新开始。

 

4.The Cathedral and the Bazaar大教堂和集市

　　维基百科给出的定义为：

　　大教堂的模型：在大教堂模式中，每一个版本的源代码都是可以被用到的，但是在不同版本间的已经开发好的代码被限制在一个专有的软件开发团队中。

　　集市的模式：在集市模式中，代码的开发是通过互联网以大众的视角来开发的。

　　就我们在学把系统开发的过程来看，我们的开发应该属于第二种模式，我们是通过互联网以大众的视角来开发。雷蒙德指出的19个软件开发的实践经验中，有一点我非常认同：好的程序员知道写什么。 伟大的知道要改写(和重用)。目前的网络上各种各样开源的代码有很多，软件开发的起点越来越高，懂得重用别人的代码可以大大节省我们软件开发的时间。而这也是面向对象编程带给我们的便利。

 

5.有人负责才有质量：写给集市中迷失的一代

　　这篇阅读主要讲的是当前计算机程序的开源在一定程度上让程序员们有一些迷失，当遇到某项编程任务的时候，越来越多的程序员想到的不是自己动手去写，而是去“大集市”中搜索，获取开源的代码。

　　文章最后的几个评论我觉得倒是很有道理，如下截图：

　　这个评论很鲜明地指出了现在编程存在的问题，但也给出了原因，因为软件开发的需求增长过快，对软件中算法的钻研变得少了，软件的细节很模糊，不过精致。

这些评论比较清楚地讲出了当前软件开发的矛盾所在。当有某些功能需求时，我们是要自己写，还是去找开源代码。自己写要付出的时间和精力有时候是我们无法承受的，但是寻找开源的代码，我们又不能保证其正确性和安全性，不能保证它的每个具体的细节是否会有一些疏漏。至于谁对谁错，各有各的道理，我也评判不了。

 

6.瀑布模型

　　根据百科的定义：瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

　　核心思想：瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

　　瀑布模型重要意义：它是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。

　　瀑布模型的概念图如下：

    　　　　　　

　　这个模型也是罗杰老师在第一节课上给出的软件开发的过程，当时看着没什么感觉，现在在做了学霸系统之后，才感觉到有一个正确的开发流程的指导对于软件开发是多么的重要。瀑布模型可以让我们的软件尽可能的减少错误，减少修改代码的工作量。

 

7.关于敏捷开发

　　 敏捷开发方法相对于传统的软件开发方法的一个明显的不同就是敏捷开发是与代码为主的，强调代码是文档的主要部分。相对于传统的软件开发方法，敏捷开发方法有以下的特点：

（1）敏捷开发方法是适应性比预见性更重要。

（2）敏捷开发是以人为本而不是以项目为本。

      敏捷开发方法之所以提出适应性比预见性更重要是因为需求的变化往往是不可预见的，因此强调软件开发要有很好的适应性，预见性显得不是那么重要；作者在文中 提出的解决的方法是迭代（Iterations），利用迭代控制不可预见的过程。敏捷开发中提出把人放在首要位置，但是可能会遇到一些问题，但是作者给出 了相应的解决方法，作者提出了程序员要对自己设计的模块负责，描述了管理以人文本的项目的方法，并且提到了商业领导的职责是什么。

      敏捷开发过程往往是一个自适应过程，要不断的在需求的变化下有一定的适应能力。下面作者就提到了一些比较流行的敏捷开发方法：

（1） XP（极限编程）。XP是一个轻量级的、灵巧的软件开 发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以 从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的 小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整 开发过程。

（2）SCRUM方法论。Scrum是一种迭代式增量软件开发过程，SCRUM方法论中其核心仍然迭代和增量，首先对于产品需求会划分为多个迭代或增量，每个迭代都需要在1个月能够交付，而一个月即是一次冲刺，而一个迭代版本又需要转化到每天的进度跟踪和问题解决，这就是每天的15分钟会议(每日站立会议)，在会议上必须回答当天的进度，明天的计划和是否存在问题。

（3）Crystal Methods-水晶方法。水晶方法把 开发看作是一系列的协作游戏，而写文档的目标就是只要能帮助团队在下一个游戏中取得胜利就行了。水晶方法的工作产品包括用例、风险列表、迭代计 划、核心领域模型，以及记录了一些选择结果的设计注释。水晶方法也为这些产品定义了相应的角色。然而，值得注意的是，这些文档没有模板，描述也可不拘小 节，但其目标一定要清晰，那就是满足下次游戏就可以了。我总是将这些思想以下面的方式向我的团队成员表达：通过它们，你只要了解你明天加入这个团队所要知 道的内容就行了。对于水晶方法论，根据方法论的轻重可以分为透明水晶和橙色水晶等。透明水晶一般是轻量级的团队适用。不管是哪种水晶，都会对团队的角色， 团队的工件和产出，核心实践，支持过程等进行定义。

（4）上下文驱动测试。以测试驱动开发也是提高软件项目适应性的一种方法。

（5）精益开发。

（6）（理性）统一过程。软件项目最后肯定是要将各个模块组合起来的，敏捷开发最后也需要一个理性的统一过程；当然这样是用例驱动的过程。

　　读了这篇文章我意识到，我们当前正在进行的软件开发就用到了其中的很多方法，极限编程，scrum开发过程。在这过程中都有所收获。敏捷开发作为当前比较好的开发方式，可以让一个软件项目更加有生命力，面对市场需求的快速变更，具有更好的适应性，这在一定程度上就减轻了软件后期维护的工作量。