说是读后感,根本算不上,当记个笔记,划个重点吧。

Reference

怎么样的架构叫好架构?

代码整齐,分类明确,没有 Common、Core

  1. 代码整齐,这是每一个工程师的基本素质。
  2. 分类明确,不要让一个类或一个模块做两种不同的事情
  3. 不要搞 Common、Core,架构是不断成长,是不断变化的。如果真有特别小的东西,索性单独开辟一个模块就好,小就小点,关键是要有序

不用文档,或很少文档,就能让业务方上手

  1. 尽可能让你的 API 具有强可读性。

思路和方法统一,尽量不要多元

  1. 做架构的时候,你得时刻记住当初你决定要处理这样类型的问题的方案是什么,以及你的初衷是什么,不要摇摆不定。
  2. 善于记录自己的解决思路,不要导致解决同一类似问题有五花八门的方法或者类。

没有横向依赖,万不得已不出现跨层访问

  1. 没有横向依赖,这决定你将来要对这个框架做修补所需要的成本有多大。
  2. 跨层访问是指数据流向了跟自己没有对接关系的模块,有时候是无可避免的,如网络底层信号量变化,需要通知到 View。

对业务方该限制的地方有限制,该灵活的地方要给业务方创造灵活实现的条件

  1. 必须要有能力区分哪些情况需要限制灵活性,哪些情况需要创造灵活性。

易测试,易扩展

  1. 提高模块化程度,尽可能减少依赖关系,便于 mock。

保持一定量的超前性

  1. 超前性不光是技术上的,还有产品上,业务方可以不实现转到正规的方案,但是架构这边,是一定要为这种可知的改变做准备。

接口少,接口参数少

  1. 满足充要条件的前提下,越少的接口,越少的参数,就能降低业务方的使用成本。

高性能

高性能非常重要,但在客户端的架构中,它不是第一考虑因素

  • 客户端业务变化快,做架构首先要考虑因素应当是便于业务方快速满足产品需求。
  • 苹果平台的新能非常之棒,正常情况下很少出现由于性能不够导致用户体验的问题。
  • 苹果平台的优化手段相对有限,但是对于客户端用户来说,10ms 的差距是无感知的。

不重要,不代表用不着去做!

关于架构分层

其实,分层这种东西,真没啥技术含量,全凭架构师的经验和素质。

我们常见的分层架构,主要针对模块分类而言:
有三层架构:展现层、业务层、数据层。
也有四层架构:展现层、业务层、网络层、本地数据层。
与 TCP/IP 分层不同,你这个架构在逻辑上是几层那就几层,具体每一层叫什么,做什么,没有特定的规范。

针对数据流动方向:
MVC、MVVM…

三层架构就是 MVC,MVC 就是三层架构?其实不是!
三层架构,里面没有 Controller 的概念,而且三层架构侧重是模块之间的逻辑关系,MVC 有 Controller 的概念,侧重在于数据流动的方向。

为什么流行起来的是三层架构,而不是四层或五层?

因为所有的模块角色只会有三种:

  • 数据管理者
  • 数据加工者
  • 数据展示者

笼统来说,软件只会有三层,每一层扮演一个角色,其他四层五层,都是这三层之一分出来,最后都可以归纳进这三层中的一层中。

怎么做分层?

这不是在做架构一开始就考虑的问题,虽然外面要按照自顶向下的设计方式来设计架构,一般都是先确定要解决的问题,先确定都有哪些模块,然后在基于这些模块再往下细化设计,再把这些列出来的问题和模块做好分类。
分类之后不出意外,大多数都是三层,如果发现某层特别庞大,那就可以再拆开来变成四层五层…
最消耗脑力,最考验架构师功力:找到所有需要的模块,把模块放在该放的地方。

答案就是没有分层,所谓的分层都是在架构图之后的事情了。模块一定要把它设计的独立性强,这其实是门艺术。

Common 和 Core

不开 Common 原因

  1. Common 不仅仅是一个文件夹,它会是一个 Pod,不管是什么,在 Common 里面很容易形成错综复杂的小模块依赖,在模块成长过程中,会纵容工程师不注意依赖的管理,导致将来如果要将模块拆分出去,会非常困难。
  2. Common 本身与细粒度模块设计的思想背道而驰,属于一种不合适的偷懒手段,在将来业务扩展会成为阻碍。
  3. 一旦建立了 Common,就等于给地狱之门开了一个小缝,每次业务迭代都会有一些不太好分类的东西放入 Common,这就会给维护 Common 的人带来了巨大的工作量,体力活且容易出错。

不开 Common 好处

  1. 强迫工程师在业务扩展的时候讲依赖管理的事情考虑进去,让模块在一开始发展的时候就有自己的土壤,成长空间和灵活度非常大。
  2. 减少各业务模块或者 Demo 的体积,不需要的模块不会因为 Common 的存在而包含在内。
  3. 维护性大大提高,模块升级之后要做的同步工作非常轻松,解放 Common 维护者。
  4. 符合细粒度模块划分的架构思想。