架构师该不该写代码？ —— 兼谈技术领导力的“后勤保障”模式

引言

“架构师要不要写代码”是个永恒话题。笔者坚定属于**“写代码派”**，但非指包揽核心模块开发，而是将写代码视为一种**“后勤保障”**手段，通过适度参与保持技术敏感度、及早发现设计落地偏差、引导团队最佳实践。

为什么架构师要写代码？

1. 设计与实现的“最后一公里”偏差

架构图很美好，但代码实现中充满细节魔鬼。合格程序员能按任务完成功能，但未必能准确理解架构意图，或在遇到阻碍时做出优雅决策。常见“烂代码”多非架构设计问题，而是落地偏差：

• 为“解耦”而复制粘贴耦合代码；
• 为“性能”将所有逻辑塞进单一函数；
• 缺乏抽象，重复造轮子。

若架构师不触达代码，这些问题将演变为“正确的错误代码”，最终成技术债黑洞。

2. 后勤保障视角的代码参与

架构师写代码不是当“超级程序员”，而是做三件事：

1. 巡检与预警：Code Review、随机抽查、关键路径亲测，第一时间发现反模式。
2. 示范与引导：核心脚手架、通用组件、疑难杂症示范实现，建立“正确姿势”标杆。
3. 工具链建设：编写代码生成器、静态检查规则、自动化测试基础设施，以工具固化规范。

3. 保持技术判断力

脱离一线代码半年以上，技术判断力会显著退化（选型偏向 PPT、忽略落地坑、无法评估重构成本）。写代码是维持“手感”最高效方式。

怎么写？—— 适度参与原则

• 不抢核心业务模块：架构师时间碎片化，无法保证深度专注，硬上反而拖累进度。
• 聚焦高杠杆代码：框架封装、基础设施、疑难攻关、Code Review 修复示例。
• 时间箱控制：每周固定 20%-30% 时间写代码/Review，其余精力用于架构演进、沟通协调、人才培养。

架构师与程序员：像产品经理与用户

程序员往往不会主动表达痛点（甚至自己都不知道），就像用户不会直接告诉产品经理要什么功能。架构师若不“跟用户做同一件事”（写代码、部署、排查线上问题），就无法共情其痛点，做出的决策必然悬浮。

结语

架构师写代码，**不是为了产出业务功能，而是为了产出“技术治理”的杠杆**。以“后勤保障”心态适度参与，既能守住技术底线，又能赢得团队信服，是技术领导力的成熟表现。