Silver bullet
软件开发的适应性和易变性使得开发过程变得异常复杂。面对不停的需求变化，开发人员必须根据需求来更改工程，有时这样的更改会花费很高的代价。不可见性也是软件工程的一个特性。机械零件的制造或是建筑物的设计可以通过设计图来较直观地展现设计过程中的不足，使得改进方向较为明确，但软件开发不同，工程与代码的抽象性使得不能用直观的方式找出错误或不足产生的地方，往往修复一个小bug都会耗去大量时间和人力。
软件开发的过程远没有想象中的那么简单，各种意想不到的问题都会发生，需求的变更，错误的出现等等都会使开发过程变得艰难。虽然没有一种可以本质上解决软件开发的复杂性，我们人就可以通过前人总结的各种方法和工具使开发过程变得尽量高效。
大泥球
大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，我们看到了多种指导方法，与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而，实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。大泥球发生的主要原因可以归结为：一次性代码，碎片式增长，为了让软件不出问题。
我们小组的工程是在前人工作的基础上进行更改与扩充，在一开始阅读他们的代码时，我们就发现了类似大泥球的代码，许多代码重复冗余。所以在改版的开发中，我们删去了所有杂乱的代码，几乎是进行了重写。并且进行重新编写时，注重扩展性和可重用性，尽量避免大泥球的出现。
CatB
世界上的建筑可以分两种：一种是集市，天天开放在那里，从无到有，从小到大；还有一种是大教堂，几代人呕心沥血，几十年才能建成，投入使用。当你新建一座建筑时，你可以采用集市的模式，也可以采用大教堂的模式。一般来说，集市的特点是开放式建设、成本低、周期短、品质平庸；大教堂的特点是封闭式建设、成本高、周期长、品质优异。
我们组的项目属于教堂式，虽然开发周期不算长，但是开发过程没有开放，对于软件设计本身考虑了高扩展性，算法也经过仔细推敲，开发的成本不算低。
现在市面上软件的数量在上升，软件的质量却在下降；对于软件包的依赖性在增多但软件的复用性在降低。开源虽然创造了史无前例的全民编程热潮，但也导致了无责任、非专业、凌乱的软件开发。在浪潮退去后，传统的紧密联系的团队开发，依然是现在软件开发模式的主流。
Worse is better
Rechard P.Gabriel 于1989年最早提出“越差就越好”（worse is better or WIB），后来发展为一种软件设计风格或理念。Gabriel的文章“the Rise of worse is better”中强调软件的简洁和界面。这同MIT approach(or the right thing)的作法形成鲜明对比，后者强调事前完美的设计。由于WIB可快速推出软件应用，并持续完善，故而易于推广。其观点几乎可以用另外一句话来概括：“Simple is Best”，
于我而言，我是支持这种观点的，因为市场是最好的评判者，一款产品是否能去的消费者的信任并占领市场，是对其“好坏”最直接，最有效的判断。简而言之：成王败寇，成功了就是好东西，不成功了就是坏东西。
瀑布模型
瀑布模型总的思想：将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。它的核心思想是按固定的顺序将问题化简，将功能的实现与设计分开，便于分工协作，即用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型的最大特点是将开发过程分成了一个个明确的阶段。为项目提供的按阶段划分的检查点，分成不同的阶段后可以使项目分成各个不同的小组，或是划分成不同的开发阶段。但是这个模型也存在着一些缺点，比如不适应用户需求的变化等等。
Agile Method
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。敏捷建模的价值观包括了五个价值观：沟通、简单、反馈、勇气、谦逊。
在我们小组的开发过程中，还是比较注重沟通的，代码编写中遇到什么困难，都倾向与互相讨论，积极反馈。
对于简单的原则，考虑到时间的有限我们也避免过多的设计不必要或者次要的功能，尽量使系统简单明了，保持功能的基础上便于开发。