我认为大部分情况下是的。至少在我待过的几家公司里真正能把架构做好的人编码能力都不会差。目前我们公司也是这样,最难的几个模块基本都是我和另外一个技术高手一起完成的。为什么因为架构设计真不是靠画图靠开会的。基础框架怎么搭微服务怎么拆核心模块如何划分快速开发框架怎么设计到底用 Spring Cloud、Dubbo还是其他方案数据库怎么设计缓存怎么用消息队列什么时候引入这些都没有什么标准答案的而是各种权衡。需要结合团队能力、业务特点、系统规模、未来发展方向一点点做取舍。很多决定一旦做错后面改起来代价非常高。但还远不止如此架构定完以后你还必须亲自把最难的那部分做出来。这是很多人容易忽略的一点。因为如果架构师只负责画图和开会把核心模块交给别人实现那最后很容易跑偏。因为很多设计在 PPT 上是成立的真正写代码的时候才会发现这里耦合太高那里性能不够或者扩展性没有想象中那么好。只有自己真正把「核心链路跑通」才能验证这个架构到底行不行。如果发现问题也能及时调整而不是等整个团队都按这个方案开发了几个月再推倒重来。所以刚开始的时候架构师往往都会亲自下场。最核心、最复杂、风险最高的部分自己先做好沉淀出一套成熟的实现方式。后面的同学其实很多时候就是按照这套模式继续开发把业务不断填进去。这也是为什么一个优秀的架构师很少脱离代码。不一定每天写业务代码但一定要持续写代码。因为代码才是真相。很多架构方案脑子里想的时候感觉完美的不得了但只有真正写出来才知道到底是不是一个好方案。所以如果一个程序员连复杂模块都做不好只停留在 CRUD 层面我是不太建议过早去做架构设计的。因为很多架构上的判断本质上都来自于长期编码积累出来的直觉和经验。
