在InfoQ-StuQ的采访中，选择了大家可能感兴趣的部分问题，总结了这篇文章。
问题：“架构师到底应该写代码吗？ ”的讨论在网上。 你对这个怎么看？
我觉得我的旗帜很鲜明：
架构师应该写代码。
做体系结构设计需要了解业务，任何脱离业务的体系结构设计都是流氓。
我反对一家公司设立所谓的架构师部门，管理整个公司的所有架构师资源。 我建议的是
每个商业研发团队都有自己的架构师
深入了解业务，针对业务特点设计系统架构。
静音：没有适用于所有业务场景的体系结构方案。
要贴近系统，必须看代码，写代码。 即使完全没有时间编写代码，至少所有详细设计的细节架构师都应该清楚。 代码审查也非常重要
代码保证至少有两个人看到了
而且，其实现逻辑和详细设计是一致的。
我对架构师的建议是：
如果有时间，我自己去写核心代码。 如果没有时间，我们将检查详细的设计，并派遣资深工程师前往代码审查。
问题：现在网络技术更新非常快，你认为修订者应该对此采取什么态度？
首先，我个人的观点是：
对于新技术，需要关注、学习、研究，但在网上应用需要谨慎。
以回家走狗的技术体系、存储为例，选择了很多选择，MySQL最成熟，我们就用它。 统一非常重要。 一定
我不知道哪个队想用什么
统一可以节约很多招聘、运维、测试成本，遇到问题可以通过参考社区资料，与行业牛人沟通迅速解决。
问题：架构师的知识范围似乎很广，有什么都知道、什么都不精致的现象吗？
首先什么都知道是绝对不可能的，什么都精益求精也是绝对不可能的。
虽然业务不同
架构设计的想法一定有共同点。
我个人的例子是，我做过几百万个同时在线的即时通讯工具。 它一定在体系结构领域有一些共同的东西，比如访问、数据、可用性、可扩展性和一致性，所以这些经验在我之后有助于设计推荐系统、支付系统、出租车系统等等。
架构师要求知识的广度和深度。 我心中合格的架构师，是的
“型人才”
除了技术宽度，还有两条腿。 一瓶呢
特别项目的深度
另一个是
通用能力
表达、交流、解决问题、创新等。
问题：以修订者为目标的人中，有很多人不知道怎么开始吗？ 笑着的鸡翅能给我更具体的建议吗？
架构师的道路是
三个阶段
：
第一阶段是做好基本功的阶段。
应对我自己是职业生涯的头三年。 无法做好语言、数据结构、算法、设计模式、研发工具、调试工具等基本工作。 其他一切都是空谈。
第二阶段是业务深度和技术深度的积累。 对我来说，业务的深度是职业生涯头五年在即时通讯领域的战斗。 业务的深度决定了进入某家公司时你的价格。 一家公司要解决某个业务问题，必须明确招聘相关人才
能解决某个业务领域的大部分技术问题是你的核心竞争力。
外音：核心竞争力不是Java工程师，而是XX工程师。 (XX是业务前缀，如即时消息。 很多技术人员容易偏向。
第三阶段，型人才的另一条腿，即共同素质。 是你的执行力、责任感、推动力、沟通表现力、项目管理力。 这些被认为是你可以信赖的。
在技术力量都一样的情况下，为什么要把一件事交给你？
因为公司认为你很可靠，所以评价很高。
问题：没有完美的体系结构。 好的体系结构有什么标准呢？
体系结构为业务服务，
能够满足业务需要
然后，那个
让我们进一步思考一下它的可扩展性
我认为这样的框架是合适的。
画音：多思考一步，请注意不是两步，不是五年后。
我曾经说过：“快狗打车从14年发展到现在，架构重叠了很多版。 如果回到14年重新进行架构设计，那个架构会变成现在的样子吗？” 答案一定和今天不一样，一定还和14年的时候一样，那个时候的架构，适合那个阶段。
体系结构不仅是设计的，也是进化的。
问题：很多技术人员都很关注公司的技术氛围，你在营造技术氛围方面有什么经验？
让我列举几点：
第一，领导机制很重要。 任何技术人员都一定有高水平的人带来，不管有什么技术问题一定有人能交流解答。
第二，技术评审很重要，技术评审是沟通和讨论技术问题的良好契机。
第三，共享机制很重要，在各个团队内定期组织技术共享，让大家沟通。
包括我在内每周花时间和团队同学进行技术交流和沟通。
问题： PHP是世界上最好的语言吗？
技术同学在讨论时要避免讨论两个问题。 一种是哪个语言是世界上最好的语言，另一种是应该避免讨论
Vim好还是Emacs好。以上纯属
个人看法
，分享自己认为对的东西。
调研：
(1)贵司是
ppt型
架构师，还是
代码型
架构师？
(2)贵司是
深度型
架构师，还是
广度型
架构师？
(3)贵司是
针对业务
的架构设计，还是
针对晋升
的架构设计？
(4)贵司有没有
指导人
？
评审
？
分享
？
最后给有志于成为架构师的同学一个建议：
多学习、多交流、多沟通
。
求助
：
这篇10W+还差一点，求转发，谢谢。
画外音：很想吹吹牛，说我是写过10W+的人。