Part 1 No Silver Bullet - Essence and Accidents of Software Engineering（没有银弹）
完读brooks的《没有银弹》这篇文章，我觉得他的主要观点就是：即使改进编程语言，软件工程的生产率在10年内也不能获得数量级上的提高，因为软件工程最大的问题在于解决概念完整性和处理沟通。作者在对问题进行分析时，并不是人云亦云，他反对很多流行的论断，他做出判断的依据通常是基于常识和经验的理性推理，他这种客观的分析方式同样值得学习，一下几点是我对这篇文章的总结和一些心得，如若有误，还劳烦批评指正。
一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括：数据集合、数据条目之间的关系、算法、功能调用等等。我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多数系统中的概念错误相比，它们是微不足道的。如果这是事实，那么软件开发总是非常困难的，天生就没有银弹。
软件工程牵涉的问题是非常复杂的，不似于大多说日常事务。由于软件产品特有的复杂度导致了成员之间的沟通非常困难，带来了软件产品的进度，质量和成本多方面的问题。特别是在软件规模增加的时候复杂度往往成倍上升。同时复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变得困难，从而妨碍了概念上的完整性。而且
必须遵循各种接口，考虑到各种环境的兼容，这些特性是无法通过设计改变的。
不仅如此，软件开发的过程必须要考虑如何适应变化，在需求，设计和编码过程中都需要考虑如何快速响应变化，如何提高软件产品的可扩展性。但是这些问题目前也没有行之有效的解决方式。而且软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。
所以就目前来讲，我们所做的项目只能按部就班，按照目前软件工程的既定步骤，逐步地完成。除了认真学习所学知识，团结协作，没有什么捷径可用。
Part 2 big ball of mud你的项目有一个大泥球么? 有什么解决办法？
所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，多种指导方法一起出现，然而实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。
很多时候无论花费多少时间试图去找出完美的软件结构,客户总是引入一个变化破坏这个结构,不存在完美结构,只存在那些试图平衡当前的代价和收益的结构。有时候,我们会把原因归咎于客户,责怪他们总是改变需求。有些人认为,只要客户的需求仅限于他们最初所声明的,那么我们的设计就是没问题的,所以错就错在客户改变了他们的需求。需求变化是非常正常的，JOBS说“用户根本不知道他想要什么，直到你把产品交到他的手中”。这种情况也是或多或少存在的。但是，客户连源代码都看不到，这种怨念却是没道理的。
结合我自己的编程经验，可以将其产生的原因总结为：一次性代码，碎片式增长，缺少前期设计，应对需求和架构变化过晚，程序员的经验，技巧，眼界的限制。
我们团队的代码中也肯定存在着大泥球，有些已经被发现的我们都已经尽力优化，当然在这个ALPHA版本中肯定还存在一些还没被发现的大泥球，我们将在剩下的一周测试的时间和BETA版本中，对这些问题进行处理。
Part 3 CatB – Cathedral and the Bazaar·
大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。
市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。
我认为作者写这篇文章，是鉴于当时的自由软件开发的现状。他不满于当时开发软件的低效率，而且，他认为，低效率的原因在于除错阶段花费了大量的时间。由此，他把开源软件的开发模式分为两种，一种是大教堂模式，源码公开，但是开发过程有一个团体控制；一种是市集模式，同源源码公开，且源码放在互联网上供人阅览，并可以贡献代码，进行开发。并且提倡市集模式，认为在足够的人的检视之下，BUG将无处藏身。
在我来看，市集模式既然能为全世界所接受，必有其优点所在。所谓“众人拾柴火焰高”，当然软工工程不能类比于“拾柴”，不过道理确实是这个道理。不论是市集模式还是大教堂模式，都有其优缺点所在，关键是找到其适用的场景。这个观点虽然中庸，不过确实是实话。我以为，大教堂模式，适用于小的项目，或者是团队中有一个技术大牛带领，不需要过多的人来指点。而市集模式，则是那种涉及的方面比较广泛的项目，且不论如何，应该有一个几个人的团体对于项目的整体走向、代码有绝对的控制力，否则，会造成难以预料的混乱局面。
我们当前的项目可以说是类似于大教堂模式。我们的源码是完全由自己开发的，而且除了本组的人外，也并没有人其他的一些人关注这个项目，不具备市集模式的要求。
Part 4 Lost in CatB这些情况在你的团队中出现过么?
作者主要讲述了开源软件中的过度依赖问题，这个问题在实际开发中目前还没有遇到过。
Part 5 Managing the development of large software systems: concepts and techniques
我觉得瀑布模型的其核心思想是按工序将问题化简，将功能的实现与设r计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。而对于我们这种较小规模的软件开发项目，瀑布模型并无裨益。
Part 6 软件工程的方法论到底有多少用处?
由于以计算机为基础的系统在数量、复杂程度、应用方面的增长，对无处不在的计算机软件提出了更高的要求：更广，以解决层出不穷的应用问题；更精，以安全可靠地完成各项任务；更简便，以适应千家万户的使用普及。要达到这一目标，仅依靠的现有的思想方法是不够的。
在软件技术的发展道路中，方法论起着决定性的作用。软件技术人员有必要站在哲学的高度、从方法论的角度，重新审视软件开发过程中各个环节，深刻体会软件工程和方法论的联系，从而改进和发展的现有的软件工程技术，消化吸收先进的思想、方法和技术，提高软件的质量和生产率，以适应现实世界对软件产业新的要求。软件工程应运而生。为了更好地发展和改进软件工程技术，我们有必要从方法论的各个角度分析软件工程的方法、工具和过程，从而有的放矢地改进软件工程中各个过程的思想、方法、模式和规则。