架构师已死

                                                     架构师已死

【编者按】本篇是一篇旧文，但其中的问题依然值得思考，故而重新发出来，另外，也在本文的下半部分给出新的问题，欢迎读者在文末的留言板上说出你的想法：

2006年的职场出奇的冷清，相比前几年，简历的数量和质量都大为不如，很难得找到三年工作经验以上的人，有一个不是特别笨，就是特别怪。就是么，干得好谁没事换工作啊！Simon是一家外企软件公司的总经理，最近给这个问题愁坏了。项目一个接一个的接下来，人手越来越紧张。虽然Simon是个极限编程的粉丝，但也不得不批准了一份又一份的加班申请。HR经理把这个问题归结到房价上，他的妙论是“怕失业了还不上房款，不敢跳槽”。

这天，K项目组长Allen终于忍不住了，带了一个只有一年工作经验的小伙子要Simon面试，“很聪明！经验少了点。”

Simon皱了皱眉毛，说：“你不知道这个职位最低要求是三年工作经验吗？”

Allen说：“这已经是三个月里通过技术考试中最好的一个了，老大，试试吧。”Allen是Simon多年的哥们，比较随便。

抵到面子上来，Simon只好让Allen把小伙子带进来。

Simon的面试通常是三步曲：

问题一：你能说说毕业后的主要工作经历吗？

问题二：再说说你在公司的地位？

问题三：你的发展目标是什么？等回答后，比如说构架师，他就跟着问：想象一下你当构架师的一天，说给我听听？

小伙子回答第一问题很快很清楚，一年工作当然没什么东西。Simon觉得小伙子挺聪明。所以在小伙子回答了第二个问题后，问了一个发散性的问题：“你刚才说你在公司里处于中等水平，那比你差的人为什么会比你差呢？”

这个问题是个陷阱。

小伙子冒冒失失回答说：“我觉得他们每天工作是为工作而工作，工作没有责任感。”

Simon点点头说：“是吗？那真是糟糕的员工。那你刚好比糟糕的员工好一点了？”

小伙子的脸一下子红了，“我不是这个意思……”

“好了，那你说说比你好的人为什么比你强？”

“我觉得他非常努力，工作很多年了还在学习各种构架，水平很高。”于是Simon就问那最后一个问题。果然，小伙子回答的是要成为构架师。大概70％的人想成为构架师。但是构架师是什么呢？

Simon问道：“那你为什么要成为构架师呢？”

小伙子一愣，大概还没有人这么置疑过他。“年纪大了，不能老写程序吧。”这个回答，让Simon想起关于他对什么是老的定义：当你希望做年轻人做的事情时，你就还年轻；如果你希望做老年人做的事情，你就老了。这和你出生了多长时间是没有关系的。

Simon接着问：“好吧，那你说说你成为构架师以后，每天都会做什么？”

小伙子说：“我还没想过，不过，我想应该主要是需求分析，设计构架吧……”这大概是现在年轻人的通病，年轻人很容易追逐一些自己也不清楚的目标。

Simon问：“那设计构架具体都做些什么呢？”

小伙子这次的回答是：“比如，选择程序框架，决定用Spring或Struts等等。”

“哦，那我问你，你怎么说服别人是用Spring还是Struts呢？”

“如果我有经验，我会知道哪个更好……”

“是吗，但关于Spring或Struts的知识任谁都可以很容易得到。如果别人不同意你的建议，你怎么说服他？如果同意你的建议，那你不过是作出了和别人一样的认识，别人又凭什么认可你呢？”

小伙子没想过构架师日子里还有一个说服人的工作，说：“我是构架师，我应该有权力做决定吧？”

Simon想起权力的三种层次，第一层，任命；第二层，专业；第三层，品德。

Simon问：“如果在一个成熟的软件企业里没有你所想象的构架师呢？或者说，构架师这种职业已经死亡或消失了呢？你会怎么定位你的职业？”

小伙子显得很震惊。

Simon画了一个系统构架，然后又给小伙子看了一段代码。

“那一个更难懂？”Simon问。

小伙子指着代码说：“代码难懂。”

Simon的解释是：“这就是为什么实际上所谓的构架师不存在的原因。一个更简单的东西怎么会更有价值呢？每个人都能够画出这种构架图，但不是每个人都能写出好的代码。”

送走了小伙子，Simon有点难受。他有点喜欢这个小伙子，但是，这又是一个被愚蠢的教育和误人子弟的技术杂志污染的家伙。Simon在自己的笔记本中加了一句话：中国程序员最愚蠢的认识之三：我想当构架师。前面两个赫然是：

35岁后写不动程序了；

我只要做Java（C＋＋）；

作者：方剑斌

来自：http://blog.csdn.net/summerfang2000/

但是我们又改如何，另外一个读者玉开（http://www.cnblogs.com/yukaizhao/）给出了自己的想法，他想呼唤一下，让架构师复活吧！

