《聊聊架构》读书分享

上周得到的消息这周六要做读书分享，要求是岗位相关书籍，看了一下手头未读的书于是选了这本。一周时间，这本书其实是读得比较仓促的。通读下来，感觉这本书应该定义成一本速读书（因为内容比较宽泛、点到为止，而且偏概念化），但是我尚未达到通畅速读该书的前置要求（最好是对于公司整体软件架构有一定认识）。

该书是通过InfoQ的渠道买的，是InfoQ自己做的第一本书。编辑出书的意图是脱离具体架构体系，聊一聊大部分公司共同的一些架构理念。适用人群还是技术人员，用作者的话讲就是“本书虽然不是技术书籍，不谈技术，却是以帮助技术人员为出发点的”。作者写作的目的是“提供给读者一个思考的出发点，一个思考的方向，一个思考的角度，使读者不再惧怕或排斥业务，并可以像业务人员一样思考，和架构师一样思考，不再受困于业务和架构，甚至是技术本身”。

本书的标题是《聊聊架构》，作者是按照三个模块排布内容的，认识架构，软件架构，软件架构的应用。

认识架构部分介绍了与架构相关的一些概念，包括生命周期、架构的定义、抽象、流程；一些概念和架构的关系，时间与架构的关系、架构和树的关系、识别问题和架构的关系；为什么会产生架构，为什么需要了解概念、架构中的切分原则是什么、什么是架构师。

软件架构部分，介绍了什么是软件、软件的生命周期、什么是软件架构、什么是软件架构师、业务、架构和技术三者的关系、介绍软件研发、介绍软件的架构拆分、如何写好代码、单元测试、软件架构和面向对象、软件架构与设计模式、软件架构和软件框架、软件运维、软件访问生命周期、软件架构和大数据、软件架构和建筑建构。

软件架构的应用部分，举例一些经常遇到的应用场景，有交易、产品、用户、订单、交易系统和事务。

后面我会站在我的维度，按照本书的内容排队，讲述一些我从书中受益或者我对书中感兴趣的内容。因为每个人的知识结构和认知体系是不一样的，所以我所侧重的内容可能并非是大家有兴趣的内容。不过没关系，如果大家对我没讲述到的内容感兴趣，这正是大家再读这本书的原因。

认识架构

这部分核心想说明的问题是，是什么和为什么

生命周期（Life Cycle）是什么？本书中生命周期指的是对某一个活动的完整过程。比如用户玩斗牛游戏就是一个生命周期，这个周期有自己的出生（玩家创建斗牛房间）、长大（玩家玩斗牛下庄、亮牌）、变异（某玩家掉线、或某玩家中途加入）、衰老（大部分玩家退出游戏）、消亡（玩家解散房间）。这个概念和很多其他专业书籍中所讲述的“抽象”是一个意思。比如我们拿到一个新项目要做程序设计，我们在调研完之后会建模，建模的过程就是把实际概念进行抽象，按照本书的说法，也就是确定生命周期（斗牛游戏过程）。然后我们会把生命周期切分成更多更小的生命周期（创立房间、抢庄过程、发牌过程、亮牌过程、结算过程、语音聊天过程）、拆分出哪些是核心的生命周期（创立房间、抢庄、发牌、亮牌、结算）、非核心生命周期（语音聊天）如何排布。这个切分和拆分的结果，就是架构，切分和拆分的过程就是架构设计。

为什么会产生架构（广义上的架构）？作者认为架构是源于分工才产生的。比如建筑架构，正因为我们把钢材焊成不同功能的零件，才需要考虑如何布局这些零件，也就是如何设计建筑的架构。

那为什么要先介绍这一部分呢？个人认为是因为我们程序猿的惯性思维模式是因果思维。这种思维模式从在学校学习专业知识时就开始养成，我们学习编程语言了解计算机所能做的内容，学习操作系统、编译原理、网络、软件工程这些课程其实都是围绕着计算机是什么能做什么为什么能做这些事情这个大因果展开的。工作后也是这样子，我们会遇到新需求（这个需求是什么），我们要考虑怎么实现（为什么实现的结果是这个结果，我们如何通过编程达成这个结果）。

另外再分享一个点，书中有一节标题是“人人都是架构师”。我们生活中也经常遇到类似情况，比如人人都是设计师，所有问题都是算法问题，所有问题最终都是运营问题一类的。这类思维，其实是鼓励用特定的思维模式来思考问题，这种方式对于特定问题都是不错的解决方案，但是一旦超出其特定领域，就力不从心了。比如遇到设计类问题，都从架构的角度入手，是可行的。但是你要说想找老婆也从这个角度入手，那就？ ？ ？ ？了。

软件架构

这部分我想分享的章节是

什么是软件架构师（第15章）

这章讲述的内容有

15.1 软件架构师的区别

之所以说区别，是因为没有一个严格意义上认证什么是软件架构师的标准。作者的隐含观点是，只有熟悉业务的熟练软件工程师才能算软件架构师，单纯的只关注于软件和计算机的“架构师”，其实是软件技术能力较好的软件工程师。

15.2 软件架构师的困境

这里的困境主要指，软件架构师本身所处的领域是软件层次，很多时候需要深入解决业务范畴问题的困境。之所以叫困境，是因为深入业务范畴有沟通成本和时间成本上的不确定损耗。

15.3 生命周期的思考

15.4 软件架构师的权利

15.5 软件架构师和技术人员对技术的态度区别

技术人员往往是偏好于使用自己所擅长的、最新的技术解决现有问题。而架构师在技术选型时，可能还要考虑当前公司现有的技术储备、面对的是什么量级的问题，综合考虑成本和产出回报。

15.6 架构师是技术的使用者

15.7 如何保障架构落地

这里说的主要是架构师最好能有组织架构和拆分架构的权力，因为拆分和组织的过程会决定架构落地的过程。（这里反过来想，如果所做的事情刚好是组织或拆分，就可以用架构的思维模式来考虑利弊 ）