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

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

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

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

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

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

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

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

其它参考

• ​ ​【架构优化过程思考】质量高于效率​​
• ​ ​【架构优化过程思考】避免随机试错​​
• ​ ​【架构优化过程思考】持续技术创新​​
• ​ ​【架构优化过程思考】规范在研发工作中的价值​​
• ​ ​【架构优化过程思考】研发过程组件化收益小结​​
• ​ ​【架构优化过程思考】因事定人优于因人定事​​
• ​ ​【架构优化过程思考】CR的五个关键点​​
• ​ ​【架构优化过程思考】技术方案评估的三个维度​​
• ​ ​【架构优化过程思考】沟通的意义​​
• ​ ​【架构优化过程思考】平台生态优先​​
• ​ ​【架构优化过程思考】技术需求排序原则​​
• ​ ​【架构优化过程思考】主动沟通的基本准则​​
• ​ ​【架构优化过程思考】架构优化工作与功能迭代工作的区别​​
• ​ ​【架构优化过程思考】CR的11个规范原则​​
• ​ ​【架构优化过程思考】评审的价值体现​​
• ​ ​【架构优化过程思考】多端方案对齐​​
• ​ ​【架构优化过程思考】风险的分类及规避​​
• ​ ​【架构优化过程思考】如何保持有效的技术决策​​
• ​ ​【架构优化过程思考】如何降低隐性的资源投入​​
• ​ ​【架构优化过程思考】足够深入理解业务流程​​
• ​ ​【架构优化过程思考】架构优化倒底优化的是什么​​
• ​ ​【架构优化过程思考】发现架构问题的6个视角​​
• ​ ​【架构优化过程思考】问题等同于机会​​
• ​ ​【架构优化过程思考】理解架构优化的资源投入方式及差异​​