对于软件架构师的一些理解

1、软件架构师的定义

架构师在一个团队中的职责比较独特，既有特定的工做，又没有特定的工做。但毫无疑问处于团队的核心位置。

架构师不是项目经理，却也须要决定交付软件的时间和形式。架构师不是产品经理，却也须要保证如何实现业务功能。架构师不是软件工程师，却也须要作核心部分的研发。

大多数的架构师都是从技术出身，懂编码，懂算法，懂测试，懂部署。这些都是一个架构师的基础技能，但除此以外还须要掌握一些其余的必不可少的技能，记忆一些新的岗位职责。

2、软件架构师的工做职责

除了掌握编码、测试、部署等工做，架构师还须要有如下工做职责：

2.1 需求分析

架构师要与产品经理、项目经理一同协做，对客户提出的软件需求进行分析，并从专业角度给出意见。

项目经理从用户角度出发进行需求分析，产品经理从业务角度出发进行需求分析，架构师从技术角度出发进行需求分析，三者的分析结果结合到一块儿，可使分析结果更加立体和全面，避免上图中发生的状况。

除了业务需求外，架构师还须要关注另外一方面的需求 —— 非功能需求，这种需求更偏向技术，架构师应主动从项目经理和产品经理处密切关注这方面的需求，由于它们可能会影响到架构设计方向的约束和特性。

2.2 分解任务

这里所说的分解任务并非分配人员的工做，而是对一个系统进行模块分解。

一个项目通过的需求分析后，需求大致已肯定，那么就须要对这个项目进行模块分解，是总体向部分的过渡。架构师将软件系统进行分解，目的将复杂问题简单化，将项目分红若干模块后，逐一对这些模块进行攻克，设计出知足功能和非功能的需求。

例如，能够将用户需求划分出一个用户模块，车辆管理划分出一个车辆模块，行程应用划分出一个行程模块，指定不一样的团队开发不一样的模块，同时考虑非功能方面的需求，使模块具有更高的可靠性、可扩展性等。

当业务初期整个团队的需求理解并不那么透彻，能够将模块范围规划的大一些，避免过分拆分致使没法整合或整合的消耗过大，并不必定是越精细越好。当团队将业务理解透彻后，能够适当对模块进行重构，由于系统已具有较好的可扩展性，因此重构的工做并不会影响太大。

2.3 系统设计

系统设计阶段，是最为关键的一个环节之一。这时要求架构师要与团队的各个角色进行探讨交流，从全局的角度考虑总体系统架构。

这表示架构师并不在单单处理需求和技术问题，要与研发团队、测试团队和运维团队进行充分的交流和沟通，确保目标一致，减小信息不对称的状况。

架构师反复思考本身在这个阶段的每个决策，有条件能够进行同行评审，利用团队的智慧弥补我的考虑不足的状况。由于一个小小的设计缺陷都有可能在研发阶段形成深远的影响。

另外，选择最适合项目的架构，而不要可疑实用新技术或不务实的技术。例如，根据业务判断，一个普通的、供10人使用的订单管理系统就不须要选择微服务架构。空想不能落地的架构老是很容易的，为了不这种状况的发生，也须要从管理角度来避免。

2.4 非功能设计

非功能设计简单来讲就是系统要求的一些指标，例如：可用性、可伸缩性、可扩展性、可移植性、性能指标等等……

对于非功能设计，架构师要根据实际状况进行一些取舍。

例如，客户要求可用性在99.99%，那么架构师就要面临硬件数量翻倍的问题，客户要求安全系数很高，那么架构师就要面临采购更专业的防火墙的问题。

放弃一些东西来换取一些东西在软件设计过程当中也是很常见的。好比用控件换时间，用稍显复杂的设计模式换取扩展性，用冗余来换取可用性。架构师在这个阶段须要与项目经理和产品经理保持沟通，找到最符合项目的折中点。

这些工做很难作到尽善尽美，可能会犯一些错误，因此还须要进行严格的质量评审，而且有一套技术债务管理的方式方法。

2.5 技术债务管理

当由于某些缘由不得不留下一些未完成的工做，或者因为一些失误形成的遗留项，必定要记录在册，并有计划的进行补偿。

全部的软件都会存在技术债务，架构师须要了解系统的分解、模块的划分，还要把业务与技术放到一块儿进行考量，只有这样才能游刃有余的处理技术债务。

出色的研发团队会有意识的引入技术债务来实现更快的交付，后续再进行偿还，从而持续创造价值。

但要作到这必定，架构师必定要从大局观出发来考虑如何遗留技术债务，保证遗留的同时不影响软件的交付，这很难作到，要求架构师既精通技术，又了解业务，同时技术团队的研发人员也要与架构师在思想上达成统一。

2.6 团队技能提高

架构师还要担任整个团队的导师和顾问，设计狂拽酷炫却无能能理解的架构毫无心义，做为团队的技术专家，必须承担向团队分享知识的任务。

架构师要因地制宜，因人而异的传授设计技巧和架构理念，作到传道、受业、解惑。也能够提出一些批判性的建议。把架构当成一项团队建设，让全部团队成员都参到设计过程当中是最佳实践，这是最有效的提高团队技能的方式方法之一。

技能的提高对于团队的成败将起到相当重要的做用。

另外，架构师也要参与到团队的研发过程当中，能够经过编写模板、样例代码的方式与研发人员进行交流，若是时间不容许，最起码每周花费一天或者半天参加到研发团队中，了解架构的使用状况，有哪些优势和不足。

要知道，团队的智慧必定是大于我的的。同时有一点要说明，软件架构设计是一门以人为本的学科，培养体系是其中最难的一种体系之一。

3、如何成为软件架构师

从经验角度看，成为架构师以前，应该参与并开发过某行业领域的软件三到五个，并且在这个过程当中，承担的职责不断的增长。随着经验不断的累积，会发现编程的时间愈来愈少，设计的时间愈来愈多。慢慢的，变潜移默化的成为了架构师。

为了记录和评估是不是一个合格的架构师，能够创建一个项目工做档案表，来记录在项目中的工做。

业务理解，以及业务目标是什么？

答：

项目总体解决方案是什么？如何进行拆分的？

答：

涉及的技术栈有哪些？为何这么作？好处是什么？

答：

最大的风险是什么？如何克服的？如何管理的技术债务？

答：

若是从新作一次这个新项目，有哪些地方须要改进？为何？

答：

这个表格能够随时增长，记录项目中的架构思惟，当慢慢的对这些问题驾轻就熟，就已经能够胜任架构的工做了。

架构师不只仅是团队中的一个角色，更是一种思惟方式，就算是研发人员，天天也会作出不少小的设计决定，这其中有些决定是有架构意义的，架构师要作到高瞻远瞩，俯瞰大局，把设计工做当成乐趣从而乐在其中。

4、总结

综上所述，架构师是一个既须要掌控总体又须要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。

架构师跟多的时候是一个团队，须要创建高效的体系，带领团队去攻城略地，在规定的时间内完成项目，确保团队有共同的技术愿景，协调多个团队甚至整个组织内的工做。在通常组织里，很是优秀的研发人员才能够成为架构师。

同时，架构师又是很年轻的一个职业，这是相比于医生或者建筑师而言，若是医生和建筑师在工做期间给出了错误的判断和决定，那么颇有可能要负法律责任，例如在某些国家，获得注册建筑师资格以前，要通过七年的系统性学习，并且这些职业几千年前就已经存在了。

因此，架构师应该站在后进的立场上，持续不断的完善本身，成为一个优秀的合格的架构师。