架构师不写代码,能行吗?

架构师不写代码,能行吗?

作者 | Brandon Bryson

编辑 | 小智

从什么时候起,技术角色的提升就意味着脱离技术与交付?CTO 不写代码已经引起诸多争议了,架构师也不写代码,能行吗?

当我面试架构师职位的候选人时,我通常会问一个这样的问题:“你认为架构师是否应该做一些编码工作?”而通常会得到下面两个反馈之一:

“不,我正在寻找一个不再需要编码的职位。”

“我喜欢继续编码,至少是少量的编码,但可能不会有时间这样做。”

与此类似,当问及其他一些架构师最近做过多少编码的工作,通常得到的答案是:

“有一段时间没有编码了。”

这些回应总是让人感到不安。从何时开始一个技术角色的提升开始意味着脱离技术和交付?

如果不能深入到实现这些技术的团队中,架构师又怎能期望在规模庞大的技术选择中指引方向,并理解这些技术如何在企业中发挥作用?或者更好的是,亲自实施这些技术?

在没有与交付团队保持紧密联系的前提下,架构师如何能够期望在应对持续变化的项目需求时,保持灵活?

优秀的架构师必须与交付团队紧密合作。这对发展成功的系统架构,进而成功交付是十分必要的。

收集反馈并展现领导力是保持与交付团队紧密合作的两个核心利益。

1 反馈

深度参与的架构师会见证第一手反馈信息并且与团队紧密合作以缓解各种缺陷。反馈可能源自于各处,如企业标准的变化,持续变化或发展的功能性 / 非功能性需求以及在实施和测试过程中所发现的各种挑战。

能够越早识别这些缺陷,架构师就能够越快改进系统架构。如果架构师没有积极参与到交付团队中,那么这个反馈可能会花费数周甚至数月才能够上报给架构师,这时通常已经处于交付周期的晚期了。

鉴于架构决策通常会包含一些非常重要或者难以改变的内容,如果需要重大的架构性调整,这一反馈方面的延迟只会加重。

在交付周期的晚期发现架构性缺陷通常会采取变通方案以“暂时熬过这一版本”,与此同时也会留下技术债务。然而,越早捕获和评估这一反馈的架构性影响,整个项目就会越敏捷,风险累积也会更少。

2 领导力

架构师所承担的另一主要职责就是领导力。领导力有多种形式,所有这些形式对于成果及其底层架构的成功实现来说都是至关重要的。

为了团队的成功实现,架构领导力要求架构师能够有效地与团队沟通“大局观”。传递这一信息的最佳方案就是与交付团队紧密合作并进行若干次相关讨论,而不是仅仅通过一篇文档、一次会议或一场演讲。架构方向必须在工作过程中反复调整。太过于陷入交付的热情中,很容易忽视整体目标。一个持续参与的架构师可以帮助维系愿景的一致性。

技术领导力源于这样的事实:架构师通常在开发和交付方面具有丰富的经验。架构师的目标之一就是教育开发团队帮助其成长。有些情况下有专门的技术领导人担当这一角色,但为什么要让架构师所获得的经验浪费掉?这种交互不仅能够让整个团队受益,也能够让架构师更好地了解开发团队所遭遇的常见问题。

导师是架构师可以向团队传递的非技术领导力的一种形式。如何与非技术人群合作,拥抱敏捷原则,定义架构以及架构建模等话题都是对开发人员和潜在架构师成长十分重要的技能。与更加正式的,课堂式的教育机会相比,架构师这一角色的训练和知识多数都源于在职经验。架构师应该拥抱这一趋势并让架构学习更加主动而非被动。

3 提高参与度的策略

参与项目的架构师可能不必亲自交付故事。实际上,取决于诸如架构师 - 开发人员比率或项目的对外承诺等因素,让架构师独自负责并交付故事可能并不是一个最优方案。下面是一些可以让架构师与交付团队紧密合作并增加架构师与团队之间交互的一些策略。

结对

