架构师到底该不该写代码

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

提问:58的技术氛围是怎么建立起来的?

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

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

第三个是分享机制,每个团队内部定期组织技术分享,让大家沟通交流。包括我也每周会花时间和团队的同学做一些技术的交流和沟通。

提问:PHP是世界上最好的语言吗?

技术的同学在讨论的时候要避免讨论两个问题,一个是哪种语言是世界上最好的语言,第二个要避免讨论的是Vim好还是Emacs好。

总结

(1) 架构师需要写代码吗?

有时间的话,亲自去写核心代码,如果没有时间的话,要把关详细设计并安排资深工程师去做CodeReview

(2)对于新技术,持什么样的态度?

需要去学习,但应用到线上一定要慎重

(3)对架构师的能力要求?

π型人才,除了技术宽度,还要有两条腿:一条是专业能力,还有一条是通用能力

(4)架构师三个阶段?

打基本功,业务沉淀,通用素质进阶

(5)好的架构的标准?

能够满足业务的需求并且对它的扩展性多考虑一步

(6)技术氛围怎么培养?

指导人机制,技术评审,技术分享

最后给有志于成为架构师的同学一个建议:多学习、多交流、多沟通。

代码架构师作为现代企业数字化转型中的关键角色,其职责和技能要求与传统架构师相比有所区别,但也存在许多共通之处。以下是关于低代码架构师的工作内容、技能要求及其职业发展路径的详细分析。 ### 工作内容 低代码架构师的核心任务是利用低代码平台帮助企业快速构建、部署和优化应用程序,同时确保系统的可扩展性、安全性及性能。具体工作包括: - 设计并实现基于低代码平台的应用系统架构,涵盖前端、后端、数据库以及第三方服务集成。 - 与业务部门协作,理解需求并将其转化为技术方案,确保所开发的应用能够有效支持业务流程。 - 对现有低代码平台进行评估和优化,提升开发效率和系统稳定性。 - 制定技术规范和标准,指导开发团队遵循最佳实践进行应用开发。 - 在复杂场景中结合少量手代码(Low-code + Custom Code)来满足特定功能需求,确保整体架构的一致性和可维护性。 ### 技能要求 成为一名优秀的低代码架构师,需要具备以下几方面的技能: 1. **平台掌握**:熟悉主流低代码平台(如OutSystems、Mendix、Power Apps等),了解其底层机制、组件模型及扩展能力。 2. **系统设计能力**:具备良好的软件架构设计经验,能够设计高可用、高性能的企业级应用架构。 3. **集成能力**:掌握RESTful API、Web Services、消息队列等集成技术,能够将低代码平台与企业原有系统无缝对接。 4. **DevOps与自动化**:了解CI/CD流程,能够在低代码环境中实现自动化测试、部署与监控。 5. **数据建模与管理**:具备数据库设计能力,能够使用低代码工具进行高效的数据建模与管理。 6. **沟通与协作**:能够与非技术人员(如产品经理、业务分析师)顺畅沟通,推动项目顺利实施。 ```java // 示例:在低代码平台上通过自定义插件扩展功能 public class CustomDataProcessor { public String processInput(String rawData) { // 实现数据清洗与格式化逻辑 return rawData.trim().toUpperCase(); } } ``` ### 职业路径 低代码架构师的职业发展通常可以遵循以下路径: 1. **初级开发者**:从使用低代码平台进行简单应用开发起步,逐步掌握平台的基本功能与流程配置。 2. **中级开发者/解决方案设计师**:开始参与更复杂的项目,负责模块划分、接口设计以及部分定制开发。 3. **高级低代码工程师/架构师**:具备独立设计完整系统架构的能力,能够主导项目的技术选型与架构决策。 4. **首席架构师或技术负责人**:在大型组织中担任技术领导角色,制定企业级低代码战略,并推动平台标准化与治理。 5. **顾问或培训师**:转向咨询或教育领域,为企业提供低代码平台的最佳实践指导与内部培训。 随着企业对敏捷开发与数字化转型的持续投入,低代码架构师的角色将越来越重要。不仅限于IT行业,金融、制造、医疗等多个行业也对这类人才有强烈需求[^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值