迈向系统架构师


编者按:系统架构师是许多程序员的梦想职业。今天的你也许已经掌握了各种开发工具,并且能够使用各种平台进行开发,但作为一个架构师的要求,也许还有很长的道路。邢波涛先生在LAMP架构上的造诣,让我邀请他撰写本文,也许这位架构师的建议能让你在未来的架构师之路上节省一点时间。

一个产品的经典开发步骤通常需要经过系统需求调研、系统分析、系统设计、开发、测试、部署实施等一系列的步骤,如下图所示:

wKioL1jk-XfjmLXhAAGdpK_E7BQ257.png-wh_50

而系统架构师,则在这个过程中,起到了承上(面对业务专家/系统分析员)和启下(面对软件工程师)的作用。所以说,系统架构师,在整个产品开发周期内是一个核心角色。如果说市场和销售决定一个产品是否好卖的话,系统架构师则直接决定着这个产品的开发是否成功。从某种意义上说,这也是众多程序员未来的梦想职业。

要想成为一个优秀的系统架构师,并非一朝一夕之功所能达到的,“冰冻三尺,非一日之寒”,除了要有很深的专业技能外,还需技术全面、成熟练达、洞察力强、经验丰富,具备战略性和前瞻性思维能力,善于把握全局,能够在更高抽象级别上进行思考。如果说系统分析员、业务专家只需要对一个产品的业务负责,可以不关心一个产品软件开发语言的话,而一个优秀的职业系统架构师,不仅要对产品背景和产品背后的业务逻辑熟悉,而且要对所用的软件开发语言(例如Java/C#/C/C++/J2EE),也要非常熟悉才可以,两者缺一不可。否则就起不到承上启下的作用,当然也设计不出良好的软件架构。在美国,一个合格的系统架构师的薪水甚至比部门经理或产品经理要高很多,这也是美国为什么三四十岁甚至五十岁的程序员也很常见的原因。

事实上,软件开发中碰到的很多问题,归结起来都可能和当初的架构设计有关,所以架构师要想不成为众矢之的,决不是件容易的事情。基于此,我认为,要想成为合格的系统架构师,首先要从程序员做起,只有有了多年的一线软件开发经验,深刻体会到了程序员的艰辛与不容易,才能设计出易于扩展、易于修改、易于维护、“不难为”程序员的架构出来。一个系统架构师,首先要能做出能够“自圆其说”的原型,才能跟程序员进行有效的沟通,而不是只是设计出来一个架构,就完全交给程序员来做了,这样,后期开发出来的产品风险很大。以我现在参与开发的产品为例,这个产品只是公司核心战略产品的很小的一部分,当然,虽然小,却是核心中的核心。这个产品配了3个系统架构师(年龄都在40岁以上,有数十年的软件开发经验),6个程序员、5个测试,还有一个负责产品打包的工程师。这3个系统架构师也都参与核心代码编写。

其次,合格的系统架构师,对所要开发的产品的业务背景,也要相当的熟悉才好,否则,设计出来的产品就不是客户想要的产品,当然也就不是成功的产品。还是以我现在参与的产品为例,这个产品是SCA规范的一个实现,3个系统架构师的其中一个,就是SCA标准规范的参与者与制定者,对SOA/SCA标准,有着相当的功底,否则,做出来的产品,就只能围着大公司,在他们屁股后面天天追了,别人做什么,自己也做什么,别人标准修改了,自己也赶快跟着修改。

第三,作为系统架构师,要经常阅读一些关于产品背景资料和系统架构设计方面的最新书籍。虽然现在技术方面的书籍,出得太滥,精品极少,大部分是从网上抄袭一些资料攒出来的,但是经常阅读一些国外大师的一些精品图书,还是能给自己带来一些新的思路和设计理念的。

第四,作为系统架构师,一定要有自信,既不要保守,也不要人云亦云,千万不要迷信于大师和大侠。别人说J2EE好,自己的产品就基于J2EE开发;别人说.NET容易开发,开发成本低,就转做.NET;别人说Ruby很敏捷,自己就说自己的产品是基于ROR开发的。一定要结合公司、市场和项目的实际情况,采用合适于自己的开发语言,设计出合适于自己的架构。比如,《J2EEWithoutEJB》那本书,提出了著名的“不要造新轮子”原则。如果大家都不要造轮子,都利用别人现有的框架和产品,怎么可能有技术的进步和百花齐放、欣欣向荣的景象呢?Spring的作者还不是看到经典J2EEEJB框架的诟病,才设计出来自己的Spring轮子了吗,为什么自己有了Spring轮子,就劝别人不要另造轮子了呢?GavinKing造出来了Hibenate这个轮子,为什么又参与EJB3.0的制定呢?并又参与设计出Seam这个轮子?我个人觉得,一个系统架构师,一定要造出自己的轮子,才算是真正的系统架构师,而不是拿着一大堆开源框架进行拼凑。

第五,对于开源的架构设计,要批判性地继承。要多阅读这些框架的源代码。以J2EE和Eclipse插件开发为例(因为我专注于这两个方面的开发),从前些年流行EJB,再到Struts→J2EEwithoutEJB→Spring/Hibernate→AJAX,每一个框架的流行,都有其深刻的历史背景,有一些现有框架解决不了的难题在里面,这些框架都是为了解决一些问题而出现的。我们经常阅读这些大师的源代码,精神上是一种享受,对锤炼自己的功底,也是大有好处的。例如,在做Eclipse插件开发的时候,常常会遇到一个问题,怎么才能监听到用户保存的事件,虽然Eclipse提供了资源变化监听机制,但是直接利用其机制,是很原始的,任何资源的变化,比如,添加/删除/移动一个图形,都会引起这个事件的调用,而我只想监听用户存盘的一刹那那个事件,以前在做项目的时候,想尽各种办法也没解决好。后来,在另外一个产品的源代码中,就看到了别人很好的解决方案,自己看到那段源代码,真的是领悟到很多。有时候,Eclipse的源代码和J2EE的源代码,在架构上是可以互相借鉴和补充的。比如,Eclipse的Adapter扩展机制和事件、资源监听机制,我们一样可以拿到J2EE框架中来,作为设计自己产品的设计模式蓝图。

第六,优秀的系统架构师还要拥有优秀的沟通能力,用以进行说服、鼓励和指导等活动,并赢得项目组成员的信任。一个系统架构师设计出一个良好的框架后,如果不能跟程序员进行有效的沟通,不能对程序员进行良好的指导,则这个良好的框架就不能很好的贯彻到产品开发的每个环节中去。有的程序员可能还是按照老经验对程序中的一些关键环节进行处理,等到这个架构师发现问题时,可能已经很晚了,说服、教育、培训和处罚到那时已经没有意义了。另外,如果一个系统架构师不能赢得项目组成员信任的话,那么他设计出来的架构就不具备说服力,程序员遇到困难,就会抱怨系统架构师设计的框架有问题,不能充分调动起来程序员的责任感和主观能动性。所以说,一个优秀的系统架构师,无论在精神上,还是技能上,都是一个程序员良好的导师。

第七,系统架构师要分清自己和系统分析员、项目经理或产品经理之间的角色和关系,不能负责一切,也不能只负责技术架构。由于系统架构师在整个产品开发周期内处于承上启下的中间地位,和程序员打交道的时间比系统分析员面向程序员的时间要长,有时候甚至比项目经理和程序员之间还熟悉,使得程序员很容易认为系统架构师对所有的需求和架构都负责,容易造成系统架构师职责过重。

成为优秀系统架构师的路,是一条漫长而任重道远的路。在这条道路上,要不断说服自己,不断抵制各种诱惑,要能在深夜无人的时候,挑灯阅读别人的源代码,还要有承受住各种压力的能力,能跟项目经理一起抵制住老板的无理工期要求,还要在困难的时候,鼓励项目组成员一起渡过难关。总之一句话,要想成为系统架构师,不是很容易。“路漫漫其修远兮,吾将上下而求索”。

作者简介:

邢波涛,11 年软件开发和管理经验,7 年的J2EE 开发经验, 资深J2EE 专家。对JSP/ Servlet /JavaBean/EJB 技术有深刻了解。熟悉OracleMS SQL ServerDB2,对Eclipse 平台开发,基于SWT/GEF/EMF 的Eclipse 插件开发有深入的实践基础。此外,熟悉UML、Rational Rose/ Rational Software Architecture 等面向对象分析技术和工具,熟悉WBI Modeler 等业务建模工具,从事过MDA/MDD 开发。