没有银弹
《没有银弹》，Brooks在该论文中，强调真正的银弹并不存在，而所谓的没有银弹则是指没有任何一项技术或方法可以能让软件工程的生产力在十年内提高十倍。文中讨论到了软件工程中主要的两种困难，即次要和必要复杂度。所谓次要复杂度是指由人们本身所产生的问题，而这类型的问题是可以被解决的。譬如说，撰写和最佳化组合语言的复杂度就是属于次要的，它可以借由高阶程序语言如Java来取代。同时发展起来的高级语言、分时技术、集成开发环境等都能一定程度程度上解决这一类型的问题。必要复杂度则是从软件本身要解决的问题衍生而来，并无法被移除。如果软件需要提供三十个不同的功能，那么这三十个功能都是必要的，这些功能都必须被实作出来。Brooks认为“没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。”，也就是他认为银弹时不存在的。
从我个人在团队开发的经历中来说，我感觉开发必然会伴随许多的缺陷，有些很严重，有些只能算作小瑕疵，假如没有子弹来解决他们的话，那么就会累积成一个巨大的漏洞，但是也没有一种方法就能解决所有类型的问题。对于不同级别的问题，我们团队都会采取不同的策略去解决。
大泥球
所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，多种指导方法一起出现，然而实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。
在我们团队开发阶段中，我们也出现了大泥球，包括我自己一开始也写了个“大泥球”。回忆一下当时为了尽快开发出缓存功能，我就在看了网上代码的例子的基础上，直接进行拷贝修改，并且根据我们app的需求增加了一系列嵌套和使用线程，最后导致这一段代码显得十分冗长、杂乱、在我们的工程中重复出现了多次（因为我进行了简单的复制黏贴）。后来，我们采取了封装的方法解决了这个大泥球。
结合我自己的编程经验，可以将其产生的原因总结为：一次性代码，碎片式增长，缺少前期设计，应对需求和架构变化过晚，程序员的经验，技巧，眼界的限制。
教堂和大市集
我认为作者写这篇文章，是鉴于当时的自由软件开发的现状。他不满于当时开发软件的低效率，而且，他认为，低效率的原因在于Debug阶段花费了大量的时间。由此，他把开源软件的开发模式分为两种，一种是大教堂模式，最终源码公开，但是开发过程有一个团体控制；一种是市集模式，同源源码公开，且源码放在互联网上供人阅览，并可以贡献代码，进行开发。并且提倡市集模式，认为在足够的人的检视之下，BUG将无处藏身。
我认为市集模式能够被全世界接受，并且被推广，必定有其优点存在。比如著名的linux操作系统就是采取的市集模式开发的，并且由于这种开发模式，使得linux获得了极快的传播和发展，linux基础版本几乎没有bug。同时，大教堂模式也有其优点，我觉得应该在不同的开发场景下选择适合的开发模式。比如我们的项目，应该是比较类似于大教堂模式，因为就算我们开源了，也没有人关注我们的项目和同我们一起开发。但从另一方面来看，在此模式下，我们一直控制着我们的代码，能够比较好的实现我们自己想要的需求。
瀑布模型
我觉得瀑布模型的其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。如果某个阶段存在问题，那么可能会回溯到前几个环节重新执行。
瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。而对于我们这种较小规模的软件开发项目，瀑布模型并没有非常明显的体现，但是有一些过程的逻辑顺序是不能被破坏的，一旦破坏带来的重复劳动或者说是无意义劳动是十分巨大的。
Lost in CatB
作者主要讲述了开源软件中的过度依赖问题，这个问题在我们的工程中也遇到过，我们使用的一个开源库，下载下来之可能有很多是不必要的包，比如是开源框架本身自己的测试所需要的包或者是样例的包，我们一开始都把这些包import进来，然后导致在开发时的编译花了非常多的无用时间。后来我们简化了对开源包的使用，将一些不必要的文件进行了剔除，形成最后的发布版本。
敏捷开发
我们的团队开发中主要用到的敏捷的原则，就是组员面对面交流和尽量简单化。
我们会尽量在统一的时间，同一个地点进行编程。这样不仅能相互监督提高效率，也方便了不同职责人员之间的交流。尤其是当某人遇到问题的时候，各个于其负责模块有关联的人员，能够及时地检查并一起发现问题、处理问题。同时一定程度上也能避免“大泥球”的存在。
简单化的原则，在我们开发初期其实坚持的比较好，首先以最简单的功能为目标进行实现。但是中期由于提出了UI的显示效果不足的问题，然后追求过一段时间的复杂特效，导致那段时间，一方面前端一直在变，后台新开发的功能耦合不上，最后后台的进度几乎停止；另一方面，前端追求特效的同时，也遇到了很难解决的困难，导致进度停滞不前。最后的冲刺阶段，我们重新确立了以简单化为原则的开发理念，最后发布了第一个版本。
软件工程方法论
我之前并不能十分理解课上讲的、包括书上写的一些方法论的理念，以及其究竟有什么实际意义。但是经过了自己团队的开发过程之后，我能体会到这些方法论一定层次上的实际意义。假如完全违背了其中某一条原则，那么一定会导致开发进程的拖沓和效率低下等严重问题。但是很多时候，我们的开发效率还是由于个人水平不够以及经验不足等因素造成低下，所以我们在实际中应该把团队的实际情况、软件的实际情况、市场的实际情况同软件工程方法论相结合来使用，才能达到比较好的效果。