最近，小编在知乎上看到这样一个问题：
为什么大部分码农做不了软件架构师？
超过了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出来的技术专家 ，前微信架构师…
那些东西怎么说呢？ 凭一己之力，能想到那种程度，已经可以令人佩服了。反正臣妾是做不到。 但是用起来呢，他想到的那些，你写起来还算舒服。 如果碰上了他想不到的，那就只能各显神通了，十几个团队，几十个子系统，一开始大家还算规规矩矩，后来需求越来越复杂，渐渐开始乱来，最后一团乱麻，甚至公共服务已将没法兼容所有子系统了。然后大牛跑了，换一位大牛，推倒重来。
项目签了一年半的合同，最后做了五年，到我离职的时候还没交付。
我对软件架构的理解：
一个好的架构设计，不是要保持多久不重构，而是能不能以最小代价重构，快速重构，局部重构。 甚至重构以后绝大部分功能模块还能继续用。不要排斥重构，而是面向重构，鼓励重构。
一个好的架构设计，不是为了面向扩展，而做过度的抽象设计。而是刚好适应当前的业务需求。如果设计满足不了新业务，那就最大程度做好隔离。提炼出最小的不得不有交集的部分，单独封装。拓展的时候不怕重复代码，千万不能贪小便宜。新业务稳定以后，重构。
一个好的架构设计，不会强行要求风格统一。因为一种风格不可能适合所有业务模型。
一个好的架构设计，不应该是追求看起来多么高大上，而应该是求生欲极强的，一刀两断，两边都能活的那种。
-
“为什么大部分码农做不了软件架构师？”欢迎在留言区交流，留下你的观点~
整理丨dbaplus社群
来源丨知乎：https://www.zhihu.com/question/36658435
*仅为提供参考和学习交流，不代表dbaplus社群立场！dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
