[转]架构师不是管理者，是领导者

俗话说：不想当架构师的程序员不是好程序员。成为架构师，几乎是每位开发者入行初期的共同理想。但架构师并非只是一个单纯的技术岗位，它需要技术能力与综合能力的共同支持。了解架构师的职业定位与主要职责，掌握架构师所需的核心技能，是通往这一高阶职位道路上的必修课。

T·TALK：在您看来，架构师的职业定位与核心职责是什么？

史海峰：

架构师的本质是更高级更资深的工程师，架构师的能力要求在工程师之上，一些大厂层级较多，架构师成了一个职级，高级工程师跳槽到小厂做架构师也是游刃有余。所以并不需要纠结工程师或架构师的边界到底在哪里。

我倾向于认为架构师是一个角色，在足够复杂、规模较大的系统才需要的角色，当系统架构不那么一目了然时，需要有人在更高的视角上去关注系统的整体。且架构师是高阶职位，难以通过培训批量生产，在能力方面更多的需要依赖于个人工作经验的积累与一些软性技能的支撑。

架构师的核心职责，是系统设计和实现的最核心的工程师，用七句话总结我对架构师职责的定义：

1. 以工程思维全面理解业务需求
2. 基于模型和基础模式抽象简化
3. 提出恰当可行的整体解决方案
4. 在限定资源范围完成明确目标
5. 满足业务需求且保证系统质量
6. 在可预见的周期内具备扩展性
7. 并在系统生命周期内持续演进

T·TALK：架构师需要掌握的的核心技能都有哪些？

史海峰：

借用李智慧老师《大型网站技术架构：核心原理与案例分析》中的说法：

软件架构师的最大价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成 N 个低耦合的子模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验，还有一部分源自于架构师对业务场景的理解、对人性的把握、甚至对世界的认知。

在技术团队中，架构师是技术领导者，要对最终设计和实现负责。多数情况下，架构是一种妥协、平衡的产物，掌握这个平衡度的，就是架构师。我们都知道，理想的架构是什么样的，但又必须有所取舍，面对现实，提出可行方案。因此，架构师应当是胸怀理想的现实主义者，高度在理想，落地在现实。

以个人经验来讲，架构师需要具备五方面的能力。

1. 全面的专业能力和经验，包括技术能力和业务能力
2. 自我驱动能力
3. 高效学习能力
4. 保持良好心态
5. 善于沟通协作

一个合格的架构师，需要拥有很强的综合能力，不能有明显的短板。其中技术能力和业务能力属于硬指标，可以通过学习和工作，跨过行业门槛获得。而后四种能力，则可以称为通用技能，或是软技能、软素质，对于团队协作的技术职位都是需要的。

自我驱动、高效学习与保持良好心态是内功，用汽车比喻的话，自我驱动能力相当于发动机，高效学习能力则是方向盘和变速箱，良好心态就是汽车悬挂和制动系统。沟通协作则是外功，是最重的外在体现。架构师并不是一个人在战斗，闭门造车是不可取的。而且架构师不是管理职位，在工作中更多充当领导者的角色，需要让大家了解你的想法，需要团队通力合作共同完成目标，这都是要靠沟通的。

T·TALK：作为一名架构师，您是如何理解系统架构的？

史海峰：

杰拉尔德·温伯格的《系统化思维导论》中提到过：系统是对世界的一种看法。而世界是多元的、世界是有机的、世界是变化的，并且世界并不完美。通过这个逻辑引申一下，架构其实就是对系统的一种看法。

以人为例，我们可以认为人也是一个复杂系统，生命则可以理解为一个信息处理器，但不同的学科和理论体系对人的认识是不一样的，比如现代医学区分神经系统、循环系统、消化系统等等，传统医学讲究阴阳五行五脏六腑。我们每天都和别人交流，别人说的话就是各种信息，我们的回应便是输出反馈。架构不仅仅是静态的视图，还包含了整个系统的实现过程，所以要面向未来。架构设计需要能够化繁为简，将架构进行抽象，当然这个过程中每个人的理解是不一样的，很难用一句话去总结。

在这个思路上继续扩展，无论面对软件还是硬件，都可以将其拆解为时间与空间，并对其进行时空的转换，时间换空间，空间换时间，是在进行架构设计时最常见的做法，这其中并没有严格的界限。最终架构设计还是要以人为本，需要更多思考系统的用户是谁，维护者是谁，在不同场景之下系统将会对他们产生怎样的影响。深入了解业务及需求，才能找到架构设计的最优解决方案，因为我们的时间与资源都是有限的。

