助教推荐的这些文章都是软件工程的经典之作，读完之后对这学期的软工学习有了更深的认识。才觉得学习软件工程之前写的都不算是软件工程，只是些程序。真正的软件工程历史悠久，其对程序员带来的痛苦伴随着很多代人，许多经典的软件工程著作和讨论都是几十年前就完成的，虽然软件行业日新月异，但其中的哲学和根本却从未改变。
软件工程中到底有没有银弹呢？
No Silver Bullet --Essence andAccident in Software Engineering
在西方文化中，狼人是一种十分可怕的怪物。其最恐怖的地方在于，他们会忽然从十分熟悉的人变为恶魔。就像中国的黑狗血可以制服妖怪一样，狼人的克星是银弹(Silver Bullets)。作者用狼人来比喻软件工程，银弹以比喻可以克服软件工程中困难的通用方法。人们渴望得到银弹，但就像题目所直截了当地描绘的那样，作者认为并不存在这种通用方法。
首先，从软件开发近10年的历史（文章写于1986年）上来看，不存在一种单独的开发、技术或管理技巧可以完全保证效率、可靠性、简易性的提高。
其次，软件开发中存在一些本质的困难。
- 硬件速度的增加相对软件开发的进步是十分快的。
- 软件本身内在的困难（复杂性、整合性、不断变化性、不可见性）和不断出现的意外。
在解决这些问题的过程中，工程师们取得了一系列突破：高级程序设计语言、时间共享、统一的编程环境。Brooks还提出了一些可能银弹：高级程序设计语言、面向对象编程、甚至是现在火爆的人工智能和其中的专家系统、自动化编程等，但这些候选的银弹都有不足之处，有些在当时甚至现在都不现实。最后，Brooks提出在目前没有所谓银弹的情况下，细化需求、快速原型设计、优秀的设计人员是软件工程的解决方案。
There is a Silver Bullet
这篇文章（2004年）是对上一篇文章No Silver Bullet的补充和反驳。开始的引用部分，作者引用了上一篇文章作者Brooks的话，提出狼人和银弹的概念。首先，作者回顾了工业的发展史，尤其是最近的信息革命的诞生。之后，作者介绍了从软件工程诞生起的一系列讨论和成果，包括我正在读的《人月神话》和同作者Fred Brooks的文章“No Silver Bullet: Essence and Accidents of Software Engineering"(也就是上一篇文章)。就Brooks没有银弹的论点进行反驳。
Cox认为，构建易用和可服用的组件是解决软件工程问题的关键，更高级的抽象，也就是面向对象程序设计是所谓的银弹。
根据本文作者Brad J. Cox的履历，他是“Object-Oriented Programming: An Evolutionary Approach“的作者，也是Objective-C系统构建环境的创造者。不难理解他对面向对象编程的熟悉和推崇，认为面向对象就是软件工程中的银弹也就可以理解了。
Big Ball of Mud
所谓的大泥球是指没有清晰结构的系统。在实际开发中，我们常常为了赶做feature，在没有充分设计和调研的情况下写出大量快速但不可复用的代码。随着feature越做越多，刚开始设计不足的问题就凸显出来。代码中的垃圾越来越多，整个项目变得难以维护和进一步开发。
CatB - Cathedral and the Bazaar
这本书（最开始是一篇论文，之后书写成书）是Eric S. Raymond根据他对Linux内核的观察和管理开源项目的经验撰写而成的。在书中，Raymond提出了自由软件开发的2种模型。教堂模型和即使模型。教堂模型指只有release版的源码公开，而集市模型中，所有源码公开，外界可以看到开发的全过程。Raymond相比之下更加推崇集市模型。他认为，更多的公开会暴露更多的bugs。
我们的团队采用的是集市模型，即所有的开发过程都可以在GitHub上看到。
Lost in CatB
文中作者举了2个例子。一个是关于十年前（2000年前后）他亲身经历的.COM的火爆，另外一个是作者在使用FreeBSD过程中，由于软件的依赖和代码的复用，而迷失在集市中。
现在Web技术重新火爆起来，NodeJS、Angular、Vue、TypeScript等各种技术层出不穷，前端成为一个技术更新飞快的领域，但在很多时候缺乏一个标准，这已经被所有人包括众多前端工程师所吐槽。我之前因为实习的需要而接触过前端，使用Angular框架构建一个dashboard以向用户显示必要的信息。追随最新的概念和技术，我构建了一个Single-page Application，使用Webpack等工具链进行打包......最后完成这个项目时，node_modules里已经有多达200M的依赖包，project.json里面的构建依赖和开发依赖也有近百个，每个依赖包都有3级版本号，有时候更改一个最小的版本号都会导致构建失败。很多包的作用我到最后也不清楚具体作用，有些究竟有没有用我也不清楚。因为开发过程中有弃用的代码，然而它们的依赖却留了下来。依赖包的递归依赖更是数不胜数。两个包可能会依赖另外一个包，但它们需要的版本号可能不同！虽然最后勉强完成了这个项目，但开发中的痛苦令我对前端敬而远之。软件工程的彼得定律在这里也可以充分体现。
The Rise of "Worse is Better"
坏即是好。这样说其实有一定的误导性，矫枉过正了，它只是相比较完美的设计来说的。“坏即是好”的哲学是：
- 简易性
- 正确性
- 一致性
- 完整性
Unix和C语言的设计就是典型的例子。尤其是Unix，有了设计完美但失败的Multics的衬托，坏即是好的成功也就更加明显了。在计算机网络中，TCP/IP的成功和ISO 7层模型的失败也是这样的例子。
“坏既是好”告诉我们不要追求完美无缺，而是强调简易、正确、一致、完整的重要性。
Is Worse Really Better
这篇文章和上一篇文章的作者相同，都是Richard P. Gabriel。Gabriel在这篇文章中并不是完全否定了他之前的观点，而是对之前的文章进行了反思，回答了一些外界关于“Worse is Better”的争论，重申了坏即是好的4个哲学。
瀑布模型
最早学习瀑布模型是在“经济管理”课上，在生产领域，将生产过程用瀑布模型安排是一种比较普遍的做法。在软件工程中，瀑布模型具体为“"系统需求-->软件需求-->分析-->程序设计-->编码-->测试-->运行"。瀑布模型是一种比较传统的模型，有它自己的缺点。针对这些缺点，软件工程师们又提出了其它的一些模型，如大小瀑布模型。
我们在实际开发中采用的就是瀑布模型。原因在于它的简单清晰，对于我们的项目也已经足够了。
敏捷
我们团队的开发流程十分敏捷。
Alpha版本快速做出一个可玩版本，既可以满足用户需求，观察用户反馈，又可以让团队成员熟悉开发和团队，为beta阶段的完全重构打好基础。
每日立会，控制在15分钟，讨论工作进度和明日安排。
经常结对编程甚至集体编程。
敏捷已死
作者作为提出敏捷开发宣言（Manifesto of Agile Software Development）的核心成员之一，高调地宣称敏捷已死，其实际上是为了让敏捷重新恢复初心，即敏捷的核心价值观：
- 个人和互动高于流程和工具
- 工作软件高于理解文档
- 客户协作高于合同协商
- 变化响应高于计划遵循
由于敏捷这个概念在软件开发中越来越火，敏捷这个词已经成为一个商家的噱头，甚至很多团队为了敏捷而敏捷。就像作者说的那样这个滥用的词已变得不再有意义，因为它转换成了一个品牌。一旦敏捷一词变得毫无意义，开发人员就不能再认为它是一个有价值的实践。回归本质才是现在敏捷的追随者应该做的。敏捷已死，放弃“敏捷”这个词，转而坚持敏捷的核心价值观，用另外的词来表达这种价值，才能保护我们的付出。
敏捷未死
这篇文章话糙理不糙，虽然充满了许多“fucking", "sucks"等屏蔽词汇，但作者勇敢地捍卫了他所推崇的敏捷开发，一条一条地反驳另一篇批评敏捷的文章。
方法论
我觉得软件工程的方法论对于软件开发的发展是很重要的。但在实际项目中，团队不必拘泥于具体的方法论，否则可能会陷入无休止的意识形态之争；而是要具体项目、具体团队，具体分析。