其他
客户端架构设计的过程
引言工作中我们会讨论很多关于架构设计的话题，最常见的是围绕某个具体的业务场景，结合程序设计的基本原则、设计模式，讨论具体的架构设计方案。对于架构设计的过程，大家却讨论的很少，以至于每个工程师都会有这样的经历：眼前有一个问题，代码已经很难维护，但不知道是否应该重构，架构设计从何下手，如何判断方案合理。本文的目的是总结对架构设计过程的一些思考，抛砖引玉，欢迎讨论。一些前置想法在开始讨论架构设计问题之前，我们需要先讨论2个问题：架构设计的目标是什么？什么时候需要设计新的架构？架构设计的目标简单的说，架构设计的目标是支撑业务的变化。这句话可以从几个方面来解读：业务的发展方向可能是横向（增加功能，满足更多人群的需求），也可能是纵向（把某个功能做细做深，提升用户体验），此时，架构设计的目的是支持好这些业务的需求，保证可用性。随着业务的持续迭代，工程复杂度提升，往往会发现一些架构瓶颈，影响迭代效率。此时，架构需要做的事情是预测/感知/收集到这个变化的趋势，做好工程、业务代码的调整，保持业务灵活迭代。著名的康威定律指出，组织架构决定系统架构。业务可能变大或变小，也可能拆分或合并，与之对应的，团队也会调整，为了方便沟通，架构的组织结构可能会逐渐向团队的组织结构靠拢。是否需要新架构？我们看到很多代码劣化的原因，往往不一定是架构不能适应，而是写代码的人没有遵循架构设计者的思想，违背了原架构的规范。其实大部分时候原架构都能满足需求，仅仅需要深入分析原架构和当前的问题，理解设计思想，在此基础上扩展、局部重构，比起盲目重写，能够用更低的成本更好地解决问题。什么时候会需要新的架构呢？做一个全新的业务，需要新建一个系统。可以了解一些已有系统的设计，借鉴/组合已有的方案，少走弯路业务变化导向的新需求很难在原架构上通过扩展实现，频繁地修改系统底层模块，系统可用性变的越来越差，此时可能需要对原架构进行调整，或设计一套新的架构架构设计的过程架构设计的过程会经历几个阶段，与软件开发的工程类似，如下图所示：需求分析这一步我们需要收集所有的需求和当前遇到的问题，将这些信息整理成用例。以一个Feed场景为例，我们可以梳理出以下用例：实际情况还会涉及到埋点、推荐场景特殊的传参规则、视频、图片预加载等需求，远比上述用例要多，但为了讨论架构设计问题，我们只看核心需求。下文将继续使用Feed场景的例子，一步步来看我们是怎么做列表架构设计的。梳理业务流程整理出所有的用例之后，需要将我们对当前业务场景的认识转化成功能的业务流程，明确流程中的关键角色、角色的职责和角色之间的关系，同时梳理出核心流程的生命周期（状态机）。继续以前面说到的列表场景为例，我们可以梳理出如下核心业务流程。其中我们会发现有几个关键的角色，他们职责如下：页面：负责维护页面加载的状态，触发加载流程，并通过骨架图、空态、内容等给到用户反馈。页面的状态变化如下数据源：负责加载页面的数据，可以设计成有状态（DataSource）或无状态（Repository）列表：通常包含一个系统列表组件（RecyclerView/UICollectionView），支持根据数据加载卡片，并且在列表内容的滚动过程中，动态创建/复用卡片卡片代理：作为列表和卡片之间的代理，负责将列表中每一个数据Item转换为一个卡片卡片：列表中的各种卡片关注核心问题对比需求分析中我们列举的用例，会发现在我们梳理出来的核心业务流程中，有几个功能/角色并没有覆盖到，例如登录相关的操作、首页底Tab点击刷新、卡片局部差异等，原因是我们始终要关注核心问题，其他的角色要么可以被核心问题所覆盖，要么不应该在当前被讨论。例如：登录/退登导致的刷新：可以通过重置页面状态+开始加载来实现，已经被核心问题所覆盖卡片局部差异：由于卡片的业务属性很强，灵活度很高，且不依赖于列表。因此卡片内部结构的处理应该作为单独问题讨论问题拆分目前的核心流程中，我们可以看到2个部分：关于页面状态，这部分描述页面状态如何变化，以及如何将数据更新到列表，交给卡片代理关于卡片代理，这部分描述列表更新数据