为什么大部分码农做不了软件架构师？
小团队一般 10 人左右，其中常常是技术最牛的人做架构师（或TL）。所以，架构师在广大码农中的占比大概平均不到 10%。而架构师也可以分为初级、中级、高级三档，江湖上真正高水平的软件架构师就更少了。
所以，大部分（超过九成的）码农干上许多年，还是做不了架构师，这是什么原因造成的呢？
说一点点吧。抛砖引玉下。
应该说不是大部分码农做不了架构师，是不具备特定思维方式的码农做不了架构师。
如果说码农，程序员考虑问题的出发点是功能，算法，业务等这些基于需求基础上提炼的功能逻辑。那么架构师必须要考虑非功能性需求。
方便部署，方便扩容，方便监控，方便构建，方便功能切分，方便支持多平台，方便集成，方便写代码等等，这些都是非功能性需求。非功能性需求还有很多，但基本上很多都是来自于技术和管理的边界。
往右是管理范畴，往左是技术范畴。
架构师的最大作用就是把技术边界往外推，不断侵入管理领域，让技术取代和优化人工管理。
换句话说，当程序猿们开始意识到人的因素的时候，并试图通过技术去影响组织结构，设计人员工作流程等等这些问题的时候，他已经开始上路了。
前几天，我在一个微信群里有人发了个技术架构问题，大家聊了一个中午。在讨论过程中，有人提了一句，大题意思是“这不一定是技术问题，这可能是技术管理问题，或者就是管理问题。因为这可能是一个技术边界”
可能就具体作用来说，基础架构师，业务架构师 前端架构师等等各有领域，但非功能性需求一定是需要考虑的。
就写这点吧。谢谢
作者：丁长老
链接：https://www.zhihu.com/question/36658435/answer/774719904
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
链接：https://www.zhihu.com/question/36658435/answer/773216376
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
我是野生构架师，
在某些方面可能是中国最顶级的，
比如说年龄和工作总时长。
20年的编码经验，基本都在架构上工作。
2010年左右出版过架构方面的著作。
架构师并不是一个很好玩的升级路线。
相对于架构师的开发工作。研发工作更有趣，更容易得到社会的承认，不论是图形学，还是人工智能，区块链，甚至骇客（网络安全），凭借你的智慧和努力，可以在短时间内取得成就，并达到一个很漂亮的高度。研发方面是拼年轻，智商和体力的工作，有众多的天才少年取得漂亮的成果，每年有大量新的技术突破和文献等着大家研究。你做的每一件事情，都能表现出漂亮的成果，全局光照，计算机视觉。或者很容易赚到很多的钱，自动驾驶或者区块链ico，就算做游戏外挂，其收入也大得超乎你的想象。
而架构师不是，架构师拼的只有经验，正确的方法和项目数量。《C++程序设计新思维》里面有一句话：“只有天才的程序员没有天才的构架师。” 在构架师的世界里不存在天才，只存在重构。一定要有正确的方法（敏捷开发），然后就是无数个项目和时间的铺垫。然而对一个架构师应该明确，我们的职责是内部质量而不是外部质量，我们要把软件做的强壮且易易扩展。但你会发现，对于外行麻瓜来说，这根本不吸引人，麻瓜老板经常说一句话：你功能做不出来我们公司就破产了，别他妈的再花时间重构了。
至于为什么架构师很少
内部原因是：架构师太无趣了，相对于图形学光照算法，你却强调测试驱动重构持续集成。研发工程师会得到大量的外部激励，所有人都去赞扬他们的成果。而构架师需要从自身产生激励的能量，比如对代码的洁癖，重构在不改变功能的情况下不断优化代码质量，一个分层，一个正确的依赖关系，甚至一个精简美丽的命名，都需要由衷地感到兴奋和刺激。否则很难熬下来。
外部原因是：浮躁的社会容不下一个架构师成长的时间和空间。一个框架师需要大量的项目经验，超级长的编码时间。坚持正确的方法和一个融洽配合的团队。国外的架构师都是大胡子，而国内程序员到30岁，老婆就催着要去做管理岗位了。和研发工作拼智商不同，架构师就拼的是经验，没大胡子没五六十岁很难成为xx之父这个级别。
行业原因是：架构师容不下架构师。架构是艺术不是科学，没有一个统一的标准，每个成型的架构师心里都有一套属于自己的程序结构和原则，你可以看到十个图形学程序员基于一个算法合作，但你很难看到两个架构师做一个项目不打架的。架构师需要有自己的团队来验证自己的观点和共同进步，但就如同食肉动物永远是食草动物的十分之一，行业也没那么多团队给架构师来糟蹋。
经历过很多项目洗礼，并有自己的想法和能力的架构师，必然是稀有动物。
但看起来无聊的架构师有什么用呢？
他是辅助英雄，给整个团队加各种属性光环：降低代码中的混乱（熵），让团队中初级的程序员做出高级的代码，提高单位时间效率避免加班，让团队更容易进入未知领域，大幅度降低企业成本。
我现在做的混合现实领域，这是一个新的领域，有一个优秀的架构师可以在没有前人经验的情况下开疆辟土，并且可以带起来整个团队的开发质量，降低成本给客户更多的获利空间。
最后关于我：
我是游戏行业的，我毕业的公司的老总是opengl发明人，我当时的老大是国内图形学的顶尖人才。但我却选择了构架的方向。
我很幸运，2006年开始自主创业，虽然一直没赚到钱，但是有一个环境容我慢慢的成长，有一个流水的团队提供给我消耗。我可以坚持敏捷开发，在整个行业996的情况下坚持周40小时工作制（极限编程）。
但其实这十几年的工作创业编码经历我是充满了自我怀疑的，是不是我的方向错了？我做的软件结构是否是合理的？
其实我有个缺点就是没有经历过架构师的正统训练，心里面并没有一些成型的架构模型。
每次我在外面碰到自己同期的程序员，我都问下：你还在写程序吗。他们的回答都是：哦，我现在已经在做管理了/我已经财务自由了/我已经交给年轻人了。 这时侯，我知道我在构架师的排行榜上又提高一名。
直到有一天，我发现我做的项目比别人都多，我编码的时间比别人都长的时候，我就知道我已经成为了中国最好的野生架构师。只要有测试驱动和重构护体，并不需要有太多的架构模型限制，在一些新了领域（没有已有的架构例子）反而更有优势。
所以我决定继续增加自己的编码经验来巩固自己的地位。
我在办公室编码，
我在家里卧室编码，
我在酒店编码，
我在地铁上编码，
我在机场候机楼里编码，
我在儿童游乐场编码。
我知道，
只要我用正确的方法，
足够多的编码，
那么我就是拥有架构师最好的身法。
你有没有注意到上面三句话加上这句都是双押。
补充下，架构师是否需要天赋
评论里面有人提出了这个问题，架构师是否需要天赋，答案是既是也不是。
这里涉及了一个概念，大天赋和小天赋。（出自游戏设计艺术第二版，小弟不才，做了这本书中文版的校审）
所谓小天赋，就是我们经常说的天才，天生具有某项适合的能力，比如身高和篮球，速度和跑步。与生俱来的能力。
而大天赋，指的是热爱一个事业，愿意投入更多的时间去享受工作的乐趣。
显然，架构师是需要大天赋的。
至于小天赋吗，对于架构师就没有那么重要了，极限编程之父贝克曾经说过，我不是天才，我只是使用了正确的方法。看了他的测试驱动就知道，使用正确的方法会迭代出优秀的代码和架构的。（说过类似的话的还包括Andrei Alexandrescu：只有天才的程序员，没有天才的架构师。）
所以正确的方法对于架构师是第一重要的能力。
但这样就足够了吗？
我曾经以为用正确的方法一个新入行的人也可以写出高质量的代码，但是事实上并非如此。
是什么限制了初学者的编码能力？
是味道。是我们经常说的“代码好的味道和坏的味道”的区分，如果不能很快的分清楚这点重构和测试驱动都会大打折扣。当然我们有代码设计原则，设计模式，重构的方向。但要快速的确定代码的优势和缺陷，就需要一个非凡的能力——品鉴代码味道的能力。
品鉴代码味道的能力 —— 需要大量的编码经验的支撑。
所以一个优秀的架构师，需要=正确的方法+大量的经验。
进一步说=开放的心态大量阅读+持之以恒的编码工作（我认同只单纯编码是没有办法提高能力的，我见过写的很烂的老代码师）
所以回归主题，大天赋对于架构师极其重要，就是热爱编码工作本身（而不仅是带来的金钱和荣誉）。这样你才可以快乐地阅读和吸收，愉快的编码和总结经验。让你成为真正的架构大师。
而小天赋呢，留给那些做算法的年轻人吧，你拼不过他们，也没必要去拼，你是构架师，是修路搭桥的人，清理了路障，让那些天才们在上面飞奔。
因为大部分中小型软件（项目）只谈功能，不谈架构。
一个初创的互联网企业，起步往往就是公众号+APP，运营一年下来用户也就几万最多几十万，日活才几千，没有性能问题，也没有很多子系统，于是既没有技术架构，也没有业务架构。
这种系统开发的唯一难度是需求，代码方面说个不好听只要参考书上Hello world的例子绝对够用，至于数据库，用SQLServer就能满足。
如果这个企业长不大，这里面的开发人员就没有通过业务实战架构的机会，如果这些开发人员换了工作还是搞小项目，就一直没有搞架构的机会，怎么可能成长为架构师。
我接触过的架构师，基本搞大型项目练出来的，从业务说，大项目从业务需要接十几个到几十个网元（子系统），业务逻辑结构非常复杂，所以需要梳理业务架构；从技术说，动不动就是几千万用户量，几十万的并发数，所以需要技术架构。
遇不到敌人，自然变不成老兵。
浙公网安备 33010602011771号