阅读感想
Silver bullet:
这篇文章从本质上解释了软件工程开发的复杂性。软件工程与其他自然科学不同，数学家和物理学家可以通过构造简化的模型来解释复杂的现象，从模型中获取性质，并通过实验来验证。但是在软件工程中这些方法不适用，因为复杂性是软件工程的本质。总的阐述了软件开发的复杂性后，作者又从几个方面详细说明了复杂性的缘由。
软件开发的适应性和易变性使得开发过程变得异常复杂。面对不停的需求变化，开发人员必须根据需求来更改工程，有时这样的更改会花费很高的代价。不可见性也是软件工程的一个特性。机械零件的制造或是建筑物的设计可以通过设计图来较直观地展现设计过程中的不足，使得改进方向较为明确，但软件开发不同，工程与代码的抽象性使得不能用直观的方式找出错误或不足产生的地方，往往修复一个小bug都会耗去大量时间和人力。
计算机研究人员也通过许多方法试图简化软件工程的复杂性，但是根据文中说的，这些方法都只是解决了accidental difficulties，而没有解决根本性的本质问题。所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力获得本质上的大幅度提升。
通过数周的软件工程课的实践我也体会到软件开发的过程远没有想象中的那么简单，各种意想不到的问题都会发生，需求的变更，错误的出现等等都会使开发过程变得艰难。虽然没有一种可以本质上解决软件开发的复杂性，我们人就可以通过前人总结的各种方法和工具使开发过程变得尽量高效。
瀑布模型
瀑布模型是由软件开发的规模变得庞大后而产生的一种开发的模式。就如文中所说的那样，在开发的规模很小时，比如个人的小程序开发，只提供内部小范围使用时，开发过程仅由分析和编码两部分构成就够了。而随着工程规模的扩大，开发过程的复杂性也会增加，步骤也会增多，并且各步骤间还存在着各种联系。
瀑布模型总的思想。将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。它的核心思想是按固定的顺序将问题化简，将功能的实现与设计分开，便于分工协作，即用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型的最大特点是将开发过程分成了一个个明确的阶段。为项目提供的按阶段划分的检查点，分成不同的阶段后可以使项目分成各个不同的小组，或是划分成不同的开发阶段。但是这个模型也存在着一些缺点，比如不适应用户需求的变化等等。
大泥球
大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，我们看到了多种指导方法，与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而，实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。大泥球发生的主要原因可以归结为：一次性代码，碎片式增长，为了让软件不出问题。
我们小组的工程是在前人工作的基础上进行更改与扩充，在一开始阅读他们的代码时，我们就发现了类似大泥球的代码，许多代码重复冗余。所以在改版的开发中，我们删去了所有杂乱的代码，几乎是进行了重写。并且进行重新编写时，注重扩展性和可重用性，尽量避免大泥球的出现。
大教堂和集市
世界上的建筑可以分两种：一种是集市，天天开放在那里，从无到有，从小到大；还有一种是大教堂，几代人呕心沥血，几十年才能建成，投入使用。当你新建一座建筑时，你可以采用集市的模式，也可以采用大教堂的模式。一般来说，集市的特点是开放式建设、成本低、周期短、品质平庸；大教堂的特点是封闭式建设、成本高、周期长、品质优异。
我们组的项目有些偏向于教堂式，虽然开发周期不算长，但是开发过程没有开放，对于软件设计本身考虑了高扩展性，算法也经过仔细推敲，开发的成本不算低。
A Generation Lost in the Bazaar
这篇文章阐述了对于软件工程较为悲观的几种看法。学会编程并不难，但是编写好的程序，并且在工程中能与他人高效合作，高质量完成软件并不是一件轻松的事。我们团队中尚未出现严重的现象。团队内组员的经常讨论，尽量避免错误方向的出现。例如之前有组员编写代码出现大量重复冗余，后来经过该进解决了这一问题。
敏捷开发
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。敏捷建模的价值观包括了五个价值观：沟通、简单、反馈、勇气、谦逊。
在我们小组的开发过程中，还是比较注重沟通的，代码编写中遇到什么困难，都倾向与互相讨论，积极反馈。
对于简单的原则，考虑到时间的有限我们也避免过多的设计不必要或者次要的功能，尽量使系统简单明了，保持功能的基础上便于开发。
