| 几个软件工程方法论认识： |
1、大泥球
定义：一个大泥球是杂乱无章的结构，蔓延，马虎，管道胶带和保龄线，意大利面代码丛林。
这些系统显示出明显的不受监管的增长迹象，以及反复的权宜之计。信息在系统的遥远元素之间杂乱无章地共享，通常到了几乎所有重要信息都成为全局或重复的程度。系统的总体结构可能从未被很好地定义过。
为什么一个系统会变成大泥球？有时，大型、丑陋的系统会从 一次性代码 中出现。废弃代码是一种快速而肮脏的代码，它只打算使用一次，然后被丢弃。然而，这样的代码通常会有自己的生命，尽管它的结构很随意，文档也很差或根本不存在。当出现相关的问题时，最快的解决方法可能是方便地修改这个工作代码，而不是从头设计一个合适的通用程序。随着时间的推移，一个简单的一次性程序会产生一个大泥球。
大泥球可能被认为是一种反模式，因为我们的意图是展示在破坏建筑的力量面前的被动是如何导致泥潭的。然而，其不可否认的受欢迎程度导致了一个必然的结论，即它本身就是一种模式。对于在软件开发环境中生成工作系统的问题，它无疑是一个普遍的、反复出现的解决方案。当一个人面对上述各种力量时，这似乎是阻力最小的道路。只有理解它的吸引力的逻辑，我们才能引导或抵消导致一个大泥球的力量。
2、瀑布模型——传统开发模式
瀑布模型（Waterfall Model）是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
3、敏捷开发
敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
四条原则：
- 递增，而不是连续的
- 避免不必要的开销
- 协作
- 说真话
进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准。敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
瀑布型与敏捷开发的区别：
瀑布型与敏捷开发的区别大多在于效率，瀑布型太过于繁琐，不是那么的便捷，每次出错只能一级一级的慢慢上报，而没有“敏捷”面对面沟通的迅速，也能更清楚的表达问题所在。
4、教堂
一套业务系统是不能完全满足用户业务需求的。对每个用户都要进行需求分析，概要设计，详细设计等必要的环节，是必须的。就像教堂的建成一样，需要很多年的时间才可以竣工，而且也需要很多环节的高度配合，每一步也要走的精准。
5、集市
开源（Open Source，开放源码）被非赢利软件组织（美国的Open Source Initiative协会）注册为认证标记，并对其进行了正式的定义，用于描述那些源码可以被公众使用的软件，并且此软件的使用、修改和发行也不受许可证的限制。
任何人都可以复用和发行开源软件的代码，被整个集市所共享。
问题：由Raymond在其书中称颂的集市模式导致的悲哀的现实：一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着。
在集市的世界里，人们知识机械的将代码复制过去，而并没有想过这些代码与自己所要设计的软件是否匹配，对于一些代码在自己用时是不能使用的，是需要加以修改的，但是大多人将代码复制时并没有更多的思考，这将让更多的IT人失去思考和发现问题的能力。
6、银弹
就目前的状况来说，银弹很难实现，但未来也许可以实现。
总结：
通过查看这几个软件工程的方法论，知道了一个软件的开发需要很多的步骤，讨论，沟通，环境等等都会影响整个的软件开发的进度与质量，而一个软件的实现就需要更多的方面的配合，不光自己还要和团队巧妙的配合。(一些链接都无法打开，只能依靠百度搜索零散的一些知识点。)
来源：https://www.cnblogs.com/youmine/p/12649869.html