【架构的本质 01】老板问我：“咱们的架构师，还写代码吗？

原创已于 2025-12-25 20:40:36 修改 · 532 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-12-25 20:26:11 首次发布

5 篇文章

订阅专栏

在这里插入图片描述

前两天，公司老板找我闲聊，聊着聊着，他突然抛出了一个让我猝不及防的问题：

“咱们团队的架构师，现在还写代码吗？”

当时我愣了一下，露出了一丝尴尬又不失礼貌的苦笑。

这个问题看似简单，实则暗藏杀机。

这个尴尬的瞬间，其实暴露了软件行业一个普遍的认知错位：我们习惯用“搬砖的数量”来衡量“建筑师的价值”。

今天，作为本系列的第一篇，我想先抛开那些晦涩的技术名词，聊聊到底什么是架构师，以及他们到底该不该写代码。

为了讲清楚这个问题，我们得先跳出软件行业。

假设你要盖一栋摩天大楼。
你雇佣了一群技术精湛的工人，他们砌砖又快又直，抹灰均匀平整。在软件行业，这群人就是高级开发工程师。他们的核心价值是**“执行力”**——把设计图纸变成坚固的实体。

但是，如果没有设计图纸呢？
如果没有人计算楼体的承重结构，没有人规划排水管道的走向，没有人决定是用钢结构还是混凝土……这群工人干得越卖力，这栋楼倒塌得可能越快。

这个人，就是架构师。

在老板眼中，大家都在电脑前敲键盘，看起来大家都在“砌砖”。
但实际上，架构师的产出并不是“砖头”（代码行数），而是**“蓝图”和“决策”**。

所以，当你问“架构师写不写代码”时，就好比在问：“设计图纸的那个人，如果我不看见他亲自下工地搬砖，我是不是就亏了？”

如果不写业务代码，架构师的时间到底花哪儿了？

软件系统和物理建筑有一个最大的不同：建筑盖好就不动了，但软件是活的，它每天都在变。

随着业务需求的增加，功能越来越多，代码越来越复杂。如果没有架构师的干预，系统会自然地走向**“无序”和“混乱”——在物理学上，这叫熵增**。

体现在现实中，就是老板们最头疼的那些问题：

架构师的核心工作，就是对抗熵增。他在做三件看不见、但至关重要的事情：

切分复杂性（Structure）： 将一个巨大的混乱系统，切分成一个个边界清晰的模块。让开发A改代码时，绝对不会影响到开发B。
制定规则（Standard）： 就像城市规划师制定交通规则。规定数据怎么流转，接口怎么定义。没有规则，系统就是拥堵的十字路口。
做艰难的决策（Trade-off）： 这是最值钱的部分。是要“数据强一致性”还是要“高性能”？是要“快速上线”还是要“系统稳定”？架构师必须在两难中找到平衡点。

架构师不是在设计软件，而是在设计“未来的低成本修改能力”。
他帮你省下的，是未来可能高达数百万的重构成本和维护成本。

回到老板的那个问题。我的回答是：

“好的架构师必须写代码，但他绝不能只写代码，更不能写重复的搬砖代码。”

如果不写代码，架构师就会变成“PPT架构师”，设计的方案落地不了，变成空中楼阁；
如果整天写业务代码，架构师就变成了“也是写代码的”，失去了全局视野。

一个优秀的架构师，应该像五星级酒店的行政总厨。

他不应该去切土豆丝（写基础CRUD代码）： 这是浪费他的高薪，也剥夺了年轻厨师的锻炼机会。
但他必须研发新菜式（技术选型与验证）： 当引入一个新技术（比如Spring Cloud、AI组件）时，他必须亲自写原型代码（POC），验证可行性。
他必须制定SOP（核心框架与规范）： 他要写出核心的骨架代码，规定“回锅肉必须炒几下”，以此作为团队的标杆。
他必须解决突发事故（攻克技术难题）： 当厨房着火或者有重要客人投诉时，他必须能顶上去。

总结一下：

架构师写代码，不是为了完成工单（Task），而是为了验证决策（Decision）和制定标准（Standard）。