架构师：软件大厦中的能工巧匠

在这个由软件和人工智能驱动的时代，我们的日常生活与软件紧密相连。在这座软件世界的摩天大楼中，架构师就像是那些建筑大师，他们不仅精通代码的堆砌，更懂得如何用代码和逻辑的砖瓦，构建出既坚固又美观的摩天大楼，并且确保这些建筑能够经受时间的考验。本文将探讨在软件世界中，那些挥舞着键盘和鼠标的架构师们，是如何在构建软件的过程中扮演多重角色的。让我们以轻松的心情阅读，带着微笑思考，甚至不妨在会心一笑后提出您的宝贵意见。

需求分析（项目经理）

当一个新的工程项目启动时，项目经理首先需要明确项目的预算、工期和需求。在这个阶段，客观、理性、科学的分析至关重要。 项目经理需要根据事实和工期，与老板争取更多的资源，并确定合理的交付成果与工期。

• 幽默案列

老板：“我们要造一个电商大厦，最好和淘宝一样就行。”
小王：”老板，您预算多少？“
老板：”10万，不能再多了。 1个月内完成。“
小王：”好的，收到，OKK，保证完成。“ 心里嘀咕到，只能用塑料和泡沫当建筑材料了(先去网上买一套或者去开源社区找一个来改改)
老板： ”你到时候，把设计图纸给我看看？“
小王： ”什么，还需要设计图纸？好的，没问题，转身就从网上找了个材料发过去。“
老板： ”小王啊，质量和安全要保证，后续我们还要维保呢？“
小王： ”OKK，没问题“
项目上线后： 质量是不可能有质量的，安全性？ 扯淡。 还要维保？做梦， 从单元测试，集成测试到性能测试是不可能有的。
二开？不可能的。没那技术和精力。 直接删库跑路。

选址与技术选型（风水师）

当一个新的工程项目启动时，项目经理首先需要明确项目的预算、工期和需求。

在这个阶段，客观、理性、科学的分析至关重要。项目经理需要根据事实和工期，与老板争取更多的资源，并确定合理的交付成果与工期。

比如：

• 开发语言选择：是选择Java的稳定性和生态完整性，还是Python的灵活性？或者是被誉为世界上最好的语言的PHP？
• 数据库选择：是选择号称单表2000万行就不行的MySQL，还是功能更强大、扩展性更高的PostgreSQL？
• 消息队列选择：是选择号称会丢消息但速度极快的Kafka，还是最近很火的Pulsar？

每个选型都需要具体落实，以追求高效作为第一性原理为指导。

例如，使用Java是否能够快速完成开发，后期更好维护？ MySQL是否真的单表2000万行就不行了？ Kafka为什么那么快，它的原理是什么，它真的会丢消息吗，它有哪些功能？

这些问题都需要深入研究。不要盲目听从，一定要深入原理，咨询专家，甚至查看代码实现，毕竟在源码面前毫无秘密。

设计图与架构图（建筑师）

建筑师用铅笔和尺子绘制设计图，而架构师则用代码和逻辑构建架构图。

这可不是随便涂鸦，每一笔都关系到软件的生死存亡。

如果图错了，那灾难是不可想象的。架构师在设计时应该具有非常高的技术前瞻性，秉着走先人一步的原则去设计。

在设计过程中，也不是一上来就是万亿级的流量、异地多活的灾备，而应根据实际情况和团队资源，因地制宜地绘制架构图。

图上的每个组件，它们的作用是什么，在什么场景下使用，它们的容错性如何，它们之间的交互协议和接口是什么，都需要仔细考量。

然后绘制线条与轨迹，说直白点，它就是一张数据流转的逻辑轨迹图。

当然，在这一过程中，架构师还需要预留一部分空地，以考虑系统的扩展性，来新增更多功能。

其次，万一哪一天老板不满意，也可以尽可能降低替换的成本。

