No Silver Bullet: Essence and Accidents of Software Engineering（Frederick P. Brooks, Jr.）
在这篇文章中，作者将内容分成了三大部分，第一部分介绍了软件开发中根本的——软件特性中固有的困难，而这些困难是：软件实体的复杂性、软件和其它接口的一致性、软件实体的可变性以及软甲本身的不可见性。这是这些根本的特性导致了软件开发的困难。
第二部分讲了次要的——出现在目前生产上的那些困难。作者列举了软件领域中取得的最富有成效的三次进步：运用高级程序语言、开发软件的分时以及编程环境的统一，这些进步都给软件开发带来了极大的便利，但是都没有从根本上解决软件开发过程中的困难。
第三部分作者提出了Silver Bullet可能的希望所在。比如Ada和其他高级编程语言，面向对象编程或者人工智能的自动编程等等，软件开发最关键的还是开发人员，培养优秀的软件设计师是至关重要的。
There Is a Silver Bullet（Brad J. Cox）
这篇文章明显和No Silver Bullet一文有合应的意味，文章开篇就引用了Brooks的一段话，并且文中关于解决现代软件工程中的一些问题的看法也是有很多共同之处。
文章的结构很明确，首先阐述的是面向对象的编程思想，从原来的面向过程的编程到现在的面向对象的编程， 面向对象是一种自下而上的程序设计方法。不像过程式设计那样一开始就要用main概括出整个程序，面向对象设计往往从问题的一部分着手，一点一点地构建出整个程序。面向对象设计以数据为中心，类作为表现数据的工具，是划分程序的基本单位。而函数在面向对象设计中成为了类的接口。面向对象设计自下而上的特性，允许开发者从问题的局部开始，在开发过程中逐步加深对系统的理解。这些新的理解以及开发中遇到的需求变化，都会再作用到系统开发本身，形成一种螺旋式的开发方式。
接下来作者以哥白尼的天体理论革命来喻指软件工程中的一系列变革，这些变革和上一篇文章中基本上都有所涉及，比如说模块化设计和多层开发，可以重用的软件组件，这些都体现了面向对象编程的思想，可以解决软件开发中遇到的一些问题，节约开发时间和开发成本。
Big Ball of Mud（Brian Foote and Joseph Yoder）
在本文中，作者阐述了软件开发中大泥球的含义，产生原因以及解决方法。大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。就比如我们有的时候在编写程序时对某种方法不清不楚，为了实现一个功能拼凑出来一段代码，表面上功能实现了，但是里面有各种各样的问题，当问题出来的时候，回头看一头雾水，拆拆这里，动动那里，把软件修改的面目全非。给软件开发带来了极大的障碍。
这些年来，为了对付这个泥球，我们看到了多种指导方法，比如SOLID、GRASP和KISS，与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而，实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发（Agile）的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。
我们的软件中肯定也会有这种现象存在，首先我们在开发初始要尽量的去避免，以一个良好的编程习惯去写代码，注意写注释和说明文档，避免自己回头看的时候不能很好的理解自己的代码。然后尽量将代码模块化设计，代码的架构必须清晰，每个模块执行的功能都说清楚并且要确定自己写的这个模块的确可靠，这样进行拼接的时候就不会出现各种各样奇奇怪怪的问题。还有就是在发现这些问题的时候一定要及时解决，避免积小成大，积累成大泥球的时候就很难解决了。
CatB – Cathedral and the Bazaar
这篇维基百科中的文章主要介绍了自由软件开发的两种模式。第一种是：大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。第二种是：市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。
从字面上理解就能看出，大教堂模式更适合商业化软件的编写，一个团队负责自己开发的软件从开发到维护，如果软件出现问题，也能够很好地解决，但是这和现在的极限编程以及快捷编程的思想不符合，这种模式可能会创造出经典的软件产品，但是开发周期长，不能很好地适应目前多变的市场环境。
而第二种市集模式体现的明显就是现在的代码开源思想。代码开源，让够多人看到源代码，错误将无所遁形。大教堂模式能够参与到代码编写维护的工作中的人明显只是少数，而市集模式则不同，更多的人参与进来，编程也更加小型化，适应现在多变的市场，开发节奏明显加快。
如果拿我们团队现在编写的MOOC客户端来说，我们现在明显采用的是大教堂模式，因为我们还没有将代码公开（但是感觉也不会有什么人来看我们的代码）。但是从另一方面来看，迭代开发明显又属于快捷编程的范畴，我们一个小的团队将工作拆分模块化，每个人负责一项工作，这又像是集市模式。说不清楚了。
图灵社区：A Generation Lost in the Bazaar（Poul-Henning Kamp）
“大教堂和市集”对应着的就是商业模式和开源模式，有一条评论说得特别好：“不管开源还是商用，都需要商业机会和商用环境，这就是市场杠杆，在市场需要的基础上，去谈论技术优劣与否，才有意义，否则就是吵吵嚷嚷。就技术论技术，意义何在？世上哪有完美的事物？开源不等于拒绝商业，有市场需求，就有其存在的空间，不管你怎么讨厌它。”不管哪种开发模式，最终决定其走向的还是市场需求。没有市场，不管哪种开发模式都不能生存下去，开源模式适应了市场，虽然还有一系列的问题，但是它的确满足了人们现在的需要，而作者提出的一系列的问题可能很多用户都不会在意，只是开发者个人的技术洁癖。
开源最大化了群体智慧，增加了复杂性；而敏捷去繁留简，丢失了规范化。这些“集市”上的东西可能很粗糙，但肯定会实用，而且其带来的繁荣也是不可忽视的。
这种现象在我们的工作中应该还没有出现，因为我们写的MOOC客户端如果和目前市场上的软件相比其实很单薄，代码量也没有那么大，所以代码之间冗余的东西也不会多，不过如果以后开发更大的软件，难免会用到网络上一系列的方法、类，这样的话这种问题肯定是会存在的，但是不能因为这些问题的存在就停止整个工作的进行，大方向架构正确的话，相信是不会有根本性的问题的。
The Rise of “Worse is Better”（Richard Gabriel）
这篇文章写得很清楚也很好明白，首先是用两个教授分别来自the MIT和the New Jersey的一段讨论来向读者介绍了什么是MIT approach，什么是Worse is Better模式。从文中我们能够很清楚的看出，MIT approach更加偏重于软件的正确性，软件的正确性是必须放在首要位置的，其他的一切特性都要为正确性让路，可以想见，这种开发模式更像是“大教堂模式”，开发的软件功能能够做的很齐全，也很准确，把各种可能都给用户考虑到，但是这种模式无疑开发需要的时间以及人力物力更多，开发难度也更大。
而Worse is Better模式的首要原则是简单，即使是正确性也要为简单原则让路。这种模式考虑的是一款软件用户用到的功能可能只有那么几种，其他的功能即使你设计的再完善，用户可能根本挤用不到，所以以简单为先，这样设计出来的软件会更加简单轻便，消耗的资源更少，很容易在各种配置的机子上面运行而不用担心运行不流畅的问题，首先满足用户最基本的需要，然后再逐步改进，在满足简单原则的情况下使软件获得最多的功能，即使这功能依然没有MIT approach模式设计出的更加完善。
我认为Worse is Better这种模式能够获得更多的支持，因为对大多数用户来说，判断一款软件好不好用的指标不是各种功能是不是完善，而是软件是不是很流畅，是不是能解决我的问题。软件功能的完善性他们是不会考虑的，因为那些功能他们根本用不到，而MIT approach开发出的软件虽然功能齐全，各种情况比较完善，但是因为软件复杂，要求配置高很可能会被用户舍弃。
ANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS（Winston W. Rovce）
这篇文章主要就是讲述了瀑布开发模型的特点还有一些优缺点。瀑布模型其实就是分析与编程，象工厂流水线一样把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。这种模型因为非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。
瀑布模型现在应该已经采用的场合已经非常的少了，因为这种开发模式的种种缺点不适应现在这种市场环境。它的缺点主要表现在：
1、强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。
2、没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应，瀑布就意味着没有回头路。
3、瀑布模型不适合客户需求不断变化的软件开发，尤其是客户的业务管理的软件，业务随着市场变化，而软件初期的设计可能已经大大变化，而后期的需求更改成本是开始的10倍基数。
4、瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动。
缺点很明显但它同时还有一些优点：就是讲软件开发的每个部分都细化，分工明确，简化项目控制，并减少开发阶段不必要的跨团队交流。无需频繁修改计划，项目评估与管理也不再繁琐。