个人阅读作业+总结
关于银弹
关于银弹我比较认同Frederick P. Brooks, Jr.的观点，软件开发过程中没有银弹。文章中提到
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
作者认为软件工程的发展是多元的，有其复杂性，可变性，不可见性等特性。软件工程是一门解决实际问题的工程性学科，而包含比较少的理论研究。从开发的角度，需要根据需求的差别，实现方式的差别，平台的差别以及最终效果与维护的差别实现一套特有的设计实现方案。如果真有一颗银弹能够覆盖面积如此广泛的设计，那它本身体系也将十分庞大而不能称其为银弹。如此庞大的“银弹”只会使开发过程变得繁复僵化。
软件开发过程中最好的实现途径就是从实际需求出发，设计出优秀的方案，开发人员根据设计完成开发，管理人员对开发过程和成果进行良好管理。
关于大泥球
大泥球的定义是A BIG BALL OF MUD is a casually, even haphazardly, structured system.
大泥球是指一个设计阶段没有清晰的设计就动手实现，导致实现过程随意，没有工程化结构的系统。这将导致模块间的高度耦合，部分数据高度共享，使得系统的结构复杂，维护和功能扩展困难。在一次完成，不需扩展的简单需求上，如此设计尚且可行。但若是在庞大的系统设计中未经周全设计就动手实现，则会使整个工程变成一个大泥球。
关于集市与大教堂
- 教堂模式：软件源代码在软件发行时一并公开，但在中间过程中源代码是由独有的工程师团队维护的。
- 集市模式：代码全程公开，即使是在开发过程中也如是。
我们团队代码在开发过程中一直在GitHub公开，但并没有受此影响。因此属于教堂模式开发流程。
我们团队没有出现迷失的现象。开发初期我们就定下了主流框架，软件包完善且稳定，没有出现重用和各种依赖交错的情况。
有关worse is better
我不认为可以为了完整性牺牲简单性和正确性。软件面向的是用户，用户评价一款软件是从体验和正确性的角度去看，而不是去用工程思想分析其完整性。实现功能完整性的同时，应当考虑花费的成本和预期的收益。因此我不认同worse is better。
关于瀑布模型与敏捷开发
瀑布模型核心思想是流水线作业，分为系统需求、软件需求、分析、程序设计、编码、测试、运行七个步骤，是一个完整的工程开发流程。
而敏捷开发的理念是迭代，每一次迭代实现功能的提升。而提升的方向是上一轮迭代成果的反馈。
两类模型对比，瀑布模型体现了软件开发的完整性，但没有考虑到开发时的市场变化。敏捷开发则注重市场的变化，在迭代的过程中满足用户需求和时代要求。但对设计和实现提出了更高的要求。
关于方法论
软件开发是一个十分复杂的问题，针对不同的开发需求又有不同的实现方案。在之前有关银弹的分析中我们就得出结论：没有银弹。此处的方法论也会是一个高度抽象的方法论，那么认为方法论有效与否还在看我们怎样将这一抽象具体化。而具体化的过程就是我们对需求的理解过程和设计过程。最终软件开发的结果也并不完全是方法论的结果，而是诸多因素的共同影响。因此单纯谈抽象的方法论是没有实际意义的。真正有意义的是在开发过程中思考与设计，而不是教条式地生搬硬套方法论。