话说这几个词确实能唬住不少人，哪怕是在程序界耕耘多年的，自认为”有点小牛Ｂ“的程序员，谈及这几个词儿时也不免有心头发虚的感觉。一个程序员从写一堆if…else…开始自己的职业生涯。

不得不说if…else…的强大，很多程序员靠着熟练运用这把利器解决产品提过来的一个又一个的需求，他们只需要在离开公司之前，用if…else… hold住各种膨胀的需求，不让程序出啥大问题就可以了，至于后面谁来接手，如何继续维护就不在他们的考虑范围之内了。

但是，毕竟有些程序员是要打算在一个公司长干的，把自己维护的代码搞得像坨shit是给自己挖坑。于是他们会对当前的需求，以及未来可能产生的变化做一定的思考，并尝试抽象出一种设计方式来解决相同性质的问题，达到以不变应万变的目的（当然是一定范围内）。这就是设计模式，它是一种被反复打磨的编程经验的总结，它很像产品界常说的方法论。

虽然在解决具体编程的问题上有设计模式来助力，但是整个应用的设计仍然需要一个良好的骨架来支撑。它也是一种抽象，抽象的内容则是应用中各个模块之间的关系，流程。框架的设计理念和公司制度流程很像，虽然各个不同的公司有自己的具体情况，但是一个成熟的公司制度是具有一定普适性的。  当然即使一个应用没有框架，也是可以构建起来的，但是有了框架的约束，能够让应用更加规范的构建起来，即使实现具体功能的程序员水平不高，但是在合理的框架下，整个应用也不会出大问题，各个模块之间协作会变得流畅。框架的使用也是为了提高程序的复用性，同类应用使用同一个框架来实现快速搭建。就比如现在有很多成熟的游戏开发框架，拿过来加个壳就是个新游戏了。

再来说说架构。上面说的设计模式，框架虽然是有一定的抽象，但是还是偏技术实现的东西。到了架构设计这个层面，基本就摆脱了这些偏具体实现的东西了，但是这不是说架构设计者不用懂具体实现，而是他不用关心具体实现，也不会将自己的思维限制在具体实现上。架构设计者会在一个非常抽象的层次提出解决方案，甚至横跨软件硬件，而框架，设计模式都是为他的设计服务的。

在一个公司的发展过程中，经常会见到这样的情况。公司发展初期，会招揽一些很一般的程序员（要价比较低），他们的工作就是完成初期的各种业务，不需要什么设计或者只需要极少的设计。随着业务的发展越来越庞大，一些程序员已经hold不住了，于是见事不对，立马撤退。这时公司需要更有责任感的程序员来改善目前的窘境，他们的任务就是重构，合理的使用设计模式或者引入成熟的框架来挽救脆弱不堪的系统。随着系统的进一步膨胀，一些架构层次的安全性，扩展性需要考虑时，公司就开始花重金找牛人（有钱了嘛），安个CTO的名头，来为业务发展保驾护航。