大泥球（Big Ball of Mud）
1.定义
大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。
2.缺点
无法使得系统内的信息得到更好的控制和共享，使得信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。
3.原因
首先，程序员在编写程序或是系统时遇到问题后的解决方法，往往不是合适的或者最优的解法，而是方便修改的，变动最小的，这就为以后的系统架构的混乱甚至整个系统的奔溃埋下了隐患。其次，用户的需求或者编程的要求是在不断地变化的，任何一个已有的系统都随之会产生重大的变化，使得系统越来越复杂化，维护也越来越昂贵，另外编写人员的变动等等因素都会导致系统的退化，一步步变为大泥球。
4.自我分析
虽入行不深，但感觉Big Ball of Mud已深深潜入编程过程中了。比如从刚刚学习编程开始，面对一个题目，可能一下子就会有思路了，便开始着手写，写之后发现有一些情况没有考虑到，便开始修改代码中的这些情况，修改之后发现又有一些新的没有考虑到的情况，在这样程度的代码上又开始添加，其实说不定这些情况可以归为一种方法来解决，却加了许多没必要的代码。这是最初编程的一些体会。现在有了比较复杂的项目，在分析需求，设计框架时，想象按照这样写下去的代码一定很清晰规范。但是在写的过程中，就会有新的需求，或者没有考虑周全的问题，要不但是去添加修改，这样久而久之就会一个函数越来越长，代码越来越碎片化，产生所谓的大泥球，要不就要修改一开始心目中完美的框架，但是对于不同的需求又总有新的框架最完美，这样的取舍问题还有待我们团队的解决。
no silver bullet
把软件创作分为本质性工作和副属性工作，
没有银弹主张并断言在未来的十年之内，不会有任何单一的软件工程上的突破，能够让程序设计的生产力得到一个数量级的提升。这个假设在随后的解释中不再成立（在1：9的情况下）。
软件开发的困难：
本质性（essence）：软件本身在概念（conceptual）建构上存先天的困难；亦即如何从抽象性问题，发展出具体概念上的解决方案。
附属性（accident）：将概念上的构思施行于电脑上，所遭遇到的困难。
这些可以有一些对未来软件开发的认识，也许现在团队的小项目之中还没有很深的体会。
Cathedral and the Bazaar
还好这个有中文版的链接，读起来明白多了。
大教堂模式
集市模式
当然下面的一些评论也非常同意，集市的存在当然是有它的市场与价值，作者偏向于教堂的观点引起了许多人的反对，在开源如此盛行的IT行业中，”集市“带来的方便大家都有所感受，也许作者的观点也是有道理的，但总觉得代码越重用越糟糕总有些绝对，正如一条评论所说，FreeBSD的核心还是大教堂，User Land就让它是大集市好了，再过30年回头看还是这样。今天我们仍然能看到像大教堂一样典雅的架构和软件，大集市里也能找到很多优雅的小物件。有能力的人可以自己设计和装修典雅的建筑，然后自己制作或者从大集市寻找合意的配件，有不合意的改改就是。