Martin Fowler 在 2015 年 O’Reilly 的一次软件架构研讨会上发表的讲话中曾经提到结对可能是让架构师更有参与感的一种很好的选择。结对或结对编程是一种敏捷软件开发技术,随着极限编程方法而逐渐流行,在结对编程技术中,两个团队成员共同工作于一个工作站以完成一个共同的目标。在这一场景下,架构师永远不会独立地负责一个故事,而是与团队中的其他成员结对完成必须的设计、开发和 / 或测试工作。这一方法的优点在于能够让架构师保持对交付所负有的责任并且与所发现的架构性反馈保持紧密联系,同时又避免在架构师必须要担负外部责任的情况下团队资源的流失。

同行评审

这一方法与结对类似,不过反馈回路相对较慢。同行评审指的是一名同行从质量的角度评审另外一名同行的工作,通常是在大部分工作已经完成之后。在这里,架构师与开发者一起同行评审代码,定期的或者在故事完成之前评审一次。通过这种方法,架构师能够获得对架构一致性或问题预防一致性的深度洞察并且有机会通过开发谏言的形式建立领导力。

开发尖兵

架构师可以带领一个专注于架构探索或交付的开发尖兵团队。尖兵通过探索某项新技术,用于识别或降低风险架构某一方面的功能性概念验证的实现。尖兵提供了绝佳的机会以了解已经实现的架构决策,致力于交付目标并促进更多的针对架构瑕疵或限制的即刻视野。他们还鼓励架构师直接参与到实现中,与团队合作,共享架构愿景,并直接从过去的经验中获益。

故事开发

架构师也可以成为团队成员并完成实际的故事交付。这可能是联系最紧密的反馈回路。这种方法的缺点在于架构师可能太过于专注在个别的故事之上(只见树木不见森林)。必须保持维系架构愿景和长远规划与详细设计和具体实现之间的平衡。此外,需要注意的是,这种方法可能会破坏团队速度的一致性。举例来说,如果架构师在进行实际的故事开发三周后,被抽调出去两周完成一些更高层级的工作(如路线图),这可能会对团队的整体速度造成一定影响。首先,尽管我同意短期可能会影响速度;但长期来看由于平均法则的缘故,对速度的影响会显著降低。其次,如果架构师要进行高层级的项目相关工作,那么应该为其安排与待交付故事相关的故事任务,这样可以减少架构师必须管理的高层级与低层级任务之间的转换次数。

轮转

在这一策略中,一段时间内,架构师这一角色会在团队成员之间轮转。在每个成员担任架构师这一角色的期间,他们需要承担作出架构决策、维系架构一致性以及提供总体架构指导的职责。在不同的团队成员之间轮转架构师角色所带来的收益是能够提升团队整体的工作架构知识。团队成员能够对参与到交付中的各个角色均有更好的理解,这会促进团队角色之间的共鸣,提升团队内部的交互,以及通过应用于每个角色之上的多样化视角所带来的更好的整体产品。我会建议谨慎地使用轮转策略,因为轮转所产生的不一致性导致的混乱可能会比所得到的收益更多。取决于团队的组成和发布周期的长度,在主要发布版本(3-6 个月)时间线上的某个时点进行轮转可能会比较合适。

4 需要避免的参与方式

有一些策略可以提升架构师在交付过程中的参与度,同样也有一些架构师可能也会采取的提升参与度的方法会对整个团队的健康发展不利,这种尝试应当尽量避免。

只处理难题

架构师可能会有只处理难题的倾向,无论这一工作是否包含在故事当中。考虑到架构师的资历和经验,这看起来像是显而易见的;然而,长期来看这可能会有损团队健康发展。首先,由于未参与其中,团队可能不会完全理解也无法支持系统中这些复杂的细微差别。其次,软件开发人员享受有挑战的工作。架构师解决了所有的难题的同时也就剥夺了其他人挖掘和学习新知识的机会。

接管

另外一种不推荐的方法就是用命令 - 控制的方式接管交付。架构师在架构定义上所花费的时间和精力,特别是在架构师融为团队的一部分时,能够为成功的交付提供足够的动力。架构师可能会产生整体控制整个交付方方面面的意图,而不仅仅局限于引导交付向架构性目标努力。这种方法会导致如下的消极影响:

这样的团队会对控制型的架构师产生愤怒情绪,而无法形成自组织、高效率和相互合作的团队。

限制了团队成员的主人翁意识和成长的机会。

难以处理更大的交付规模。

驱动细节 而非本质