以下为详情：

0. 序

我不便说我所在的公司是那家公司，后面所说的公司就是我所在的公司。以下所说的项目仅仅说一些与本文相关的内容，不会说到具体内容。

我做为一名网站开发人员进入这家公司，我的工作是做一些网站系统，我的第一个项目是一个图片管理的系统，为内部共享图片使用。与这个项目相关的有以前已经完成的一个内容管理系统cms。图片管理系统需要使用cms用户的数据进行登录，然后还需要在这些数据的基础上进行授权。另外还有一个与此项目无关的系统，是公司内部的一个考勤统计系统，我做的这个项目与考勤系统没有直接关系。

我与负责的产品经理谈好需求之后，由一位领导告诉我怎样与cms系统交互，不可思议的是我需要直接通过连接cms的数据库去完成图片管理系统的用户登录功能。很明显这样做是不正确的，用户登录的过程可能做很多事情，有可能需要记录登录日志，有可能需要更新用户的登录次数等等。这样我连接到对方数据库，重新编写登录逻辑的做法非常不合适，于是我提出来可否通过CMS系统提供登录Web服务，由我这儿的图片管理系统去调用，但是不幸的是领导并没有很在意这个问题，领导说这种功能封装很容易以后再说吧，由于我只是新人，不便争执，因为如果我争执的话，肯定还会给做cms的团队带去一些工作量。另外一点图片管理系统还涉及到了权限的管理，而这在cms中也是现有的功能，而由于图片管理系统是几种新的角色，所以需要在本系统内实现，很显然这也是不合适的，也属于一样的逻辑实现两次，另外还因为考勤统计系统中也有公司所有员工的用户信息，下面就是现有的系统一个侧面结构图。

这种结构造成了一些重复的逻辑和重复的数据，还有就是给各个系统之间造成了病态的耦合关系，这些将给维护造成了很大的困难，而且还会给后开发的系统增加很大的工作量。

上面的图片管理系统只是我做的一个小东西，很快就迎来了第二个项目，是网站的一个频道，就像新浪有宽频，有新闻等等，我做的是这些中的一个。我们公司业务很多，所以有很多模块，我做的这个东西呢会引用到很多其他模块的东西，怎么引用其他模块的东西就成了一个问题，这里（我的公司）采用的方式有几种1） 直接读取对方数据库 2）直接引用对方dll，3） 调数据库中的存储过程。 虽然方式不少，但是没有一种是令人感到美的。代码可以是美的，整个系统的架构更可以是美的！所以我呼喊：复活吧，架构师！

1. 架构师应该做什么工作

有了上面的问题，我忍不住想呼唤系统架构师出现。在《架构师已死》这篇文中曾经提到一位面试的朋友认为架构师的工作是选择某个项目是采用structs还是spring结构来开发，结果博主证明选择这个问题比编码还简单，所以这不是架构师的工作，架构师的工作应该是难度更大的工作，架构师应该熟悉公司所有的项目，并且可以一定程度上预见将来会有的系统，从而调节各个系统之间的关系，使各个子系统形成一个完美的架构体，既可以稳定的相互影响，也可以各自独立的运行；用软件工程的术语就是使各个子系统内聚性和它们之间的耦合度达到一种美妙的平衡。

我们还和传统的建筑工程做类比，系统架构师的工作不是某个大厦设计师的工作，而是整个城市布局的设计师。架构师必须了解每一座大厦，每一个菜市场，每一个医院的结构和作用以及它们之间的关系，和一些外部的因素，然后才可以决定如何构建一个美丽健康怡人的城市。

2. 有了架构师我们会收益什么

做好了架构师的工作，可以使我们的程序更稳定，因为程序子系统之间的结构是稳定的。可以减少我们维护的工作量，一个好的架构师，绝对不会让系统中出现重复的逻辑和数据，这必然减少系统的开发工作；架构师还可以使构建新系统的工作更容易，因为架构师会为我们抽象出底层的模块，在各个程序之间共享。

本文中的第一个案例经过架构师的设计之后，如下：

架构师设计了一个用户管理系统模块给其他的三个模块提供用户管理的服务，涉及到用户的操作统一在用户管理系统中完成，包括用户的注册，和权限的管理等等。这样新开发一个系统的时候没有必要再去做系统登录，用户授权的模块。这样的结构是不是更好一些？

3. 架构师需要什么能力

架构师首先要懂得编码，编码是设计的前提；然后还需要懂得设计，能够设计出完美的系统；然后还需要有通观全局的能力；有出色的协调能力，大家可以看到架构师的工作有可能会涉及到多个项目，这就需要在多个项目组，甚至客户之间进行协调。

文中举的例子比较简单，但是真正的架构师不可能只处理这样简单的问题，要考虑很多方面的因素。

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-