九妹带你走向 架构师

迈向系统架构师

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

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

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

要想成为一个优秀的系统架构师，并不是一朝一夕之功所能达到的，“冰冻三尺，非一日之寒”，除了要有很深的专业技能外，还需技术全面、成熟练达、洞察力强、经验丰富，具有战略性和前瞻性思惟能力，善于把握全局，可以在更高抽象级别上进行思考。若是说系统分析员、业务专家只须要对一个产品的业务负责，能够不关心一个产品软件开发语言的话，而一个优秀的职业系统架构师，不只要对产品背景和产品背后的业务逻辑熟悉，并且要对所用的软件开发语言（例如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 技术有深入了解。熟悉Oracle、MS SQL Server、DB2，对Eclipse 平台开发，基于SWT/GEF/EMF 的Eclipse 插件开发有深刻的实践基础。此外，熟悉UML、Rational Rose/ Rational Software Architecture 等面向对象分析技术和工具，熟悉WBI Modeler 等业务建模工具，从事过MDA/MDD 开发。