开发人员如何成为架构师

不少架构师都是从好的开发人员逐步过渡而来的，但并不是每一个好的开发人员都但愿成为架构师，并且他们并非都适合作架构师。不管您是打算进行职业转型的开发人员，仍是寻找能承担体系结构设计责任的合适人选的经理，都务必对此转型过程有个清楚的了解。本文将讨论从实现专家到架构师的过渡过程。

　在寻找优秀的指挥的时候，您首先要找的是一名优秀的音乐演奏家。但并不是每一个音乐演奏家都能成为优秀的指挥。架构师的专业发展方面也与此相似。愈来愈多的 IT 组织开始认识到良好软件体系结构的重要性，架构师职业正迅速发展为 IT 内一个独立的门类。因为要从至关小的候选范围内招募架构师，所以这就给管理带来了一些新挑战。即便人力资源部门找到了候选者，针对经验进行的筛选也比其余门类更为严格。跨越这些障碍的最快方式是要认识到，大部分好的架构师同时也是好的开发人员，所以寻找架构师人才时可能首先应该从普通开发人员中找起。招聘人员在对候选者（内部或外部）进行详细审查时，应该考虑这个观点。不过，对此资源进行挑选可能比较麻烦，由于只有极少的优秀开发人员具备成为架构师的特征或愿望。

本文列出了开发人员成为架构师要进行的工做。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在作出这些决策时要考虑的因素。

我的特征

软件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。两者都倾向于以彻底不一样的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的状况仍然很是广泛，并且这是项目失败的首要缘由。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。如下是成功架构师的一些主要特征。

愿意并有能力进行沟通：在开发人员中发现架构师的最有价值标准是有效的沟通。您须要技术娴熟、经验丰富的开发人员，这样的人员须要有就项目中的业务相关问题进行沟通的经历。架构师常常必须对理解方面的差距进行预计，而后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并没必要对意见交换工做进行计划和协调；这仍然主要是项目经理的工做。他们的任务是肯定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须可以判断当前方法显得不足而须要采用新方法的状况。写做技能也很是重要，还须要具备制做草图的技能或使用制图软件的能力。

具备处理谈判细节方面的经验：架构师常常须要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践限制、风险规避或可能致使在各个不一样业务组之间需求不一样。优秀的架构师可以有效地评估技术可能性，并能在不损失项目的主要价值的前提下制订开发计划来处理各类利害关系和限制。这与前面讨论的沟通技能紧密相关，但同时也要体现架构师的技术能力。好的架构师候选者应该是常常帮助对有争议的讨论进行引导的人，可以使讨论得出新的想法，而不会使其在一个位置停滞不前。

自觉主动；积极解决设计问题：架构师的平常工做目标常常并不明确。不少开发人员直接参考功能规范来列出任务清单。架构师一般则是向这些开发人员提供所需结构的人员，以便尽量提升工做效率。好的候选者不只进行沟通方面的工做，并且也会预计各类设计问题并加以解决——一般在没有任何具体指示的状况下自觉进行。不管所分配的职责如何，积极参与项目的开发人员都有机会从一块儿工做的人员中脱颖而出。

抽象思惟和分析：架构师必须可以理解表述模糊的概念并将其变成相关各方可以理解的项目构件。他们必须可以理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者常常要求或本身主动解释开发生命周期中容易混淆的问题。他们能迅速评估各类想法并将其归入后续工做的操做建议中。

开发人员常常具备很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员常常说开发人员具备“工程意识”，而这是一个用于评估架构师的很是有意义的方面。架构师应该具备很强的解决技术问题的能力，但还必须可以准确获知更为全面的人员如何与技术交互的信息。这要求具备某种形式的抽象思惟（而再也不是代码的细节），这种思惟能力可能较难造成。

有些人认为，某种级别的正式教育是成为优秀开发人员的必备条件之一，我并不一样意这种精英论。我遇到了不少高中就辍学的优秀开发人员。不过，对于体系结构设计工做，个人我的经验以及我对所需能力的认识都让我相信，好的架构师一般至少得到了一个有挑战性的学士学位。

