银弹
在 No Silver Bullet 中，作者谈到，软件工程中的一些问题就像狼人一样，起初是直接且无害的，但却很有可能演变成巨大的麻烦，因此人们一直在渴求可以控制住这些问题的普遍的“银弹”，可惜，数十年来却没有任何有效的改进，连一个领域的都没有。作者因此认为，没有就是没有，是因为其本身的难度所致，就像 NPC 问题一样。其难度具体体现在复杂性、一致性、可变性和不可见性上。
作者同时分析了一些“可能”成为银弹的技术，但是详加考察下却不见曙光。
而在 There is a Silver Bullet 中，作者认为模块化，可重用组件会带来银弹，这将使生产效率大大增加，甚至犹如工业革命一般。
我个人倾向于没有银弹。软件工程除了是一个技术问题之外，还涉及到人与人之间的合作与竞争。有的时候人之间合的来，即使技术没有那么好，也可以事半功倍，相反，即使都是高手，互相之间也可能因为配合原因导致无法发挥出原本的水平，此处仅是一例，只是说明有些重要问题不是单纯依靠技术就能解决的，因此没有所谓万能银弹。
大泥球
在文中作者指出，大泥球是那些只是为了方便而不是出于设计的代码。
在项目中，大泥球其实是存在的。在物理实验网站中，大泥球体现在几处
- 若干个版本交织在一起，但很多代码并没有什么用处。整理之后发现其实真正的代码并没有多少，但是初看之下一团乱麻难以下手。
- 大概是为了调试方便，html 和 CSS 分离的并不好，混杂在一起，导致前端逻辑十分混乱，无法直观得出页面究竟想表达什么。
解决这个问题的办法其实也比较容易。对于第一点，利用好版本控制系统，让旧代码分散在版本控制系统中即可。对于第二点，只需要每次都较好的遵守代码规范问题自然就不存在了。
大教堂与集市
大教堂指由一个团队专门负责，并定期发布，同时公布源代码。集市模式指开发过程中便公开源代码，以便让错误无所遁形。
我们的团队采取的是大教堂模式。由于无论是团队规模还是软件规模都比较小，也没有出现 Lost in CatB 中提到的现象。
我个人比较喜欢集市模式，这样可以尽可能的吸取一些宝贵意见。在有良好的代码审查，以及时常回顾设计架构的机制时，个人认为集市模式也不会成为一团乱麻。
Worse? Better?
“Worse is better” 的哲学强调简单就是王道，为了简单，会自己考虑正确性和良好的设计，因为没有正确性和良好的设计，实现根本不会简单。
这个哲学颇有一些诡辩的味道，对于经验丰富的人来说可能更加实用一些，因为他们对于良好的设计已经有了一定的感觉，在实现的时候为了简洁会自觉的往那个方向上靠。但是对于水平不那么高或者大局观不太强的人来说可能就不是很适用了，在缺乏指导的情况下，很有可能给项目埋下一个又一个大泥球。
瀑布
瀑布模型比较慎重稳健，基本上是按照一步一个脚印的节奏向前推进的，但这同时也意味着在开发速度上很难与敏捷模式相比，否则在质量上会打折扣。这样做出来的产品个人认为虽然难以得到及时的用户反馈，但是在代码质量上每一步都是有保障的，是其优势所在。
敏捷
敏捷开发是一个很好的理念，不过在 Agile Method 中作者也提到，需要“负责任的专业人员”才能保证敏捷的效果。诚如敏捷已死中所说，敏捷在很多时候已经成为一种卖点，而非一种实用的方法。就像我在知乎看到的一篇文章中说“人工智能在外国是个科技概念，而在中国是个商业概念”，敏捷也有这种转变的倾向。
其实敏捷本身无非好坏，只是在不同的人手中会有不同的发挥、不同的作用而已。我个人很赞同需要“负责任的专业人员”的观点，因为个人实力是团队实力的基石，没有这个基础，依据敏捷的方法将任务分拆并期待按期交付并不现实。
争论
Why Software Development Methodologies Sucks 的作者和我的观点比较像：本身的实力永远是最重要的，方法论只是一种引导实力尽可能完美发挥的途径。
没有实力空谈方法，最终只会陷入：为什么我一一照做了，但却还是做不出东西/做出烂东西的疑问。
当然这也并不是说方法论不重要，但是比起实力的变化幅度来说，方法论所起到的加成并不是那么显著。总而言之，实力才是硬道理。