提问：网上有个很有争议的问题“架构师到底该不该写代码？”，您对此怎么看？我旗帜鲜明的认为：架构师应该写代码。
做架构设计需要了解业务，任何脱离业务的架构设计都是耍流氓。
我比较反对一个公司成立一个所谓的架构师部门，把控全公司所有的架构师资源。我建议是每个业务研发团队都自己的架构师，深入了解业务，针对业务的特点去设计系统架构。
画外音：没有一个架构方案，适用所有的业务场景。
要贴近系统，所以得看代码，写代码。即使完全没有时间去写代码的话，至少详细设计的每一个细节架构师都需要清楚。CodeReview也非常重要，
保证代码至少是有两个人看过
，而且它的实现逻辑和详细设计是一致的。
我对架构师的建议是：
有时间的话，亲自去写核心代码，如果没有时间的话，要把关详细设计并安排资深工程师去做CodeReview。
提问：当前互联网技术更新非常快，您认为架构师对此应该持什么态度？
先说个人观点，我认为：
对于新技术，需要去关注，学习，研究，但应用到线上，一定要慎重
。
到家集团、快狗打车的技术体系，拿存储来举例，选择很多，MySQL最成熟，我们就用它，统一非常重要，一定
不能是哪个团队想用什么就用什么
，统一能够节省很多招聘、运维、测试成本，遇到问题能够查阅社区资料，通过行业牛人沟通快速解决。
提问：大家觉得架构师的知识宽度是很广的，那会不会有什么都懂、什么都不精这样一种现象存在？
首先什么都懂是绝对不可能的，什么都精也是绝对不可能的。
虽然业务不一样，但是
架构设计思路上肯定会有通用的地方
。
以我个人为例，曾经做过几百万同时在线的即时通讯系统，它肯定有架构领域内通用的东西，比如接入、数据、可用性、扩展性、一致性等，所以这些经验对我后面做推荐系统的设计，支付系统，打车系统等，设计思路上有很大的帮助。
架构师对于知识的宽度和深度都是有要求，我心中合格的架构师，是
“π型人才”
，除了技术宽度，还要有两条腿：一条是
专项深度
，还有一条是
通用能力
，比如表达、沟通、解决问题、创新等。
提问：有很多立志于成为架构师的人不知道如何开始？沈老师能不能给一些比较具体的建议？
我认为架构师之路分为
三个阶段
：
第一阶段，是打基本功的阶段。
对应我自己的话就是职业生涯的前三年，语言、数据结构、算法、设计模式、研发工具、调试工具等，基本功没打好，其他的一切都是空谈。
第二阶段，是业务的深入与技术深度的积累。对于我来说，业务的深入，是职业生涯前五年在即时通讯领域的打拼。业务的深度决定了进入一家公司的时候，你的身价，一个公司要解决某个业务问题，就必须有针对性的招相关的人才，
能够解决某个业务领域内的大部分技术问题，才是你的核心竞争力
。
画外音：核心竞争力不是Java工程师，而是XX工程师（XX是一个业务前缀，例如即时通讯），很多技术同学容易走偏。
第三阶段，π型人才的另外一条腿，即通用素质。就是你的执行力、责任心、推动能力、沟通表达能力、项目管理能力，这些会让别人觉得你是靠谱的。
在技术能力大家都差不多的情况下，一个事情为什么交给你来做？
因为公司觉得你是靠谱的，靠谱这个评价很高。
提问：没有完美的架构，那好的架构有一个什么样的标准呢？
架构是为业务服务的，
能够满足业务的需求
并且
对它的扩展性多考虑一步
，我觉得这样的架构就是合适的。
画外音：请注意，是多考虑一步，不是两步，不是五年后。
我曾经被问到“快狗打车从14年发展到现在，架构迭代了很多版，如果回到14年重新做架构设计，其架构会不会是现在的样子”，答案是一定不会跟今天一个样子，一定还是和14年时候一个样子，那个时候的架构，适合那个阶段。
架构不但是设计来的，更是演进而来的。
提问：很多技术人关注公司的技术氛围，技术氛围建立有什么经验分享么？
提几个点吧：
第一，指导人机制很重要。就是任何一个技术人一定会有一个高职阶的人带，有任何技术上的问题一定是有人可以交流和解答的。
第二，技术评审很重要，技术评审是一个很好的契机让大家沟通交流和讨论技术上的问题。
第三，分享机制很重要，每个团队内部定期组织技术分享，让大家沟通交流。
包括我也每周会花时间和团队的同学做一些技术的交流和沟通。
提问：PHP是世界上最好的语言吗？
技术的同学在讨论的时候要避免讨论两个问题，一个是哪种语言是世界上最好的语言，第二个要避免讨论的是Vim好还是Emacs好。
以上纯属
个人看法
，分享自己认为对的东西。
调研：
（1）贵司是
ppt型
架构师，还是
代码型
架构师？
（2）贵司是
深度型
架构师，还是
广度型
架构师？
（3）贵司是
针对业务
的架构设计，还是
针对晋升
的架构设计？
（4）贵司有没有
指导人
？
评审
？
分享
？
最后给有志于成为架构师的同学一个建议：
多学习、多交流、多沟通
本文转自“架构师之路”公众号，58沈剑提供。
