写点什么

不想做架构师的 Gopher 不是好程序员

作者:王中阳Go
  • 2023-04-10
    北京
  • 本文字数:1262 字

    阅读完需:约 4 分钟

不想做架构师的Gopher不是好程序员

最近我们在组队学习《手把手带你写一个web框架》,强制 PUSH,坚持每天学习打卡,不完成惩罚发红包的那种。


你别说,效果还真挺好。


昨天学到了架构部分,很受启发,光学不写假把式。(还是得坚持输出哇)


我站在大佬的肩膀上输出一篇总结文章出来,希望对大家有帮助:

概述

所谓架构,与一线开发最大的不同就在于是否有系统设计工作。架构师的价值已经不再体现在编码实现上,而更多地体现在设计上。


本文将重点介绍业务架构师和基础架构师的工作内容和职责,以及在架构设计中的重要性和作用。


业务架构师和基础架构师的职责

基础架构师主要负责基础服务的架构设计,这些服务是和业务无关的,包括数据库、缓存、队列等几乎所有业务都会使用到的服务。而业务架构师则主要负责让技术更好地服务业务。


在架构设计中,实现一个功能的方法有很多种,但是最符合自身业务的技术选型才是最优的。因此,业务架构师必须了解业务特点和需求,从而做出最优的技术决策。而基础架构师则需要深入了解基础服务的特点和性能,以及如何为业务提供最优的基础架构支持。

合作与沟通

对于技术人员而言,最终的技术能力模型应该是一个大 T 字形,即在某个领域有足够的深度,在多个领域有足够的广度。因此,虽然基础架构师和业务架构师具有不同的技术背景和专业领域,但两者之间的交流和合作至关重要。只有通过合作,才能确保系统的整体性和稳定性。


不管你的能力有多强,接手新的业务时,前三个月尽量不要做大的架构级别的修改,因为不熟悉业务,没有足够时间了解一线的代码逻辑,是不可能做出好的架构调整的。


架构设计中的原则和规律

基础架构的同学更大可能是往技术专家方向发展。他们对技术的成就感更多来源于为某个软件或某种语言增加特性,比如会追求成为 Apache PMC、微软的 MVP 等。他们的研究有可能改变某个技术行业。如果想走这个方向,必须热衷于某个技术行业。


《系统架构 - 复杂系统的产品设计与开发》这本书告诉读者如何做出一套思考系统架构的方式,即一些思考系统的原则和定律。整理一下对我有启发的原则:


  1. 歧义原则:系统架构的早期阶段充满了歧义。架构师必须解决这种歧义,以便给架构团队定出目标并持续更新该目标。

  2. 架构师角色原则:架构师的角色是解决歧义,专注创新,并简化复杂度。

  3. 架构决策原则:要把架构决策和其他决策分开,并且要提前花一些时间来谨慎地决定这些问题,因为以后如果要想变更会付出很大的代价。

  4. Conway 定律:设计系统的组织,总是会产生出与该组织的沟通结构相同的设计。

  5. 产品进化原则:系统必须进化,否则就会失去竞争力。因此,在架构设计中,必须考虑系统的可扩展性和可维护性,以适应未来业务的变化和发展。

  6. 2 下 1 上原则:要想判断对 level1 所做的分解是否合适,必须再向下分解一层,以确定 level2 中的各种关系。


这些原则和规律对于架构师的工作非常有帮助,可以帮助他们更好地理解系统架构,做出更优秀的设计。

结论

总之,业务架构和基础架构在架构设计中扮演着不同的角色和职责,但两者之间的合作是非常必要的。


架构师必须具备足够的技术深度和广度,以及良好的沟通和合作能力,才能为企业构建稳健和可靠的系统架构。



发布于: 刚刚阅读数: 3
用户头像

王中阳Go

关注

靠敲代码在北京买房的程序员 2022-10-09 加入

【微信】wangzhongyang1993【公众号】程序员升职加薪之旅【成就】InfoQ专家博主👍掘金签约作者👍B站&掘金&CSDN&思否等全平台账号:王中阳Go

评论

发布
暂无评论
不想做架构师的Gopher不是好程序员_Docker_王中阳Go_InfoQ写作社区