个人阅读作业+总结
关于银弹
在这一点上，我是比较倾向于认同Frederick P. Brooks, Jr. 文章中所说的'The essence of a software entity is a construct of interlocking concepts: …… It is nonetheless highly precise and richly detailed.'也就是在软件编程中，缺乏能够直接杀死狼人那样直接而且简单的方式。而这一点的原因就在于软件本身数据和数据关系作用的多样化和非多项式的关系作用可能。
尽管另一篇文章中布拉德J.考克斯认为“掌握面向对象编程手段就意味着得到了银弹，而非一定要掌握所有问题的具体实现”，也就是面向学习过程和一致性而非面向问题的具体性和差异性。
尽管我能在一定程度上认可这种面向学习过程的观点，但是我还是更加认可没有银这种观点。众所周知，编程的基本作用也是最主要的作用应该是解决实际问题，只有比较少的部分用于理论研究（指计算机本身的研究而非利用编程完成某一方面研究的计算或者模拟），总这个比例上来说，仅仅掌握手段有时候是远远不足的，计算机编程类似于构建一个自洽的系统，各个方面相互作用从而达到目的，其内容的复杂度是np级别的，这种作用更类似与实际生态中的相互作用（尽管大多数问题的复杂度远远不及），尽管理论上有掌握宇宙中所有的因素可以推出一切发生的事件的理论，但是就复杂度而言，远远不是人类现在所能达到的（理论本身的正确性也有待商榷），编程也是这样，尽管你能通过类似的方式（面向对象）来达到目的，但是在你达到目的之前仍然不能认为你已经完成了任务，而问题本身是可变的，复杂的，所以，综上而言，在目前可以预知的未来中，“银”是不存在的。
有关大泥球
大泥球的定义是：A BIG BALL OF MUD is a casually, even haphazardly, structured system.
也就是说大泥球是一个随便的甚至是随意的结构化系统，在我们个人的理解中，基本上就是在编程之前，没有系统化的良好设计，想到哪儿写到哪儿。新的结构的出现是因为某一个阶段新的功能的需要，从而形成一个高度耦合，部分数据高度共享的系统。
大泥球出现的原因也很好理解，在有限的时间内，过分关注实现程序的功能，而忽视了架构方面的考虑，项目也很少考虑进一步维护或者更新，从而导致大泥球的出现。这种情况几乎在我们的编程作业中每每出现（个人项目），因为时间有限，只能优先实现功能，多数情况下结课后不用考虑维护和进一步增加功能。而避免出现大泥球的根本方式在于工作的延续性和问题的复杂程度，比如没有人愿意用空军系统去计算一道简单的1+1，尽管它也可以，但是并没有必要耗费如此多的资源，如果一个问题的解决是一步到位的，而且不会考虑衍生问题的出现，大泥球也未尝不可。
但是一点涉及到更加复杂，而且工作周期包含维护的时候，避免大泥球，系统化就变得更加必要了。
有关大教堂和集市
我们团队的开发应该更倾向于大教堂的方式，就是代码基本上由团队的人各自完成自己的部分，自己负责部分的代码由自己进行完成和修正。最后加上测试人员的测试来保证代码的正确性。
原因也很简单，因为时间有限，大家在学习阶段只学习了分工部分的语言和环境，在开发过程中因而只能对自己部分的代码有一个比较深入的了解。因而代码的分享度不是特别高，不是集市型。
有关迷失
团队没有出现那种情况，因为在初期就将前后端的框架定了下来，而且网页开发已经是一个相对比较成熟的问题，所以我们所用到的软件包基本上都在计划之内，而且比较精简，未出现最后各种重用和各种依赖交错的情况，总体比较良好。
有关worse is better
我不认为worse is better，即不认可可以为了完整性来可以牺牲简单性和正确性。因为无论什么软件，它的开发最终是面向用户的（面向使用），完整性固然很好，但是这个完整性是对于开发者的完整性，而非使用者的完整性，对于使用者0.1%可能使用的功能，要求其因为牺牲简单性而额外付出的10%的的资源是绝对不合理的，追求一切的完整其实也就意味着庞大和资源的浪费。
因而，站在这个角度来说我不认为worse is better。
有关瀑布模型
瀑布模型的核心思想接近流水线，按照工序将问题分成若干步骤，基本分为系统需求、软件需求、分析、程序设计、编码、测试、运行七个步骤，这种设计的优点在于可以就每个节点进行检查，而且完成前面的步骤后可以直接进行后面的步骤，不需要继续考虑前面的步骤。
但是它的缺陷更加突出，“牵一发而动全身”，任何一个步骤发生改变，可能影响它后面所有步骤，如果经常变动，维护的成本难以想象。其次，只有进行到后面的步骤才能知道项目的效果如何。这在软件工程中无法接受，因为这意味着如果效果不满意，几乎需要重新开始很多步骤，极大增加了开发和维护成本。
关于敏捷
敏捷开发的理念是： 个人和互动高于流程和工具；工作软件高于理解文档；客户协作高于合同协商；变化响应高于计划遵循。
也就是说大家更加倾向于根据实际情况的变化来实时进行调整，而不是按照事先规定的要求或者文档死板地进行执行，同时关注客户需求多于合同的要求，总体而言是一种灵活的，不断适应现实的开发方式。
这种方式能够让最终的产品更加优质而且符合客户的要求，其实是一种很好的开发方式，但是就个人理解，我觉得敏捷开发对于个人的要求更高，因为就一个人而言，如果他对文档的要求根据自己所学进行了调整，很难讲结果会变得更好或者更坏（应该是based on他的能力，因为自己的观点不一定正确），所以敏捷开发应该更加适应高水准而且最好有一个技术总监的团队。
关于方法论
这部分有比较大的争论：究竟软件开发中的一些方法是否真的有效，阶段管理是否真的有效，结对编程是否可以有效替代代码审查。Jez Humble认为减少周期时间并增加反馈。是真正可以提升软件价值的评判标准。
而对于方法论而言，很难验证其正确性而发挥作用的大小，Jez Humble主要认为是其效果反馈过长而且无法控制其他变量，因为个人技能和性格也是很重要的影响因素。正如我在上面第一题的“银”中所说的：软件开发是一个很复杂的多因素相互影响的体系，很难线性分析得出一个确定的结果，所以我更倾向于敏捷开发类的思维（不止针对程序，也针对团队管理），不断调整方式，或许比严格遵循某些方法论更加有效。