不想做架构师的Gopher不是好程序员
最近我们在组队学习《手把手带你写一个web框架》,强制PUSH,坚持每天学习打卡,不完成惩罚发红包的那种。
你别说,效果还真挺好。
昨天学到了架构部分,很受启发,光学不写假把式。(还是得坚持输出哇)
我站在大佬的肩膀上输出一篇总结文章出来,希望对大家有帮助:
概述
所谓架构,与一线开发最大的不同就在于是否有系统设计工作。架构师的价值已经不再体现在编码实现上,而更多地体现在设计上。
本文将重点介绍业务架构师和基础架构师的工作内容和职责,以及在架构设计中的重要性和作用。
业务架构师和基础架构师的职责
基础架构师主要负责基础服务的架构设计,这些服务是和业务无关的,包括数据库、缓存、队列等几乎所有业务都会使用到的服务。而业务架构师则主要负责让技术更好地服务业务。
在架构设计中,实现一个功能的方法有很多种,但是最符合自身业务的技术选型才是最优的。因此,业务架构师必须了解业务特点和需求,从而做出最优的技术决策。而基础架构师则需要深入了解基础服务的特点和性能,以及如何为业务提供最优的基础架构支持。
合作与沟通
对于技术人员而言,最终的技术能力模型应该是一个大T字形,即在某个领域有足够的深度,在多个领域有足够的广度。因此,虽然基础架构师和业务架构师具有不同的技术背景和专业领域,但两者之间的交流和合作至关重要。只有通过合作,才能确保系统的整体性和稳定性。
不管你的能力有多强,接手新的业务时,前三个月尽量不要做大的架构级别的修改,因为不熟悉业务,没有足够时间了解一线的代码逻辑,是不可能做出好的架构调整的。
架构设计中的原则和规律
基础架构的同学更大可能是往技术专家方向发展。他们对技术的成就感更多来源于为某个软件或某种语言增加特性,比如会追求成为 Apache PMC、微软的 MVP 等。他们的研究有可能改变某个技术行业。如果想走这个方向,必须热衷于某个技术行业。
《系统架构 - 复杂系统的产品设计与开发》这本书告诉读者如何做出一套思考系统架构的方式,即一些思考系统的原则和定律。整理一下对我有启发的原则:
- 歧义原则:系统架构的早期阶段充满了歧义。架构师必须解决这种歧义,以便给架构团队定出目标并持续更新该目标。
- 架构师角色原则:架构师的角色是解决歧义,专注创新,并简化复杂度。
- 架构决策原则:要把架构决策和其他决策分开,并且要提前花一些时间来谨慎地决定这些问题,因为以后如果要想变更会付出很大的代价。
- Conway 定律:设计系统的组织,总是会产生出与该组织的沟通结构相同的设计。
- 产品进化原则:系统必须进化,否则就会失去竞争力。因此,在架构设计中,必须考虑系统的可扩展性和可维护性,以适应未来业务的变化和发展。
- 2下1上原则:要想判断对level1所做的分解是否合适,必须再向下分解一层,以确定level2中的各种关系。
这些原则和规律对于架构师的工作非常有帮助,可以帮助他们更好地理解系统架构,做出更优秀的设计。
结论
总之,业务架构和基础架构在架构设计中扮演着不同的角色和职责,但两者之间的合作是非常必要的。
架构师必须具备足够的技术深度和广度,以及良好的沟通和合作能力,才能为企业构建稳健和可靠的系统架构。