在进行结对编程或者同行评审时,架构师应该驱动需求的本质,而非细节。即使是最简单的逻辑也有许多种编码方式,而且其中有许多都能够完美地实现功能,尽管并非完全照搬架构师的思路。架构师必须要在架构方向上加以指引,并强制实施本地代码标准,与此同时也要允许一些例外。

5 总结

要让一个成功的架构得以实现,架构师必须要在整个生命周期始终保持与交付团队的紧密合作。保持紧密合作能够促进架构层面的快速反馈循环。并且还能够为架构师提供更多的与团队交流架构愿景和领导团队的机会。正如本文题目所描述的那样,架构师除了可以参与到实际的编码工作中之外,还有许多其他的方式可以参与到交付团队中,例如结对编程和同行评审。相反,某些参与方式有可能会对团队造成负面影响,例如接管交付、不允许团队自组织或者采用集体所有制。其中一个关键目的是为了避免“象牙塔”架构师的角色——只在项目最初发布架构,然后就再也不见踪影。谋求与交付团队的协作关系,共同努力尽早识别和解决架构性缺陷,从而交付成功的架构和最终的产品。

英文原文

https://www.infoq.com/articles/architects-should-code-bryson

6 InfoQer 说

从何时开始一个技术角色的提升开始意味着脱离技术和交付?

这个问题让人深思,难道程序员升职了、加薪了,反而离安身立命的代码越来越远了吗?

你们怎么看?欢迎留言告诉我们,大家一起讨论交流!

今日荐文

点击下方图片即可阅读

架构师不写代码,能行吗?

Vue 和 React 构建相同应用程序,区别是?

人工智能和机器学习正在改变并塑造软件的未来。作为公司的高级 / 资深工程师、架构师、技术经理 / 总监,我该如何将 AI& 机器学习应用到公司业务中,有哪些落地案例和踩坑经验可供参考?相关工具、平台、框架是怎样的,如何做选型?如何构建一个专门的人工智能团队,有哪些难点和需要注意的事情?

第二届 AICon 全球人工智能与机器学习技术大会上,我们将为你一一解答。大会涵盖语音识别、NLP、搜索推荐与算法、计算机视觉、AI 工具与框架等 20+ 技术热点,来自 Google、Facebook、Twitter、BAT 等 40+ 一线技术大牛将现场与你深入交流,目前大会 6 折最低价购票 火热进行中,点击“阅读原文”了解更多详情!

