《No Silver Bullet: Essence and Accidents of Software Engineering》
Frederick P. *s, Jr.
论述中强调由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。布鲁克斯认为，附加性的困难（Accidental Difficulties）会随着工具的改善而逐渐淡化，反而是本质性的困难（Essential Difficulties）最难以解决，因为大部分的活动是发生在人们的脑海里，缺乏有效的辅助工具。过去的突破解决了附属性的困难方法：高级语言、分时技术、统一的开发环境。而现在我们寻找的银弹很可能是：Ada和其他高级语言的进展、面向对象程序设计、人工智能、专家系统、自动化程序设计、可视化或图形化程序设计、软件的验证、环境与工具、工作站。
疑问：本质困难是否可以通过解决附加困难得到解决？或是将所有的附属性工作降到零，也无法将整个开发工作的轻松程度提升一个数量级？
心得：即使没有银弹，降低软件开发中的附属性工作会提高开发效率。
《Managing the development of large software systems: concepts and techniques》
1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
瀑布模型核心思想
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采瀑布模型用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。
在我们团队项目中，充分利用了这种方法，将各个成员的功能封装起来，整个工作流程都是一级一级往下传递。优点：只需关注当前阶段的工作。缺点：瀑布式的主要的问题是它的严格分级导致的*度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
big ball of mud
“大球泥”系统通常已经被开发在很长一段时间，与不同的个体，对各种片及部件进行工作。 没有正式的架构或编程培训的人开发的系统往往会陷入这种模式。富特和Yoder不普遍谴责的“大泥球”编程，并指出，这种模式是最普遍的，因为它的工作原理 - 至少在目前，它的发展。 然而，这种模式的计划会成为维护的噩梦。
我们的项目有一个大泥球么？
这次的团队项目中，我们项目也有个大泥球：由于我们负责的是search of this site 和upload/download功能，我们一开始的设计并不完全兼容数据库组和UI组的设计，前期接口的混乱造成软件开发的麻烦，还有一些功能模块设计不周导致调用越来越深，最后花了更多的时间将它们封装。
《大教堂与市集》（The Cathedral and the Bazaar）是埃里克·史蒂芬·雷蒙（Eric Steven Raymond）所撰写的软件工程方法论。本书讨论两种不同的*软件开发模式：
大教堂模式（The Cathedral model）：源代码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。
市集模式（The Bazaar model）：源代码在本模式也是公开的，不过却是放在互联网上供人检视及开发。
此书的要义是“让够多人看到源代码，错误将无所遁形”（Given enough eyeballs, all bugs are shallow）。作者表示大教堂模式的软件开发让程式除错的时间大幅增加，因为只有少数的开发者可参与修改工作。市集模式则相反。
两种模式都各有各的优点，而我们采用的大教堂模式，我们的规模比较小，相对而言并不需要太多的人参与，其次我们正处于初期开发阶段，功能较少，也并不能吸引到其它更多的人参与。随着我们对软件的开发，需要拓展的功能越来越多（可能会出现插件），我们的模式就可能有大教堂到市集了。
Lost in CatB- 有人负责，才有质量：写给在集市中迷失的一代
在市集化的潮流下，作者看到其中的不足，指出：所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。很多人觉得作者的观点偏激，但我觉得这只不过是作者对那些迷失在市集中的人的一点劝戒，不能忽视市集带来碎片化的危险，我想这就是为什么google既要给厂家，用户定制android的*，又要维护android市场的标准，统一。碎片化，缺乏标准会造成用户粘性差的问题。
Agile Method-敏捷软件开发
这是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.
这种方法适用于人员相互信任，人少精干，能够快速交流的地方。
我们团队项目中只有在小组工作中应用到了敏捷开发，小组与小组之间适用瀑布模式，在小组工作中由于小组成员一般一起干活，所以交流方便，大家水平大致有认知，而大组之间人员较多，并不是每个成员都需要与其他成员交流分析，我认为这样的模式分配还是比较科学的。