最后，架构师需要通俗易懂地与项目团队成员沟通和评审，确保每个人都明白自己在做什么以及如何做。

施工与管理（包工头）

如果把开发一个软件大厦比作一次小小的战役，那么架构师无疑是战场上的将军。

了解底下人的战斗力水平、技术水平和脾气秉性，是排兵布阵、用人之长的关键。

这样，即使遇到不断变化的需求，也可以灵活调整。遇到技术难题时，架构师的口号应该是：弟兄们，跟我上”（而不是“弟兄们，给我冲），带头冲锋，攻克技术难题。

不要心浮气躁地飘在“PPT”上，这里画个图，那里连个线，就以为事情解决了。真正落地开发时，会发现完全不是那么回事，有多难，需要花多少时间。

• 在开发的过程中：
  1. 首先架构师应该根据需求，以及架构设计，来合理科学的预估每个模块的工期，一定要预留一定的时间。（有时候，遇到一个问题，开发一解决就是好几天）
  2. 编写核心代码，制定代码规范，完成接口协议的设计，制定单元测试，集成测试，E2E 测试等，同时要和团队成员沟通，为什么这么做，以及这么做有什么好处。
  3. 其次架构师应该时刻关注项目的进度，发现搬砖慢的时候，可以封装一些轮子或者借助 AI 的能力来提升搬砖的速度。
  4. 最后需要针对每个功能进行验收，需要review代码，保持对质量的执着， 当对代码的理解不一致的时候，甚至需要自己亲自下场重构代码，然后再和团队成员进行沟通交流。
• 在管理沟通上：
  1. 好的技术团队其实是不需要管理的，古人说，文人相轻。 其实程序员群体也是，他们不会因为你的 tilte，你的各种管理手段， 而是，他在跟你一起共事的时候，能学会什么，能有什么提高，才会真正组成一条心，才会真正的热爱这个事情。
  2. 关于沟通上，对内你们是一个整体，一个 team，一定要把问题当面沟通清楚，让每个成员明白你的想法。 对外， 一定要有自己的技术坚持，有自己的个性，当有不合理的需求，要及时的沟通，甚至是争论，确保项目在正轨上，不要让人觉得你是个 老好人，软柿子，当然也会给人一种，你不好沟通的样子。那又怎样呢，负责把项目办好就行。

交付与运维（物业管理）

现在大厦盖好了，怎样把房子安全的交互给业主，让业主住的安心呢？在这过程中，架构师应该扮演 物业管理的角色，应该明确以下事情：

• 文档 文档是整个交付过程中，最关键最核心的交付物。 首先得负责文档和知识的管理，确保所有重要的架构决策、设计文档和运维手册都被妥善记录和管理。 确保文档就像是一本食谱，即使换了厨师，也能做出一样的味道。
• DevOps 试想一下，假如大厦有需要修缮或者零部件的配换的时候， 架构师们通过自动化持续集成/持续部署（CI/CD）流程，快速响应需求，持续迭代。 假如遇到了像电梯坏了这样的问题，除了考虑容错的策略，还需要考虑如何进行滚动，灰度的更新。
• 可观测性 需要时刻监控和观测小区的运行状态。一定要做到该监控的地方一定要有监控，并且确保监控数据在需要使用的能够还原整个链路。要提前预判系统风险，提前规避异常情况。

在这个充满变化的时代，架构师需要不断地学习新技术，适应新环境，解决新问题。

同事也需要保持好奇心，对未知充满探索欲，对新技术充满热情。勇于创新，敢于尝试，不怕失败。

这项工作充满挑战，但也充满乐趣。

这次架构师同盟是一次思想的碰撞，也更像是一次英雄的会盟。

借用英雄联盟（LOL)里面易大师的台词：真正的大师，永远怀着一颗学徒的心。希望各位架构师和致力于成为架构师的工程师们，为中国软件大厦添砖加瓦。