no silver bullet：
开篇就做了一个很有趣的比喻，说软件工程就像“狼人”，因为一些缺陷会在某个不确定的时候变成一个可怕的“怪兽”。由此，引发了一个疑问，软件工程是否有捷径能够让软件的花销像计算机硬件那样可控的减少？
然而，遗憾的是，作者证明，不论从技术上还是管理上，都没有这样的捷径。但同时，这并不意味着悲观，也许没有康庄大道，但是逐步的，坚持不懈的改进是可以创造一条路的。
到底有什么本质上的困难导致无法找到这样的捷径呢？主要是这四个现代软件系统的本质因素： 复杂性(complexity), 一致性(conformity), 易变性(changeability), and 不可见性(invisibility)。
复杂性体现在，软件实体比其他人造的结构更为复杂，并且不知是数量上，在实体之间的关系上也常常呈现非线性。这种技术上的复杂性也蔓延到了管理上，很难去找到并控制未知结局，大量的学习理解让人员流动也成为了灾难；
一致性体现在设计人员的不同，物理等自然学科尽管会面临困境，但原理是一致的，大家有迹可循。而软件工程仅仅因为经手的人不同，接口设计不同，导致复杂性，这种复杂性也不能被重新设计软件而消除；
易变性在于软件系统是体现在功能上的，容易受人们想法的影响，一旦人们感觉这个功能可以拓展，就必须满足这种压力；
不可见性在于没有一个几何学一样只管的方法展示想法，进行交流。尽管根据使用情况不同，有很多种图，但这些图算不上多直观。想让概念容易理解，只能消减一些联系直到图出现分层的等级。
前人曾在很多重大问题上有突破，但都是偶然性问题，本质上的难题仍然有着天然的局限性。
高级语言，都说提高了程序的简洁和可读性，但是作者认为这同时提高了用户掌握工具的难度，因为要考虑各种复杂的数据结构。还有分时、统一的编程环境等突破。不过，有些突破的确带给我们希望去找到捷径。比如Ada，面向对象编程，人工智能，专家系统，自动编程，图形化编程，智能终端等等，但是各自的局限性仍然不能给我们的编程带来魔法般的增强作用。
我在面向对象编程上有点体会，对各个实体的抽象和联系让编程变得简单，但是不能解决之前所说的复杂性和不可见性，因为实体的设计本身就是一个内在的难题。
文章转而说起了一些有希望的策略，但都倾向于管理方面，比如说用买来代替造，也就是说买别人的优秀程序减少自己开发的周期，还有充分发挥优秀设计员的方法等等。
感觉这篇文章看下来，就是一个意思，本质上的困难无法解决，技术上只能减少偶然困难，管理上可以带来一些希望云云，比较泛泛，也许是自己理解能力有限吧。
the big ball of mud
“大泥球”是指杂乱的，蔓延的，意大利面条式的代码。
这种代码结构散漫，对于软件开发来说应该避免，但是在软在开发中却常常使用，有这些因素在限制开发：时间，没有足够时间进行长远的架构；开销，进行架构的开销太大；程序员，经验和技能限制；可见性，关注功能实现，而没人关心内里是什么样的；复杂，易变性，规模庞大。
在企业中，为了生存必须让软件运行并按时发布，时间和花销上的限制使得程序员不得不首先关注功能的实现，然后再是架构和表现。我在pair work里很有体会，由于计划失当，留给pair work的时间太少，在最后根本就是为了跑起来狂码代码，丝毫没心情去考虑代码结构，因此写出来的东西简直惨不忍睹，出现了很多copy/past的情况，改的过程也就很痛苦。
大泥球的产生原因除了这个客观因素之外，就是程序员的修炼了，尽早分析需求，进行前期设计和架构，有意识的减少copy/past，减少一次性代码和代码碎片，除了让程序跑起来注意考虑其性能和可维护性等等。其实，这些说着容易做着难，关键在于一个管理者和程序员的心态，不能急功近利，长远考虑和架构虽然在短期花销大，但是维护的代价减少、系统稳定性增强就是长远利益。
The Cathedral and the Bazaar
Eric Raymond的这篇文章很有名，以前听过。他以大教堂和集市隐喻软件开发的两种方法，大教堂是封闭的、成本高的，长周期的，而集市是开放的，成本低的，周期短的。他提出这个是因为一个本科生，创造了linux的神话，这不禁让人反思。可不可以从一个集市建成一座教堂呢？他认为，只要具备几个条件这个是可发生的，比如，项目可以很粗糙、有bug、不完整，但是一定要能运行；必须要展示一个前景，让潜在合作开发者能预见到不久的将来这个项目可以变得很可观......最后他表示了他的态度，未来一定属于集市开发，因为集市开发投入的人才将以数量级数增长，是封闭教堂无法比拟的。
我们团队的项目使用的cocos2d就是一个开源的2D游戏开发平台，非常好用，功能强大。但是有一个疑问就是，一旦开源怎么盈利呢？