阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 www.zhihu.com/question/36658435 「整理丨dbaplus社群」欢迎转载，保留摘要，谢谢！

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

最近，小编在知乎上看到这样一个问题：

为什么大部分码农做不了软件架构师？

超过了280W+阅读，引发了不少同行的共鸣。

秉持着和平交流的学习态度，小编精选了几位高赞知乎网友的精彩回答，分享给大家学习交流（勿上升、勿引战）：

1号知乎网友：上官人

我管过很多研发团队了，架构师见得非常多。

绝大多数回答根本搞错了方向，架构师只有10%，是因为我们只需要10%。

一个10个人的研发团队，只需要一个人每个月花几天时间想一想架构就够了。

一个50人以上的研发团队才需要一个专职的架构师。

10%的员工做架构都太多了，没那么多活给你。

工作和知识是相辅相成的，学一堆理论你得实践，没干过的几句话就问出来了。

没那么多需求，自然没那么多架构师——别抬杠，架构师培养起来真没多难，大团队架构师都是量产，很多人追求的完美的架构，其实在老板眼里能凑合用就行，根本没人关心。

2号知乎网友：暗灭

写代码和做架构是两个不同的事情。

一个系统中，如果拆解出来了很多模块，到底应该部署在哪些机器上？架构师会解决这些问题。

能Hold住团队里所有人的那个人，技术一定非常NB，团队里的每一个人，都会质疑，如果你Hold不住全场，怎么能推行下去？

近30的技术团队里，每一个都是神一样的存在啊，谁能Hold住30多个神。

架构师要做哪些事情，他就是要把这些大的骨架定好，然后我们去填充里面的内容，如果骨架定歪了，其余团队必然跟着歪。

3号知乎网友：游戏开发极客

架构师并不是一个很好玩的升级路线。

相对于架构师的开发工作。研发工作更有趣，更容易得到社会的承认，不论是图形学，还是人工智能，区块链，甚至骇客（网络安全），凭借你的智慧和努力，可以在短时间内取得成就，并达到一个很漂亮的高度。

而架构师不是，架构师拼的只有经验，正确的方法和项目数量。

4号知乎网友：知乎用户

我管过很多研发团队，架构师见得非常多。

绝大多数回答根本搞错了方向，架构师只有10%，是因为我们只需要10%。

一个10个人的研发团队只需要一个人每个月花几天时间想一想架构就够了。

一个50人以上的研发团队才需要一个专职的架构师。

10%的员工做架构都太多了，没那么多活给你。

工作和知识是相辅相成的，学一堆理论你得实践，没干过的几句话就问出来了。

架构师培养起来真没多难，大团队架构师都是量产，很多人追求的完美的架构，其实在老板眼里能凑合用就行，根本没人关心。

5号知乎网友：姚冬

架构师和程序员其实是两种不同的人，他们的思维方式有本质区别，虽然表面看上去他们都是懂软件技术会编写代码的

架构师很多是从程序员过来的，所以他们可以理解程序员思维，但是反过来就不一定了，程序员大多数不具备架构思维。

我们可以从一行代码开始，想象自己逐渐把镜头拉远，以便有更广阔的视野，可以看到全局。

代码==>函数==>算法==>逻辑==>模块==>框架==>功能==>应用==>产品==>服务==>业务==>企业==>行业==>产业链==>经济体==>人类社会==>星辰大海

每递进一个层次，涉及的规模都要扩大几个数量级

架构师主要工作在模块到应用之间，程序员主要工作在代码和模块之间，应用到产业链是企业家的工作范围，业务到经济体则是金融家资本家的领域，经济体之上是政治家的事情。

架构师首先要有更广阔的视野，能从代码看到经济体，然后再聚焦到模块和应用之间，对下规划代码函数到模块的设计，对上为产品服务提供支撑。

架构师需要的能力主要是设计能力，这里的设计不是指算法逻辑的设计，更不是代码语法函数参数的设计，要解决的问题不是算法精度或者运行性能，而是研发体系的效率，质量和成本。

再次强调，架构设计是用来解决研发体系的效率，质量和成本问题的。

架构师是通过对模块，框架的设计，参与制定研发体系流程，从而获得更高开发效率，更高交付质量和更低研发成本。

大部分人做不了架构师，不是因为他不够聪明勤奋，也不是因为他代码写得不够好不够多，而是因为他的思维方式思考的维度不对，没有建立架构思维，还停留在程序代码思维层次。

6号知乎网友：九章算法

真不是不想学，主要是大多数程序员根本就没有做架构的机会！

假设你在某知名电商公司干过高并发系统，用户上亿，一天流量几十亿，高峰期并发量上万，甚至是十万，那之后你去找个架构师的工作不成问题。

但能在某知名电商公司工作的程序员有多少?能接触到高并发系统的又有多少?

随之就进入了一个死循环：进不了大厂，积累不了高并发的工作经验;没有高并发的工作经验，面试又过不了，有没有高并发项目经验直接把程序员分成了两个互相绝缘的圈子。

没有实战过的项目经验就像一盘散沙，面试官一问，就全散了。

7号知乎网友：黑白花的猫

没做过架构师，但是码过几个所谓“大牛” ，架构出来的东西。title一个个都吓死人，什么baidu出来的技术专家 ，前微信架构师…

那些东西怎么说呢？ 凭一己之力，能想到那种程度，已经可以令人佩服了。反正臣妾是做不到。 但是用起来呢，他想到的那些，你写起来还算舒服。 如果碰上了他想不到的，那就只能各显神通了，十几个团队，几十个子系统，一开始大家还算规规矩矩，后来需求越来越复杂，渐渐开始乱来，最后一团乱麻，甚至公共服务已将没法兼容所有子系统了。然后大牛跑了，换一位大牛，推倒重来。

项目签了一年半的合同，最后做了五年，到我离职的时候还没交付。

我对软件架构的理解：

一个好的架构设计，不是要保持多久不重构，而是能不能以最小代价重构，快速重构，局部重构。 甚至重构以后绝大部分功能模块还能继续用。不要排斥重构，而是面向重构，鼓励重构。

一个好的架构设计，不是为了面向扩展，而做过度的抽象设计。而是刚好适应当前的业务需求。如果设计满足不了新业务，那就最大程度做好隔离。提炼出最小的不得不有交集的部分，单独封装。拓展的时候不怕重复代码，千万不能贪小便宜。新业务稳定以后，重构。

一个好的架构设计，不会强行要求风格统一。因为一种风格不可能适合所有业务模型。

一个好的架构设计，不应该是追求看起来多么高大上，而应该是求生欲极强的，一刀两断，两边都能活的那种。

“为什么大部分码农做不了软件架构师？”欢迎在留言区交流，留下你的观点~