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