2020 | 带领团队学习成长，干货总结
正文共： 3166字 10图 预计阅读时间： 8分钟
在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
NoSQL为了解决关系型数据库无法对应高并发访问带来的访问压力
全文搜索引擎为了解决关系型数据库like检索低效的问题
Hadoop为了解决传统文件系统无法应对海量数据存储和计算的问题
安全性
功能安全、架构安全
规模程度
量变引起质变
功能越多（数据越多），导致系统复杂度指数级上升
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 编程之钻
编程之钻（The Programming Diamond）
上图描绘了编程作为一个完整工作流程（work process）的四项最基本活动
需求分析
设计实现
测试验证
调试纠错
我们开发任何一个软件功能、实现某个软件需求，一般都需要经历这 4 项基本的活动或状态。把这四个状态连起来恰好形成一个菱形，所以我把它叫作“编程之钻”（The Programming Diamond）。
犹如一颗大钻镶嵌了四颗小钻，把它们称作编程的“钻石”，也凸显了这几个基本任务及其相关技术与方法在软件开发、软件工程中的重要性。
Part4：总结
4.1 “悖论”？
通常我们在解决具体问题时候，最常见的想法就是快速的完成自己的工作任务，这样一来，是不是建设优质的软件架构形成了悖论呢？
4.2 观点
无论是微观世界的代码，还是宏观层面的架构，无论是编程范式还是微服务架构，它们都在解决一个问题：分离控制和逻辑。
所谓控制就是对程序流转的与业务逻辑无关的代码或系统的控制（如多线程、异步、服务发现、部署、弹性伸缩等），所谓逻辑则是实实在在的业务逻辑，是解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度，有效地分离控制和逻辑会让你的系统得到最大的简化。
其中 简单vs.简陋、平衡vs.妥协、迭代vs.半成品 就是我们需要涉及到软件架构中平衡的艺术。
4.3 学习建议
最后给大家一些学习上的建议：
1w小时学习定律
不断的踩坑与填坑，会带给你真正的成长
关键点
对技术的保持热情
需要持续不断的精力投入
坚持学习、实践、思考、总结
指导原则
经验的沉淀与积累
拓宽视野，不拘泥于现状
锻炼深度思考能力，抓本质问题
大家好，我是「架构精进之路」公号作者 flyer0126，公号文章主要来自于个人日常工作问题总结思考，相信问题及解决方案均具有普适性，希望同大家一起学习成长。
大家如有任何疑问/困惑，可关注公号回复关键字 “wx” 添加个人微信，继续勾搭~
往期热文推荐：
「技术架构精进」专注架构研究，技术分享
Thanks for reading!