还需要补充的一点是衡量系统架构的标准，一个好的架构首先要满足需求、性能优良、实用友好，满足使用者是架构设计的最核心目标。其次，需要做到的是结构合理、设计简洁、成本可控，这几项则更多地涉及到系统的开发效率。最后，稳定健壮、易于维护、易于分解同样是优秀架构不可或缺的，举个最简单的例子，在一个系统中使用不同的命名规则和接口规范，可能会导致很严重的后果。实现这些要求，才能使系统拥有更高的上限。

T·TALK：在您做架构师的过程中，发生过哪些令您印象深刻的事件？

史海峰：

有两件印象比较深刻的事情。首先是去当当面试的时候，那时并不知道互联网企业具体是什么样的，对架构师的概念也不是很清晰。当被问到如何解决错误订单问题时，我没有在技术栈方面做过多纠结，而是依靠在亚信处理相似场景的经验，从系统整体角度出发，给出了恰当实用的解决方案。这件事给了我很大启发，让我对架构以及架构师的职责有了更深刻的认知。

其次，是在加入当当一年多后，和另一位架构师赵振林共同完成了一张当当的整体架构图，将所理解的 100 多个系统都串联了起来。虽然其中肯定是有遗漏甚至错误，但通过这张图，我成功验证了自己对当时公司整体架构的理解。这也让我意识到，做架构师同样是需要输出的，自我感觉并不是总能靠得住，需要通过文字、图案等一些方式将自己所了解的表达出去，并对自己的认知不断进行校正。

T·TALK：在敏捷开发流行的今天，架构师该如何确保开发设计的质量呢？

史海峰：

我们曾经讨论过这个问题，甚至讨论敏捷的模式中是否需要有架构师，因为敏捷似乎是每次只解决一个问题，但如果只看眼前而忽略长远，一定会出更大的问题。人无远虑必有近忧，架构是演进的，目标不是自己说了算。变化越快的系统，其腐化就会越快，几年之后就很可能会面临重构。重构的同时，原有系统要迭代，然后并行，再切换掉，重构需要做架构设计，而且要尽可能有前瞻性，帮助团队甩掉技术债，避免保留原来的局限。想要确保质量，日常迭代便要把握原则，就算敏捷也要做方案评审，做 CodeReview ，该做性能测试做性能测试，该监控监控，该复盘复盘，确保把基本动作做到位。说回来，敏捷开发对团队整体能力要求更高，每个成员都要对业务目标、架构原则、开发流程、协作机制有充分的认知，才能真正跑得又稳又快。

T·TALK：最后，能否从架构师的角度，给有志于此的开发者提供一些建议。

史海峰：

先抛个梗，架构设计是一门艺术，架构师作为架构设计的实践者，要掌握四门功课：多打酱油，能和稀泥，肯背黑锅，敢拉仇恨。

前面提到过没有完美的架构，只有合适的架构。技术同学在工作中容易理想主义，不考虑 ROI，废寝忘食熬夜加班。但我们做的是工程，时间资源是有限的，要能够在有限时间内交付符合预期的成果。因此，怎么能在复杂的系统里化繁为简，举重若轻，找到最简单有效的解决方案，是做技术的同学应该更多思考的问题。最终我们要靠实践获得反馈，靠成果积累经验，简单一句话，光说不练假把式，光练不说傻把式，能说会练真把式。

关于工程师、架构师的成长，我写过一些文章，大家可以到我的公众号“IT 民工闲话”上搜索“工程师”和“架构师”关键字，可以进一步交流，共同成长。

疑难解答：架构设计的框架如何选择？

史海峰：

架构设计的框架有很多，比如付晓岩老师在《企业级业务架构设计》开篇有介绍，但无论哪个体系，都是方法和手段，我们不能被体系所限制。应当更多地去了解其中的思维模式，初步了解并不会花费太多的时间。当我们对大部分体系都有所理解后，才能够更准确的选择出最能够帮助到你且最适用于你目前工作的架构体系，而后再去对其进行深究。

疑难解答：架构师需要有产品经理的经验么？

史海峰：

是否具备产品经理的经验并不是关键因素。从个人发展的角度讲，在初入职场的时候，只要把本职工作做好就可以了。而在三五年后，则需要考虑差异化竞争，发挥自己的专长，这需要对某一领域进行深耕，成为领域内的专家。接下来要发挥更大价值，则需要与更多相关角色打交道，要能够换位思考，对不同角色工作的方式与输入输出有感性的认知。架构师要知道团队中每一个角色的关注点是什么，不只局限于自己擅长的领域，要让整个团队都能够了解你的设计思维，这样才能使团队拥有更好的配合度，形成合力。

 

 

 

Refer

“IT民工”史海峰：架构师不是管理者，是领导者