1. 银弹
第一篇文章的作者Brooks将狼人比作软件工程中遇到的种种问题，试图论证软件开发中不存在杀死“狼人”的银弹——即以不变应万变的解决问题的通用方法。
我赞同Brooks的观点，软件工程中没有银弹。
一个软件的开发过程是复杂而多变的，而随着需求的不断变更，软件的框架也可能会发生变动，而这些是开发者很难预测的。一旦需求和当前设计发生了冲突，就意味着又要从底层开始做起。而面向对象程序设计固然降低了软件开发的复杂性，但仍然很难照顾到现实情况中无穷多的变化，科技在发展，新技术的引入在为开发人员提供一定便利的同时，也意味着会摒弃一些过时的设计。最底层的实现不会一成不变，而是顺应科技的发展不断更新，这本身也是一种需求的变化。因此我认为，只要技术在发展，软件开发就永远不会存在银弹。
2. 大泥球
文章中作者对大泥球的定义是：
A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design.
我感觉这正是我现在在写的代码。实际上在写这篇博文的时候，我刚刚搞完了编译原理的课程设计，那就是一坨将近7k行的大泥球，结构松散，调用关系异常复杂，这一点我也总结在了编译课设的报告中。
我思考了一下为什么自己的代码会变成这样，我认为主要是不明确“究竟要实现什么 样的东西”，以至于一直处于一种“不识庐山真面目”的状态，只能走一步算一步，到后来才发现自己绕了多么大的圈子。
编译器相对于软件开发的好处在于它的需求是明确的，不会变动的，然而即便如此我的代码还是一团糟。更何况在软件开发中，需求是不断变动的，开发者永远不会知道他们要开发的软件会变成什么样，想要设计一种满足所有需求变动的具有灵活性的结构是十分困难的。当需求和结构相违背，时间又很紧迫的时候，只能舍弃结构，将需求僵硬地实现出来。因此我认为，软件开发中大泥球是在所难免的，我们可以减少大泥球的数量，但是想要完全消灭大泥球是不现实的。
3. 教堂和集市
教堂开发模式在两个版本间限制了开发者的范围，而集市并没有做出限制，无论是谁都可以获取源码为项目做出贡献。我们属于集市模式，但实际上完成项目的只有我们自己。
4. Worse? Better?
软件的开发不是没有成本的，一个完美的产品背后的代价是巨大的，而Worse正式对开发成本的思考。在实际的开发中很多功能我们也没有做到完美，而是尽快仅仅确保其正确性就将其上线，在一定程度上节省了时间，却提高了功能的局限性。
5. 瀑布和敏捷开发
瀑布模型在软件工程中具有很强的局限性，对需求变动抵抗性较差，回溯修改带来的成本很高，而且只有在最后才能将产品提交给客户，一旦用户认为不满意，还要重复之前的流程，不是很灵活。
而敏捷开发面对需求变化的压力较小，相比于瀑布“笨重”的开发方式，用户可以尽早地了解到产品的变动，并给予反馈，及时修正开发的方向。开发者可以随时了解到项目紧张情况，及时作出调整以躲过可能出现的危机。
我认为敏捷开发应当注意不要过分依赖于用户，要有明确的目标，不然很容易在开发过程中迷失方向。举个不恰当的例子，如果一本小说采用敏捷写作的形式，根据读者的反馈来进行接下来情节的书写，那么这本小说也就失去了原本要表达的意义。我认为敏捷开发不应过分追求变化，因为不可能存在一个满足所有用户需求的产品，用户反馈也只能作为一个参考，敏捷的体现主要在于思路的敏捷，将实践的结果与预期进行匹配，看看是否达到了自己的目的，而不应以讨好用户作为最终目标。
我们团队项目确实是采用敏捷开发的方式，根据任务进展情况及时变更开发计划，但收集到的用户反馈较少。
6. 方法论
软件工程的方法论是前人根据实际经历总结出的经验，具有很强的参考价值，并非没有意义。只是软件工程中没有银弹，方法的选取要因地制宜，根据实际情况采取不同的策略，而不是用一套理论去抨击另一套理论。