我的阅读&我的总结

助教推荐的这些文章都是软件工程的经典之做，读完以后对这学期的软工学习有了更深的认识。才以为学习软件工程以前写的都不算是软件工程，只是些程序。真正的软件工程历史悠久，其对程序员带来的痛苦伴随着不少代人，许多经典的软件工程著做和讨论都是几十年前就完成的，虽然软件行业突飞猛进，但其中的哲学和根本却从未改变。

软件工程中到底有没有银弹呢？

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"等屏蔽词汇，但做者勇敢地捍卫了他所推崇的敏捷开发，一条一条地反驳另外一篇批评敏捷的文章。

方法论

我以为软件工程的方法论对于软件开发的发展是很重要的。但在实际项目中，团队没必要拘泥于具体的方法论，不然可能会陷入无休止的意识形态之争；而是要具体项目、具体团队，具体分析。