<think>嗯,用户问“软件工程师往上走是软件架构师吗”,我需要先理解这个问题背后的意图。用户可能是在职业规划上有疑问,想知道软件工程师的发展路径是否是直接晋升到软件架构师。这时候,我需要考虑用户可能的背景,可能是一个正在考虑职业发展的软件工程师,或者刚入行久的人,想了解未来的方向。 首先,我需要确认软件工程师的常见职业发展路径。通常来说,软件工程师的发展方向并是单一的,可能有技术路线和管理路线之分。技术路线可能包括高级工程师、架构师、技术专家等,而管理路线则可能走向技术经理、项目经理、CTO等职位。因此,用户的问题中的“往上走”可能指的是技术方向的晋升,但需要明确是否存在其他可能性。 接下来,我需要分析软件架构师的角色和职责,以及它与软件工程师的区别。软件架构师通常负责系统的整体设计,技术选型,确保系统的可扩展性、可靠性等非功能需求。而软件工程师可能更多专注于具体模块的实现。因此,架构师需要更广泛的技术视野和系统设计能力,而仅仅是编码能力。 然后,我需要考虑用户可能存在的误区,即认为晋升路径是线性的,从工程师到架构师。但实际上,很多公司可能有同的职级体系,比如在有些公司,高级工程师之后可能是技术负责人,然后才是架构师。另外,架构师可能分为同的类型,比如解决方案架构师系统架构师等,职责也有所同。 用户可能还想知道成为架构师需要哪些技能,是否需要特定的经验或认证。因此,在回答中应该涵盖这些方面,比如技术广度和深度、系统设计能力、沟通协调能力等。同时,需要指出架构师是唯一的晋升方向,还有技术管理、专家路线等可能性。 另外,用户可能没有考虑到个人兴趣和职业目标的重要性。有些人更适合深入技术,有些人则喜欢管理或产品方向。因此,在回答中应该建议用户根据自己的兴趣和长处选择路径,而仅仅是跟随常规晋升路线。 最后,要确保回答结构清晰,分点说明,可能包括职业路径的多样性、架构师的核心能力、转型所需的准备,以及同选择的建议。这样用户能全面了解,做出适合自己的决策。</think>软件工程师的职业发展路径并非单一方向,软件架构师是技术路线的重要分支,但并非唯一选项。以下是详细分析: --- ### 一、技术岗位发展三维模型 $$ \begin{cases} \text{技术深度轴} & \text{(工程师→技术专家→科学家)} \\ \text{系统广度轴} & \text{(工程师→架构师→CTO)} \\ \text{管理跨度轴} & \text{(工程师→TL→技术总监)} \end{cases} $$ 典型发展路径示例: 1. **技术专家路径** `中级工程师→高级工程师→领域专家(如Java并发专家)→研究员` 2. **架构师路径** `全栈工程师→系统架构师→解决方案架构师→首席架构师` 3. **管理路径** `技术主管→工程经理→技术总监→CTO` --- ### 二、软件架构师核心能力矩阵 #### 1. 技术决策能力 - **技术选型** 根据$QPS/TPS$指标选择存储方案(如MySQL vs Cassandra在10w+TPS场景下的选择) - **模式应用** 设计微服务架构时采用$CQRS$模式解耦读操作 - **风险预判** 用$MTBF/MTTR$模型评估系统可用性(如设计异地多活架构) #### 2. 系统设计能力 - **抽象建模** 使用$UML$绘制领域驱动设计(DDD)中的限界上下文 - **协议设计** 制定内部RPC协议(如基于Protobuf的自定义二进制协议) - **容量规划** 通过$Little's Law$计算系统承载能力($L = λW$) #### 3. 协作协调能力 - **技术布道** 编架构决策记录(ADR)说明选择gRPC而非REST的原因 - **资源平衡** 用$EVM$(挣值管理)方法监控技术债务处理进度 - **成本控制** 优化云资源使用(如通过$Spot Instance+Reserved Instance$组合降低30% AWS成本) --- ### 三、架构师与工程师能力差异对比 | 维度 | 软件工程师 | 软件架构师 | |--------------|---------------------------|-----------------------------| | 关注重点 | 功能实现(How) | 系统演进(Why & What) | | 技术范围 | 具体技术栈(如Spring生态) | 跨领域整合(云原生+大数据+AI) | | 决策依据 | 代码质量(SonarQube指标) | 架构权衡(CAP定理应用) | | 交付物 | 模块代码/单元测试 | 架构蓝图/技术雷达 | | 典型工具 | IDE/调试器 | ArchiMate/C4模型工具 | --- ### 四、转型架构师的准备阶段 #### 阶段1:技术纵深期(2-3年) - 深入理解设计模式(如用$Reactor$模式重构网络模块) - 参与重点系统改造(如将单体应用拆分为微服务) #### 阶段2:系统视野扩展期(1-2年) - 主导技术方案设计(如设计日均百亿级消息处理系统) - 研究论文与专利(如学习Google Spanner的TrueTime算法) #### 阶段3:架构思维成型期(1年+) - 构建技术决策框架(建立架构评估矩阵) - 输出行业解决方案(如金融级分布式事务方案) --- ### 五、架构师之外的进阶选择 1. **技术管理路线** 适合沟通协调能力强者,需掌握$OKR$制定与团队激励方法 2. **创业技术合伙人** 需补充商业知识(如学习$Pitch Deck$制作与融资流程) 3. **技术产品经理** 结合工程师背景主导技术型产品(如APM、DevOps工具链) --- ### 典型案例 某电商平台工程师转型路径: - **第1-3年**:负责订单系统开发,主导MySQL分库分表改造(提升QPS从5k到3w+) - **第4年**:晋升技术主管,设计基于$Kafka$的异步消息体系(降低系统耦合度) - **第5年**:成为架构师,完成服务网格化改造(引入Istio实现流量管理) - **第6年**:转型解决方案架构师,为零售企业设计混合云架构 --- 是否选择架构师路径,建议通过《架构整洁之道》+《设计数据密集型应用》进行能力自测,同时参与开源项目架构设计(如Apache项目贡献)积累实战经验。技术管理路线同样值得考虑,两者年薪在资深阶段均可突破$50w-$100w(一线城市)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值