【架构优化过程思考】如何构建技术方案影响的评估能力-CFANZ编程社区

在架构优化的早期，还处于研发或方案设计的阶段时，当研优化相关的需求还没有完成能力的构建，对于技术方案的影响比如，核心指标的变化，用户体验的变化，资源消耗的变化等还处于一个理论的状态，在真实的使用场景的数据是什么样，用户使用的真实体验如何还是未知，如果技术方案可能存在对业务指标产生影响，关于指标变化的摸底还是有必要放在技术方案中一起推进落地的。

评估主要分为两类，一类为线下评估，一类为线上评估。

线上评估：真实的用户使用场景，数据量大，样本全，机型，网络，系统，运营商都有所不同，评估的数据是最真实的。但是，数据是在App上线之后产生的，对于指标的优化需要App再次发版。出现异常之后，对于线上用户的影响较大。特别是用户规模较大的App，较小比率的用户出现了异常，影响量级也是极大的。
线下评估：模拟的用户使用场景，数据量少，样本少，机型，网络，系统，运营商等外界因素的评估与成本有关。线下评估的数据可以在App没有发版之前就进行相关的摸底，对于一些比较重要的影响，可以先进行优化再发布给用户。线下评估的需要使用自动化评估方式，评估投入的资源较低，覆盖的样本也相对的全面。

基于以上两者评估方式，App实现可评估的能力，至少需要以下4个能力

可记录：实现数据的记录及上报的能力，支持对App中需要评估的数据项进行记录。
可对比：实现不同的样本进行抽样，打开或关闭某一组能力。支持App中的同一类中多个能力的流量控制。
可计算：根据评估的需要，进行数据的计算。数据的分析和处理主要基于云端构建的可计算能力，部分数据也需要在App中计算后再同步给云端，比如，一些涉及到用户隐私的信息。
可查看：对于计算出来的数据信息可以进行查看，报表、图表或原始数据。对于计算出来的数据，可以支持研发人员快速了解架构优化之后核心指标的变化，发现问题，或者支持后续优化的决策。

有了基础的打点和对比能力。在App的业务代码中出现的点位信息过多，那么对于代码的可读性是极差的。而多业务场景都有涉及的打点，对于模块的拆解也会产生影响。

而对于App架构来说，可统计和可对比的相关能力，应该作为基础的服务。与业务相关的统计点位的调用，应该与业务逻辑的代码弱绑定。

其它参考