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

一、软件架构师的定义

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

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

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

二、软件架构师的工作职责

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

2.1 需求分析

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

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

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

2.2 分解任务

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

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

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

当业务初期整个团队的需求理解并不那么透彻，可以将模块范围规划的大一些，避免过度拆分导致无法整合或整合的消耗过大，并不一定是越精细越好。当团队将业务理解透彻后，可以适当对模块进行重构，因为系统已具备较好的可扩展性，所以重构的工作并不会影响太大。

2.3 系统设计

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

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

架构师反复思考自己在这个阶段的每一个决策，有条件可以进行同行评审，利用团队的智慧弥补个人考虑不足的情况。因为一个小小的设计缺陷都有可能在研发阶段造成深远的影响。

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

2.4 非功能设计

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

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

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

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

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

2.5 技术债务管理

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

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

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

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

2.6 团队技能提升

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

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

技能的提升对于团队的成败将起到至关重要的作用。

另外，架构师也要参与到团队的研发过程中，可以通过编写模板、样例代码的方式与研发人员进行交流，如果时间不允许，最起码每周花费一天或者半天参加到研发团队中，了解架构的使用情况，有哪些优点和不足。

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

三、如何成为软件架构师

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

为了记录和评估是否是一个合格的架构师，可以建立一个项目工作档案表，来记录在项目中的工作。

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

答：

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

答：

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

答：

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

答：

如果重新做一次这个新项目，有哪些地方需要改进？为什么？

答：

这个表格可以随时增加，记录项目中的架构思维，当慢慢的对这些问题得心应手，就已经可以胜任架构的工作了。

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

四、总结

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

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

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

所以，架构师应该站在后进的立场上，持续不断的完善自己，成为一个优秀的合格的架构师。