什么决定架构？

   今天和同事探讨一些问题，偶尔提到了为什么要架构的问题，并交换了观点。对过去一些项目进行了反思，包括一些刚提拔上来的架构师做的一些成果，进行了检讨。
 
   到底需不需要架构，也就是为什么要架构？如果要的话，到底什么决定架构？个人觉得，回答这个问题，就要看回答者所处的层面或者说立场了。架构的好处，可以有一堆资料，我也就不罗嗦了。
   
   但是我们需要一个东西，就是因为这个物品有一堆好处吗？我想不一定吧！梳子是一个好东西，但是对于和尚来说，不一定就需要这个，或者说大部分和尚是不需要的，古董奢侈品除外。
  
   现在很多一谈架构，必谈SSH，好像没有了spring那简直不叫架构。那到底什么决定架构呢？常识？流行？通用？我想也不是吧。我们请客吃饭，一般都会点些猪肉制品。但是，是不是只要是请客就必须有猪肉制品呢（如红烧排骨啊等）。起码请回族的朋友就不能点。

   那，到底要不要架构，这个我们要回到架构的本质，架构为谁而生，这个概念的产生的初衷是什么。在10年前我们也不谈架构，而现在我们做什么都谈架构。到底是为什么？
现在的客户再也不是以前的客户了，他们掌握的信息化知识比以前要多的多，而他们期望信息化给他产生效果的周期越来越短，投入也希望更少，而且企业用户为了应对快速变化的市场，他的需求也在不断的变革。这就是架构产生的背景。架构的产生就是为了能让软件开发者或企业能更好的应对这些问题，而产生的一种软件构造方法和技术。
 
   所以架构对于需求千年不变的应用，可有可无。没有什么时间成本压力，就搞个艺术品。如果没有那么好的待遇，就搞个生活品。

   那什么决定架构呢？其实上面的例子里已经很明确，就是客户决定架构。说得更直接就是客户给的钱决定架构。道理很简单架构也是要成本的，架构选用的技术都是成本。你不能点一个菜，却要求餐馆给满汉全席的待遇给你吧。

评论

1 楼 lutian1984 2011-02-12  

小弟不才评论几句：
  我认为不管大小项目都应该用架构。在对架构不熟悉的人眼里，用架构是件费时费力的事情，如果我们程序员的水平都能运用架构灵活自由了，架构一个项目就和现在咱们编程一样不费力气了！