关于“银弹”
Brooks 在 No Silver Bullet 一文中开篇便提到 “There is no silver bullet”，并且从软件工程的本质上解释了为什么一个能够解决关键问题的“武器”在软件工程上不存在（软件工程的 Complexity;Conformity;Changeability;Invisibility）。之后作者又从这么多年软件工程的发展来解释为什么没有“银弹”，无论是高抽象的语言、合理的构建方法、面向对象的思想等等。这些都不能解决软件工程带来的根本性问题。我认为，作者这么说是有道理的。
而在另一篇关于“银弹”的文章中，作者以思辨的角度从历史和方法论的观点来对软件工程中是否有银弹做了分析：
面向对象的编程思想提供了一种编写复杂系统的方法（从小的组件开始写起（造轮子））；可复用的组件以及硬件的更新都推动了软件工程的发展。软件工程发展到了现在，确实还有问题需要解决，但是正是这些问题能够不断推动软件工程的发展。
所以，就从现在来说，软件工程中的“银弹”还未出现，但是随着方法、科技的不断进步，或许之后会产生。
关于“大泥球”
大泥球的定义：
在软件工程的整个结构方面，大泥球是这样被定义的：A BIG BALL OF MUD is a casually, even haphazardly, structured system.
在具体实现上面，大泥球的定义是这样的：A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.
在我们的项目中，有些地方还是有 大泥球 存在的。像是最开始我们定义了一些数据结构用来存放会用到的一些“硬编码”，但是到了后来，为了方便，用的时候直接把“硬编码”写在代码里了，代码看起来极不规整（后期有调整）。
避免大泥球的方法：
- 如果不能减少混乱，尽可能隐藏混乱。
- 如果系统bug太多，已经没有了修复的意义，这时候，要尽快的抛弃它。
- 系统出现问题的时候，不要想着从头到尾地全部检查所有代码，应该尽可能的想办法让整个系统开始运行。
- 在有限的时间中需要一个高质量的软件，首先关注的应该是功能，实现了功能之后再考虑结构上的优化和表现形式。
- 总而言之，在设计开始，尽可能地做出一个好的设计方案，实现的时候，写高质量的代码，发现问题，要敢破敢立。
- 代码的质量要高，减少THROWAWAY CODE。遇到问题的时候，不能只是想简单地写出代码解决问题，还要尽可能地写出一份高质量的代码。
关于大教堂和集市
大教堂：一个软件的一个版本只能被一组开发人员所有。
集市：将代码公诸于众，大家一起来测试，实验，开发。
我们的开发方式是大教堂。
对于迷失的情况，我们没有出现，因为我们的PM在嵌入代码的时候会对代码进行审查，而且，我们后面也进行了一次代码调整（将不符合代码规范的代码进行修改），软件依赖不是特别复杂。
Worse?Better?
Worse is Better 在文章中被作者多次提到，并强调这是一种设计哲学。这种哲学的特点是更看重结果，宁肯舍弃一些在细节上的精细处理也要的得到一个正确的结果
工程是一个注重结果的领域，能够快速高效得到正确结果，就是一种好的方法。
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn't.
就像上述所讲，“完全正确的并不一定是好的”，在软件工程中，这句话或许改为这样理解：“能够正确完整功能并且能够方便快速的实现就是好的”。在AI软件中，C语言当然能够正确的实现想要的功能，但是C语言更加底层一些，用起来也就相对繁琐；相比于C语言，其他语言也能够正确实现功能，像python之类的语言能够更快的实现，所以，这种情况或许是python略胜一筹。软件工程是一个整体，正确性和实现花费是都要考虑在内的。
瀑布模型
瀑布模型的核心思想是按工序将问题化简，将功能的实现和设计分开。将软件生命周期划分为为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序。
特点：
- 为项目提供了按阶段划分的检查点；
- 前一阶段完成后，只需要关注后续阶段；
- 每个阶段之间反馈很少；
- 在项目生命周期后期才能看到结果；
- 通过许多强制日期和里程碑来跟踪每个阶段。
敏捷开发
- 在我们项目的开发过程中，我们每天都有“每日立会”，所有人员聚到一起花一个很短的时间讨论交流昨天的工作，并且讨论之后怎么做。这和敏捷开发中的管理方式和自适应观点相一致。项目进行了两次迭代，其中对用户的需求又进行了一次分析，通过这样再一次获取可能改变了的用户需求，进一步修改项目。
- 在“敏捷已死”的文章中，作者说此时由“敏捷开发”导出的一系列附加产品已经覆盖了“敏捷开发”的真正含义，而敏捷开发存在的意义就是为了开发人员更快地实践，“敏捷开发”这样商业化的发展已经让它失去了原有的意义。在“敏捷未死”的文章中，作者用针对对敏捷开发的误解做出一系列“反击”，强调“敏捷开发”还是在IT、软件开发中起到了很大作用的。
方法论
文章中提到，软件项目是复杂的，典型的软件项目往往没有规律和可预测环境。因此，在开发软件的过程中，如果不能得到实际的用户反馈和有效的开发方式，很难做出一个好的软件。对于在软件开发领域中提出的各种方法，像是瀑布模型、敏捷开发方法，这些只是一些能够帮助我们创造出好的软件的途径，就像作者所说：
it’s not possible to take seriously any of the general claims as to whether agile development practices are better than waterfall ones, or vice-versa.
所以，盲目使用这些方法并不一定能够带来好的结果。因此，正如作者所说，我们需要的，是缩短开发周期和提升反馈效率，根据具体情况选择合适的方法，并且尽可能发挥人的能动性，在软件开发的过程中不断快速学习，让整个团队变得更好。
来源：https://www.cnblogs.com/StonesA/p/8268939.html