<<聊聊架构>>读后笔记

聊聊架构这本书很有意思,作者在这本书中并没有讲解具体的技术解决方案,而是针对架构到底是什么、架构解决了什么问题、架构需要什么条件等角度,阐述了自己对架构的认识。
打个比方,比如LOL的教学,大多数教学是告诉你某个英雄怎么玩有什么技巧或者最佳的刷野和出装路线是什么,而作者这个教学是从他的角度告诉你,获胜的策略有哪些,为什么要分上中下打野这几个位置以及各个位置的职责。

下面写一下自己收获比较大的一些点:

1. 生命周期
  • 意义:作者认为一切事物都有生命周期,业务与软件也不例外,每个生命周期都有自己的主体,而每个生命周期可以继续的拆分出核心生命周期和非核心生命周期,拆分出非核心生命周期的意义是能够使原本单人需要串行完成的工作产生分工,这样能更合理的利用时间,高效并行的完成核心生命周期。
  • 非核心生命周期:非核心生命周期的意思并非是说该生命周期不重要,而是不需要自己亲自干,可以分工出去给别人干,用来提高并行度。
  • 与架构的关系:架构的工作就是要能对核心生命周期进行合理的拆分,确认其主体,分配负责人,设立各周期间的沟通机制。
2. 权责对等
  • 意义:架构对业务的声明周期做切分设计后,更关键的是确定各周期的负责人,只有做到了每个周期的负责人全责对等才能保证架构的落地。
  • 结果:架构的切分会导致职责和利益的重新分配,因此架构的切分结果最终一定要体现在组织结构上,否则就是一个没有落地的架构。
3. 理解业务
  • 意义:架构为业务而服务,因此一定要先理解业务的核心生命周期,知道业务当前遇到的问题和瓶颈是什么,才能做架构设计。而每个业务领域都会有很多概念,因此进入一个领域,首先弄清楚该领域的一些常见概念也非常重要。要理解业务,首先要克服对时间的焦虑,不要急于设计各种技术方案,而是要先识别出当前的问题是什么。而识别问题分两步,寻找问题的主体,确定问题是什么。
4. 架构
  • 目标:支持业务的快速增长。
  • 核心:架构的核心架构的执行。
  • 原则:以业务为核心,拆分后不应该影响外部访问行为,如果影响了,这说明是结构或者业务发生了变化。
  • 架构师职责:除了要掌握软件技术还要掌握业务技术,能够为拆分出的各生命周期选择出合适的技术。
5. 业务、技术、架构三者关系
  • 概念:业务是核心,技术是解决业务问题的工具,架构是让业务长大的组织方法。
  • 关系:架构需要用技术来实现拆分,技术需要架构来合理组织以提升效率。
6. 学习开源技术
  • 核心:代码的核心在于作者对其理念的实现,而不是代码本身,要掌握好作者的理念,一般要先从理解作者面对的问题入手,也就是从业务入手,分析作者是如何拆分业务生命周期的。
7. 软件架构
  • 影响因素:业务的组织架构,软件架构最好能合业务组织架构匹配;软件开发团队自身的组织架构;用户流量对软件的冲击。架构的根源以及公司的最终目标都是流量的增长。
8. 代码结构
  • 分类:存储业务代码;业务逻辑代码,要保持内聚;服务代码,用户的访问通道,负责组合调用不同的业务,对不同角色的用户提供不同的访问通道;黏合代码,对业务和存储的封装,通过存储保存和加载业务中对象的状态。
  • 各自特点:服务、黏合、存储代码都是严格的访问代码,只要做连通性测试即可,业务代码需要做单元测试。服务代码不要考虑代码重用,要针对不同角色提供不同的服务调用;业务代码必须要考虑代码重用。
9. 单元测试
  • 适用范围:业务代码需要,判断依据的有两点,方法能否用一个main函数执行;方法的参数能否自由模拟,而不依赖外部环境。
  • 好处:是对自己工作效果的反馈,同时也是对保证自己代码质量的责任;能消除自己对测试工程师测试时的焦虑心理;能帮自己检验业务逻辑是否分散到了访问代码中。
10. 设计模式
  • 分类:创建型、结构型、行为型。
  • 应用:黏合代码是为了给业务对象加上状态,可以用到装饰器;服务代码很多时候扮演的就是代理;存储基本上是适配器。
  • 怎样用:不但要了解各种设计模式所能解决的问题,还要了解自己要解决的问题。
11. 框架
  • 概念:框架基本上是根据业务模型,或者设计模式等,把模型中稳定的部分进行封装,形成一个大的边界,但对具体内容仍留有余地。
12. 产品、商品、企业、软件
  • 产品构成要素:产品本身以及访问到产品的途径,因此产品也可以分为制造类产品和服务类产品。
  • 商品:用来交易的产品单元,可同时包含产品和访问产品通道两部分的价值。
  • 企业:企业的产品来源于企业对自己在人类社会的分工定位,也就是企业的愿景,企业产品的价值来于对人类问题的解决。
  • 软件:衡量软件的价值的一个重要因素是对软件的访问量。
13. 订单
  • 概念:为了把每个交易的生命周期过程串联并记录下来,并和客户形成一对一的交易跟踪,就形成了订单的概念。所有企业的产品提供给用户的过程都可以看做是交易,因此其实每个企业都有自己的订单,只是订单的形式不同。
14. 事务
  • 另一种解决方案:参考复式记账的方法,事务其实可以由业务自己来保障,数据库等其他系统提供的事务本质也是一种辅助手段。

你可能感兴趣的:(<<聊聊架构>>读后笔记)