关于Silver Bullet：
*s在“No Silver Bullet”主张并断言在未来的十年之内（从1986年文章发表后开始计算），不会有任何单一的软件工程上的突破，能够让程序设计的生产力得到一个数量级的提升。软件开发困难分为本质性(essence)和附属性(accident),*s认为，附加性的困难会随着工具的改善而逐渐淡化，反而是本质性的困难最难以解决，因为大部分的活动是发生在人们的脑海里，缺乏有效的辅助工具，这是造成本质性困难的原因。而附属性的困难可以由过去的突破解决，一些高级语言和开发环境的发展使得附属性的困难大大降低。
但就我个人浅薄的见识来说，我觉得这种“不会有任何单一的软件工程上的突破”的说法过于悲观和绝对了，好吧，这其实只是我对于这个瞬息万变的世界的“变化”的肯定，只有“变化”是不会变的，这种悲观的预测在我生活的信息化时代是不可想象的，不过这或许没有什么关系，我没有生活在1986年我也不甚了解那个时候的信息技术是怎样的。不过我只从看文章的角度来说比较赞同“There is a silver bullet”，查阅相关资料时发现Caper Jones曾提出的一个见解：
“〈没有银弹〉就如同大部分的论文一般，都把焦点集中在生产力，也就是软件每单位的输入成本能得到多少输出效果。Jones则表示：“把重点放在品质上，生产力将随之而来。”他认为，只要是成本过高和时程落后的专案，都耗费了非常多的额外时间和工作在查找并修正规格、设计、实现中的错误。Jones并提出数据佐证，缺乏有系统的品质控制与发生时程落后的灾难，这两者之间有强烈的相关性。
Caper Jones相信，两份同等的Cobol程序分别花10年编写，但其中一份使用结构化的方法，另一份则否，那么所得到的效果将相差3倍。”
我觉得Jones讲的比较有道理，但是由于我自身对于软件工程的了解和实践很少，也说不上来一些理由啥的，我只能表明一下我赞同的方面。
关于big ball of mud:
对于软件开发过程中的大泥球我真是感同深受，随意化的杂乱和结构化的系统，只是代码的堆砌和拼凑，导致很多错误和缺陷。在上一次的结对编程项目中，对于电梯的调度算法的改进确确实实让我们的工程成了一个大泥球，遇到问题不是用最合适或最优的解法，而是更方便修改的，没有对整个工程做一个好的规划，需要哪就改哪，整个工程是碎片式增长起来的，缺少前期的设计就直接做修改，以至于对于相同的需求都不能完全满足，也因为碎片式的结构无法完全的找出bug，彻彻底底成了一个无法改进也回不到原点的垃圾，最后我们还是放弃了做过修改的代码，重新设计规划修改了源代码。那一次的经历真是刻骨铭心，连续几天的熬夜做出了没用的东西也真让人挫败，也让我意识到做工程前期设计和考虑全局用最合适的解法修改是多么重要的事情。
关于Cathedral and the Bazaar：
Cathedral model：每个版本开发有专属团队控管
Bazaar model：放在因特网上供人检视及开发
我们团队是做学霸网站的团队，采用的是Cathedral model。
关于lost in catB：
代码频繁的被重用但是没有经过适当的修改，使得重用部分有各种冗余也可能有缺陷，并不是最适合工程的代码，如今信息开放的时代，各种代码重用滥用屡见不鲜，但很多并没有经过修改，而是“拿过来就用”，B用A，C用B，如此循环下去代码质量会越来越差。
就像这篇文章中提到的“学会计算机编程很容易，就像学会用钉子把两块木板钉到一起一样简单”，“但问题是——打个不恰当的比方，市场对“钉在一起的两块木板”的需求，除了“自豪的爷爷”的那点天伦之乐以外，真的是太小了。而且，由此再进一步学习钉椅子或做碗橱，都需要天分、实践和训练。我们增长的这99倍恰恰都来自那些既没有实践经验，又没有受过良好训练的人。” 模块化和代码重用都是好主意，但是现实是“各种包把Web搞得一团糟， 随便依赖，互相纠缠，代码越重用，浪费越严重。”
作者批判了现在的bazaar model，他指出了我对于软件工程的印象比较倾向于Cathedral model的一方面：Bazaar model可以供很多人开发，而你去找相关功能时并不知道哪一部分才是你真正需要的，就好像我遗失了一朵花在路上，回去找时发现那里已经变成花园了，我不知道哪一朵是我要花，可能这个例子举的并不好，但是Bazaar总给我一种杂乱的感觉。但Bazaar相比于Cathedral是有它的优势的，Given enough eyeballs, all bugs are shallow。很显然Bazaar在这方面是Cathedral无法相比的。
关于worse is better：
我始终记得小时候看的一本儿童文学里的“她的缺点就是她没有缺点”，“精致完美并不代表一切”。WIB提出的总的思想应该是“Simple is Best”。(原谅我很多地方用了“应该”之类的词，因为我也不确定对于作者的思想的理解对不对)比较simple和perfect，simple不一定不perfect，而软件工程中的perfect确不是简单的，考虑到各个方面的因素，将产品做的尽善尽美肯定是耗时耗力的，而Richard Gabriel提出的WIB可以快速推出软件应用，持续完善易推广并且拥有简洁的界面，相比于那些精致完美的工程(耗时长，不能快速更新满足客户源源不断的需求)来说是在现代软件工程领域比较受客户喜爱的，至少我比较喜欢。
关于瀑布模型：
瀑布模型将软件生命周期分成了六个阶段：制定计划，需求分析，软件设计，程序编写，软件测试和运行维护。它规定了软件开发的顺序自上而下、相互衔接的固定次序，如果有信息未被覆盖或者发现了问题则返回上一阶段查找问题并进行适当的修改。
优点是：每个阶段有自己的目标，不需要再关注前面的阶段，按部就班来做很省时省力；缺点是：各个阶段之间很少有反馈，只有在整个项目后期才能看得到结果，各个阶段都有deadline(这个点简直神烦，deadline什么的最讨厌了)，对于经常变化的项目瀑布模型毫无作用。
关于敏捷开发我们团队的思想和做法：
在12条敏捷原则里面我们至少做到了如下几条：
1，我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
学霸网站基础的雏形已经有了，基本功能是用的，只是部分更高级的功能不能更好的满足用户的需求。
2，即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3，围绕被激励起来的人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
4，在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
5，敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
团队PM会持续的督促开发者按时完成自己的工作。
6，每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
定时会议让大家指出工作上的不足，相应的进行调整。
经过几周的开发，自己的心得总结：
首先是了解自己拿到的需求是什么，仔细思考后明确在现有的代码基础上如何进行最适合的改动才能满足需求。而不是随意的在改动最少的地方最方便改动的地方修改代码，那样会使得整个工程代码呈碎片式的增长，容易出现一次性代码的情况。现在要做的就是磨练自己，多思考，增加开发的经验和技巧，不让手中的程序成为一个大泥球。
在团队协作方面，我觉得最重要的是沟通，面对面交流是最具有效果并且富有效率的传递信息的方法，所以在开发过程中一定要时常保持和队友的交流。并且工作中要保持一个长期恒定的开发速度，不能拖不能懒，因为不是一个人的项目而是一个团队的项目，对自己的放纵就是对团队的不负责任，不负责任的人是不会有好结果的。
ps：文章中可能引用到别的作者的观点，鸣谢且侵删歉！