
架构师:软件大厦中的能工巧匠
在这个由软件和人工智能驱动的时代,我们的日常生活与软件紧密相连。在这座软件世界的摩天大楼中,架构师就像是那些建筑大师,他们不仅精通代码的堆砌,更懂得如何用代码和逻辑的砖瓦,构建出既坚固又美观的摩天大楼,并且确保这些建筑能够经受时间的考验。本文将探讨在软件世界中,那些挥舞着键盘和鼠标的架构师们,是如何在构建软件的过程中扮演多重角色的。让我们以轻松的心情阅读,带着微笑思考,甚至不妨在会心一笑后提出您的宝贵意见。
需求分析(项目经理)
当一个新的工程项目启动时,项目经理首先需要明确项目的预算、工期和需求。在这个阶段,客观、理性、科学的分析至关重要。
项目经理需要根据事实和工期,与老板争取更多的资源,并确定合理的交付成果与工期。
- 幽默案列
老板:“我们要造一个电商大厦,最好和淘宝一样就行。”
小王:”老板,您预算多少?“
老板:”10万,不能再多了。1个月内完成。“
小王:”好的,收到,OKK,保证完成。“ 心里嘀咕到,只能用塑料和泡沫当建筑材料了(先去网上买一套或者去开源社区找一个来改改)
老板:”你到时候,把设计图纸给我看看?“
小王:”什么,还需要设计图纸?好的,没问题,转身就从网上找了个材料发过去。“
老板:”小王啊,质量和安全要保证,后续我们还要维保呢?“
小王:”OKK,没问题“
项目上线后:质量是不可能有质量的,安全性?扯淡。还要维保?做梦, 从单元测试,集成测试到性能测试是不可能有的。
二开?不可能的。没那技术和精力。直接删库跑路。
选址与技术选型(风水师)
当一个新的工程项目启动时,项目经理首先需要明确项目的预算、工期和需求。
在这个阶段,客观、理性、科学的分析至关重要。项目经理需要根据事实和工期,与老板争取更多的资源,并确定合理的交付成果与工期。
比如:
开发语言选择:是选择Java的稳定性和生态完整性,还是Python的灵活性?或者是被誉为世界上最好的语言的PHP?
数据库选择:是选择号称单表2000万行就不行的MySQL,还是功能更强大、扩展性更高的PostgreSQL?
消息队列选择:是选择号称会丢消息但速度极快的Kafka,还是最近很火的Pulsar?
每个选型都需要具体落实,以追求高效作为第一性原理
为指导。
例如,使用Java是否能够快速完成开发,后期更好维护?
MySQL是否真的单表2000万行就不行了?
Kafka为什么那么快,它的原理是什么,它真的会丢消息吗,它有哪些功能?
这些问题都需要深入研究。不要盲目听从,一定要深入原理,咨询专家,甚至查看代码实现,毕竟在源码面前毫无秘密。
设计图与架构图(建筑师)
建筑师用铅笔和尺子绘制设计图,而架构师则用代码和逻辑构建架构图。
这可不是随便涂鸦,每一笔都关系到软件的生死存亡。
如果图错了,那灾难是不可想象的。架构师在设计时应该具有非常高的技术前瞻性,秉着走``**先人一步**
的原则去设计。
在设计过程中,也不是一上来就是万亿级的流量、异地多活的灾备,而应根据实际情况和团队资源,因地制宜地绘制架构图。
图上的每个组件,它们的作用是什么,在什么场景下使用,它们的容错性如何,它们之间的交互协议和接口是什么,都需要仔细考量。
然后绘制线条与轨迹,说直白点,它就是一张数据流转的逻辑轨迹图。
当然,在这一过程中,架构师还需要预留一部分空地,以考虑系统的扩展性,来新增更多功能。其次,万一哪一天老板不满意,也可以尽可能降低替换的成本。
最后,架构师需要通俗易懂地与项目团队成员沟通和评审,确保每个人都明白自己在做什么以及如何做。
施工与管理(包工头)
如果把开发一个软件大厦比作一次小小的战役,那么架构师无疑是战场上的将军。
了解底下人的战斗力水平、技术水平和脾气秉性,是排兵布阵、用人之长的关键。
这样,即使遇到不断变化的需求,也可以灵活调整。遇到技术难题时,架构师的口号应该是:弟兄们,跟我上”(而不是“弟兄们,给我冲)
,带头冲锋,攻克技术难题。
不要心浮气躁地飘在“PPT”上,这里画个图,那里连个线,就以为事情解决了。真正落地开发时,会发现完全不是那么回事,有多难,需要花多少时间。
- 在开发的过程中:
首先架构师应该根据需求,以及架构设计,来合理科学的预估每个模块的工期,一定要预留一定的时间。(有时候,遇到一个问题,开发一解决就是好几天)
编写核心代码,制定代码规范,完成接口协议的设计,制定单元测试,集成测试,E2E 测试等,同时要和团队成员沟通,为什么这么做,以及这么做有什么好处。
其次架构师应该时刻关注项目的进度,发现搬砖慢的时候,可以封装一些轮子或者借助 AI 的能力来提升搬砖的速度。
最后需要针对每个功能进行验收,需要review代码,保持对质量的执着,
当对代码的理解不一致的时候,甚至需要自己亲自下场重构代码,然后再和团队成员进行沟通交流。
- 在管理沟通上:
好的技术团队其实是不需要管理的,古人说,文人相轻。其实程序员群体也是,他们不会因为你的 tilte,你的各种管理手段,
而是,他在跟你一起共事的时候,能学会什么,能有什么提高,才会真正组成一条心,才会真正的热爱这个事情。关于沟通上,对内你们是一个整体,一个 team,一定要把问题当面沟通清楚,让每个成员明白你的想法。对外,
一定要有自己的技术坚持,有自己的个性,当有不合理的需求,要及时的沟通,甚至是争论,确保项目在正轨上,不要让人觉得你是个
老好人,软柿子,当然也会给人一种,你不好沟通的样子。那又怎样呢,负责把项目办好就行。
交付与运维(物业管理)
现在大厦盖好了,怎样把房子安全的交互给业主,让业主住的安心呢?在这过程中,架构师应该扮演
物业管理的角色,应该明确以下事情:
文档
文档是整个交付过程中,最关键最核心的交付物。
首先得负责文档和知识的管理,确保所有重要的架构决策、设计文档和运维手册都被妥善记录和管理。
确保文档就像是一本食谱,即使换了厨师,也能做出一样的味道
。DevOps
试想一下,假如大厦有需要修缮或者零部件的配换的时候,
架构师们通过自动化持续集成/持续部署(CI/CD)流程,快速响应需求,持续迭代。
假如遇到了像电梯坏了这样的问题,除了考虑容错的策略,还需要考虑如何进行滚动,灰度的更新。可观测性
需要时刻监控和观测小区的运行状态。一定要做到该监控的地方一定要有监控,并且确保监控数据在需要使用的能够还原整个链路。
要提前预判系统风险,提前规避异常情况。
在这个充满变化的时代,架构师需要不断地学习新技术,适应新环境,解决新问题。同事也需要保持好奇心,对未知充满探索欲,对新技术充满热情。勇于创新,敢于尝试,不怕失败。这项工作充满挑战,但也充满乐趣。这次架构师同盟是一次思想的碰撞,也更像是一次英雄的会盟。借用英雄联盟(LOL) 里面易大师的台词:真正的大师,永远怀着一颗学徒的心
。希望各位架构师和致力于成为架构师的工程师们,为中国软件大厦添砖加瓦。