跟踪生命周期

好的架构师一般有在具有定义良好的软件开发生命周期（Software Development Life Cycle，SDLC）的组织工做的经验。架构师必须理解在其所属专业内最重要的操做过程。这并不意味着须要有其余前提，例如，并不须要高能力成熟度模型（Capability Maturity Model，CMM）级别的工做经验。好的架构师可能来自使用 SDLC 的多个小型迭代的极限编程（Extreme Programming，XP）方法的组织。务必注意各类传统软件开发操做，如 Michael A. Jackson 的方法：Jackson 结构编程（Jackson Structured Programming，JSP）和 Jackson 系统开发（Jackson System Development，JSD）（请参见参考资料）。Jackson 的研究对架构师职业发展的意义就像 Donald Knuth 的研究对程序员同样重要。架构师能够偏心任何经典的、通过时间考验的软件系统开发方法。

SDLC 也能够成为评估架构师合适人选的有用机制。每一个 SDLC 阶段都具备能提供相关线索的特征。SDLC 包含不少小的变体，但在此部分，我将使用几乎全部方法的公共基础部分。下面的列表详细说明了 SDLC 的各个阶段，并列出了好的架构师候选者在每一个阶段表现出来的特征。

分析：在分析期间，好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来普遍的软件经验供参考。寻找具备丰富经验的开发人员，以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的早期阶段可以预计可能遇到的问题的开发人员。

设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素，并就其进行沟通，以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所获得的系统体系结构的功能。在详细设计期间，他们所扮演的角色并非核心角色，但为了根据整个系统的规则对特定模块的元素进行审查，仍然须要他们。寻找善于让团队可以预计设计决策对最终系统的影响的开发人员。寻找善于肯定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。

实现：在实现期间，架构师对项目进行引导，以确保其符合系统体系结构。他们在一线评估技术更改请求，并肯定如何对设计进行调整，以最好地处理此类请求。架构师还要密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。寻找常常对讨论进行引导来链接多个子系统的开发人员。寻找项目经理能够依赖其快速地进行与更改和出现的问题相关的风险评估的开发人员。

测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。

维护：在维护期间，架构师将发起关于系统集成的讨论。不管处理 IT 基础设施问题，仍是确保部门之间的技术合做，架构师都必须彻底理解应用程序，必须快速学习姊妹应用程序的体系结构，并且必须就集成点和风险进行有效沟通。寻找具备系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特的任务。

架构师培养建议

有些组织能比其余组织更有效地进行架构师培养。若是充分考虑到招聘此类新专业人才的困难，努力促成能鼓励开发人员发展为架构师的环境是很是明智的策略。但务必避免对不肯意或不适合走这条路的开发人员进行处罚。组织应该为开发人员制订多条发展路线，包括那些愿意继续担任开发人员的人。对架构师而言，资深开发人员不可或缺。他们能够实现系统中最关键的模块。经过对其余开发人员进行代码检查和测试支持，他们可帮助确保整体软件质量，而若是质量不能保证，即便最好的体系结构也毫无用处。

组织应制订我的评估程序，以鼓励开发人员考虑其职业目标，其中要包含体系结构设计的选项。应该鼓励经理在其下属中寻找体系结构设计人才。应该实现指导计划，让架构师与但愿成为架构师的开发人员协做工做。应该鼓励开发人员经过参加各类协会、撰写文章和参加会议，从而参与到专业领域中来。经过这样参与进来，可帮助开发人员重新的角度理解系统，并帮助他们更好地就其认识进行沟通。这样还能培养可提升效率的重要创新想法。

结束语

开发人员一旦迈出了通向体系结构设计专业方向的第一步，就能够利用不少资源来得到帮助，其中包括不少来自 IBM 的资源。有时候，此过程的最困难的部分就是第一步，而本文提供了一些线索和提示，经理和开发人员能够利用其来评估应该鼓励哪些人努力成为架构师。

更多内容请关注微信公众号：it_haha

http://www.uml.org.cn/zjjs/200703062.asp