写点什么

盘点 2020 | 带领团队学习成长,干货总结

发布于: 2020 年 12 月 20 日
盘点2020 | 带领团队学习成长,干货总结

在 2020 年这个非同寻常的年份里面,自己与团队小伙伴一起利用周例会时间,分享学习了《架构整洁之道》系列内容,同团队一起学习成长。在这个岁末年终的日子里,结合 InfoQ 协作平台【盘点 2020】活动,来对自己本年度带领团队学习成长做个总结,分享给大家参考。


本文主要内容思路围绕以下几点:

  • 通过系列学习分享,我们 get 到了什么?

  • 我们搞这个系列的分享,初衷是什么?

  • 通过系列分享,是否可以指导我们技术设计?

Part1:收获

1.1 《架构整洁之道》系列内容

主要内容总结一下,主要分以下几部分:

  • 编程范式(结构化编程、面向对象编程和函数式编程)

  • 设计原则(主要是 SOLID)

  • 组件处理(依赖、边界)

  • 软件架构(其中讲了很多高屋建瓴的内容)

简单概况一下即包括 微观(代码层面)和宏观(架构层面)两个层面的主要开发技能。

1.2 “架构”到底是什么?

可能我们天天会说到“架构”,那它到底是什么呢?

软件架构(software architecture)

有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。 -- 来自维基百科


系统其实是一群关联个体的组成,系统中的个体需要“根据某种规则”协作,架构需要明确这种协作规则。

架构=骨、结,源于建筑学。

骨架 揭示架构中内在的支撑物;

结构 则表明架构关心支撑物相互结合的某种构造方式。


架构的价值是什么呢?

  • 最少的人力成本满足构建和维护该系统的需求

  • 支撑软件系统的全生命周期,让系统便于理解、易于修改、方便维护、轻松部署

1.3 “架构”的目的是什么?

架构设计的主要目的是为了解决软件系统复杂度带来的问题。


当明确了架构的目的之后,会有哪些好处?

主要对于“老鸟”架构师与“新手”架构师区分而言

  • 心中有数,而不是一头雾水

  • 有的放矢,而不是贪大求全


现实中我们还会遇到一些这样的讨论:

  • “我们的系统一定要做到 QPS 10w”

  • “淘宝的架构就是这么做的,我们也要这样”

  • “Docker 现在很热,我们的架构应该将 Docker 引入进来”

影响我们做决策的首要依据应该是系统复杂度,那该如何分析呢?

1.4 复杂度主要分析点

系统复杂度主要分为以下几点:

  • 高性能

单机复杂度、集群复杂度

  • 高可用

计算高可用、存储高可用

  • 可扩展性

预测变化、应对变化

  • 低成本

创新(NoSQL、全文搜索引擎、Hadoop)

Facebook HHVM、新浪微博 SSD Cache、LinkedIn Kafka

  • 安全性

功能安全、架构安全

  • 规模程度

量变引起质变

功能越多(数据越多),导致系统复杂度指数级上升


1.5 架构设计的原则有哪些?

同样的代码,不论是不是同一人写的,执行结果是确定的,但是同一个系统,不同的架构师,最终都可以解决问题,但设计方案却可能大不相同。

架构设计的原则主要是解决不确定性,也是优秀程序员与架构师区分点所在。


如何解决这种“不确定性”呢?

  • 合适原则:合适优于业界领先

将军难打无兵之仗(人手不足,却想产出多)

罗马不是一天建成的(例如各大电商平台的“双 11”抢购技术能力支持)

冰山下面才是关键(没有业务场景,却幻想灵光一现)

  • 简单原则:简单优于复杂

结构复杂性(组件多,关联多,故障概率大,定位问题困难)

逻辑复杂性(集所有功能于一身)

《UNIX 编程艺术》KISS:Keep it Simple,Stupid!

  • 演化原则:演化优于一步到位

就软件而言,变化才是主题

满足当前的业务需要

应用过程中迭代,保留优秀,修复缺陷的设计,改正错误的设计

业务变化时,扩展、重构,甚至重写

Part2:初衷

2.1 软件系统的价值

软件系统价值主要分为行为价值架构价值

  • 业务价值(核心价值)

需求的实现,以及业务可用性保障(功能性 bug 、性能、稳定性)

  • 架构价值

需求变更时,软件变更成本低且可控


事实表明,随着软件复杂度的上升,工程师人数随之增加,但是代码量到达一定量之后涨幅呈现缓慢。但是代码维护成本却呈指数级上升,同时工程师的生产效率也会随之降低,需求变更维护成本增大。


