架构师到底该不该写代码

最新推荐文章于 2024-12-05 03:34:44 发布

原创最新推荐文章于 2024-12-05 03:34:44 发布 · 452 阅读

CC 4.0 BY-SA版权

周末InfoQ-StuQ直播，主持和听众提问的简版实录，快消时代，精简到1分钟可以读完（原文有10000字）。

提问：沈老师是从什么时候开始写文章的？

我从大学开始有写文章的习惯，最开始主要记录学习上和生活上的一些东西。毕业加入百度之后，在百度空间总结一些学习到的技术的东西，后来百度空间好像转型做交友平台了，于是搭建了自己的博客，在博客上写了一两年。最近当然就是在公众号“架构师之路”上写，梳理和总结自己日常工作中学习到的一些技术，业务上和架构上遇到的一些问题，分享给大家。

提问：网上有个很有争议的问题“架构师需要写代码吗？”，您对此怎么看？

我认为架构师应该写代码。

首先，业务是肯定需要深入去了解的，我比较反对一个公司成立一个所谓的架构师部门，拥有公司所有的架构师资源。我的建议是每个业务线团队都需要有架构师。架构师一定要深入了解业务的特点，针对业务的特点去设计系统架构。

我一直有一个观点“任何脱离业务的架构都是耍流氓”。肯定没有一个一成不变的架构方案，适用所有的业务场景。

其次，是要贴近系统，所以得看代码，写代码。即使完全没有时间去写代码的话，至少详细设计的每一个细节架构师都需要清楚，每一个流程、接口参数、数据库设计都要非常清楚。详细设计尽量详细到组内的任何一个工程师拿到详细设计都可以去做实现。CodeReview也非常重要，保证代码至少是有两个人看过，而且它的实现逻辑和详细设计是一致的。

我对架构师的建议是：有时间的话，亲自去写核心代码，如果没有时间的话，要把关详细设计并安排资深工程师去做CodeReview。

提问：当前互联网技术更新非常快，您认为架构师对此应该持什么态度？

首先对于新技术，需要去关注，但我的观点是“应用到线上，一定要慎重”。去看、去学、去研究是一个技术人员必须做的，但是学习新技术与把它应用到线上生产环境是两回事。

我负责58到家的一些后端架构，实施一些通用的技术平台，比如说线上的监控、数据的统一收集等，如果技术体系统一，综合成本会非常小。

再拿存储来举例，存储的软件和技术有很多，mysql，sql-server， mongodb等，统一用一个非常重要，一定不能是哪个团队想用什么就用什么。

我的建议是：对新技术我们一定要去学习，但应用到线上一定要慎重。

提问：大家觉得架构师的知识宽度是很广的，那会不会有什么都懂、什么都不精这样一种现象存在？

首先什么都懂是绝对不可能的，什么都精也是绝对不可能的，但是架构师也不能哪一块都不精。虽然业务不一样，但是架构设计上肯定会有通用的地方。我原来做过几百万同时在线的即时通讯系统，它肯定有架构领域内通用的东西，比如接入、数据、可用性、扩展性、一致性等，所以这些经验对我后面做推荐系统的设计，支付系统的设计肯定会有帮助。

其实架构师对于知识的宽度和深度都是有要求的，像现在网上有一种说法说架构师的能力是π型人才，除了技术宽度，还要有两条腿：一条是专业能力，还有一条是通用能力，比如表达、沟通、解决问题、管理、创新等。

提问：有很多立志于成为架构师的人不知道如何开始？沈老师能不能给一些比较具体的建议？

我认为架构师之路分为三个阶段：

第一个阶段是打基本功的阶段。对应我自己的话就是职业生涯的前三年，语言、数据结构、算法、设计模式、研发工具、调试工具等，基本功没打好，其他的一切都是空谈。

第二个阶段是业务的积累或叫技术深度的积累。对于我来说，则是业务深入，即前五年在即时通讯领域的打拼。业务的深度决定了进入一家公司的时候，你的身价，一个公司要解决某个业务问题，就必须有针对性的招相关的人才，如果你可以解决这个业务领域内的大部分问题，这就是你的核心竞争力。

第三个阶段，π型人才的另外一条腿，即通用素质这一块，就是你的执行力、责任心、推动能力、沟通表达能力、项目管理能力，这些会让别人觉得你是靠谱的。在技术能力大家都差不多的情况下，一个事情为什么交给你来做，大家有没有想过？因为公司觉得你是靠谱的，靠谱这个评价很高。

提问：对一个架构来说，因为没有完美的架构，它一定会有一些缺陷，那好的架构有一个什么样的标准吗？

架构是为业务服务的，能够满足业务的需求并且对它的扩展性多考虑一步，我觉得这样的架构就是合适的。

我曾经被问到“58同城从05年发展到现在，架构迭代了很多版，如果回到05年重新做架构设计，58的架构会不会是现在的样子”，答案是一定不会跟今天一个样子，一定还是和05年时候一个样子。

提问：58的技术氛围是怎么建立起来的？

第一个指导人机制很重要，就是任何一个研发一定会有一个高职阶的人带，有任何技术上的问题一定是有人可以交流和解答的。

第二个我觉得很重要的是技术评审，技术评审是一个很好的契机让大家沟通交流和讨论技术上的问题。