2.2 对程序员的简单分类

  • 普通程序员

  • 工程师

  • 架构师

编写代码的方式有很多,只要能让程序跑起来,能正确地处理业务流程和对数据进行计算,就可以说“会编写代码”。程序员需要熟悉整个程序的逻辑及处理过程,需要熟悉程序语言的特性,还需要熟悉一些计算机操作系统的交互调用方式,才能写出从用户侧交互,到数据和业务逻辑处理,再到与计算机系统交互的代码,有效地把用户信息、数据、业务和计算机串联和拼装出来。

还需要易读、易扩展、易维护,甚至可以直接重用。于是,这些人使用各种各样的手段和技术不断提高代码的易读性、可扩展性、可维护性和重用性。

2.3 我们的初衷

谈到我们学习《架构整洁之道》系列课程内容的初衷,其实即是回归软件系统的价值,利用多维的指导分析,帮我们做出正确的架构决策和架构设计。


Part3:收益

3.1 架构分类

我们需要针对当前业务需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡。


主要架构分类:

  • 业务架构

战略层面,业务方向是什么,要做什么;

  • 应用架构

战术层面,承上启下作用;

  • 技术架构

装备层面,负责业务的具体落地实施。

3.2 架构演进

架构的主要演进过程:

  • 单体式架构

俗称“烟囱式”架构

  • 分布式架构

按功能模块,服务化拆分

  • SOA 架构

  • 微服务架构


其实无论哪种架构方式,在当时环境下都可以解决问题的,都具有一定的意义的。

总结起来还是那句话:存在即是合理的。

3.3 请求链路

除了系统架构本身,还需要关注每层技术架构的设计点。过程质量关乎整体质量,各环节的架构合理性至关重要。


3.4 编程之钻

上图描绘了编程作为一个完整工作流程(work process)的四项最基本活动

  1. 需求分析

  2. 设计实现

  3. 测试验证

  4. 调试纠错


我们开发任何一个软件功能、实现某个软件需求,一般都需要经历这 4 项基本的活动或状态。把这四个状态连起来恰好形成一个菱形,所以我把它叫作“编程之钻”(The Programming Diamond)。

犹如一颗大钻镶嵌了四颗小钻,把它们称作编程的“钻石”,也凸显了这几个基本任务及其相关技术与方法在软件开发、软件工程中的重要性。

Part4:总结

4.1 “悖论”?

通常我们在解决具体问题时候,最常见的想法就是快速的完成自己的工作任务,这样一来,是不是建设优质的软件架构形成了悖论呢?


4.2 观点

无论是微观世界的代码,还是宏观层面的架构,无论是编程范式还是微服务架构,它们都在解决一个问题:分离控制和逻辑。

所谓控制就是对程序流转的与业务逻辑无关的代码或系统的控制(如多线程、异步、服务发现、部署、弹性伸缩等),所谓逻辑则是实实在在的业务逻辑,是解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度,有效地分离控制和逻辑会让你的系统得到最大的简化。


其中 简单 vs.简陋、平衡 vs.妥协、迭代 vs.半成品 就是我们需要涉及到软件架构中平衡的艺术。

4.3 学习建议

最后给大家一些学习上的建议:

  • 1w 小时学习定律

不断的踩坑与填坑,会带给你真正的成长

  • 关键点

对技术的保持热情

需要持续不断的精力投入

坚持学习、实践、思考、总结

  • 指导原则

经验的沉淀与积累

拓宽视野,不拘泥于现状

锻炼深度思考能力,抓本质问题



以上为自己带领团队学习成长总结内容,借 InfoQ 写作平台【盘点 2020】活动分享给大家参考,其中不妥之处还烦请指正,谢谢!


Thanks for reading!

发布于: 2020 年 12 月 20 日阅读数: 708
用户头像

坚持分享接地气儿的架构技术文章! 2018.02.26 加入

同名微信公众号「架构精进之路」,专注软件架构研究,技术学习与职业成长!坚持原创总结、沉淀和分享,希望能带给大家一些引导和启发,感谢各位的支持(关注、点赞、分享)!

评论 (2 条评论)

发布
用户头像
感谢分享!
2020 年 12 月 21 日 13:54
回复
成长总结,记录学习成长
2020 年 12 月 21 日 18:29
回复
没有更多了
盘点2020 | 带领团队学习成长,干货总结