一、引言

     最近看一些狙击手题材的电影的时候，发现这些狙击手身边多了有一个角色------观察员。











之前看得一些狙击手都是个人英雄主义，一个人扛着杆枪，又是找地点，又是一埋伏就一动不动的埋伏好几天。









看来可能也是战场形势变化了，狙击手也组织架构升级了。



出于好奇，特意去搜了一下观察员是干嘛的。

一、文字记录，大致就是目标是谁、任务时间之类的。

二、目标区域速写图，画出目标区域景物的相互关系（比例，透视关系等）。

三、射程卡，用若干同心圆标示出不同目标的方向、距离、仰角等，还要标上风速风向，这个是用来计算弹道和偏移的。

四、训练的时候还要写其它的数据资料卡，记录一些详细的参数。

五、观察狙击手的弹着点，确认射击结果。如果一枪未中，需要根据弹着点再次给狙击手建议。

看完这个观察员职责的介绍，突然感觉这个也是一种系统架构升级的思路。





二、结合工作

2.1、工作概述

      最近在负责财务域的付款核销组件，给大家简单介绍一下这个组件的功能

      付款核销组件会受理一大堆上游系统产生的账款数据，我们会把这些数据抽象成待核销流水，关键字段如下：

2.2、现状问题

      一开始，核销逻辑还算简单，每天都会核销，把到期的待核销流水按财务结算公司的维度聚合到一起生成核销单，聚合的过程中按一级供应商、二级供应商的维度汇总生成核销明细。



     但是随着接入的产品越来越多，各个产品的个性化需求也越来越多。有的产品要按一级供应商维度生成核销单、有的供应商有固定付款日期，只能在每月的固定几天生成核销单、有的供应商有黑明单控制、有的供应商需按一级供应商维度做倒挂帐控制、有的供应商需按二级供应商维度做倒挂帐控制、有的要求预付、应收类型的待核销流水不能与别的待核销流水核销。



     整个核销任务的复杂度慢慢膨胀了，而且组件owner也很难理清楚组件里面有多少能力。单纯的提高狙击手模块的复杂度会越来越难以测试、难以维护，因此我打算做大做强观察员模块的逻辑，为狙击手模块保驾护航。





2.3、解决思路

观察员标记

     简单说来就是一个待核销流水受理进来，我的观察员模块会对这个待核销流水做个分析，并对这个待核销流水打标，标记一下这条待核销流水预计会什么时候被核销、预计会被什么样的任务核销。



     这样一来，在核销之前我可以通过标记，在数据层面看看我的核销逻辑对不对，方便测试，也方便我在核销之前做一些数据稽核，验证我的逻辑。

    比如：HM的ADR_VER类型的流水只能被ADR类型的核销任务核销，我可以写个sql做稽核，where merchant_code='HM' and ledger_type='ADR_VER' and plan_verify_task not like '%ADR%'

狙击手射击

     实际核销时，狙击手模块把待核销流水拉出来真正做核销，核销完标记一下实际核销时间、实际任务核销。

观察员确认结果

     核销之后，我可以观察实际核销日期跟核销任务是否与我标记的一致，这样可以校验一下我的狙击手模块的逻辑是否正确，确实应该不一致的也可以把数据捞出来人工在看一下，做到心中有数。

捞出不一致情况如下：

架构规划

     最后的趋势是观察员模块的逻辑越来越丰富，狙击手可以适当的将一些逻辑放在观察员模块，降低自身的复杂性。同时提高组件整体的可靠性、可测试行、数据标签丰富，方便更多维度的稽核，可以光看数据就对整个组件做到心中有数。

三、总结

     

     引入观察者模块，其实就是在核心模型上打上完整的标，代码里面有的逻辑概念，核心模型是有相应的标与之对应。这样别的相关同学能单纯的通过看数据、稽核数据，来了解你的核心逻辑，知道你代码逻辑写的对不对，而不是去一行行的撸代码。

    标越丰富，稽核越精准，稽核的粒度越细腻，同时也能反哺保障代码更稳定，bug快速发现，可维护性更强。





打王者荣耀的时候都经历过这样的阶段

青铜级：

     选个自己喜欢的英雄，完全靠个人能力，全地图游走。个人能力够强就打的够爽。

王者级：

      大家技术都比较高，战场复杂，容错率比较低的时候，必须得跟辅助配合，辅助标记打谁就打谁。得定点标记，精准打击，不然容易一套输出打完，一个敌人没死。



      所以系统也一样，越来越复杂之后，得有个观察者模块，提高系统的可视性，可稽核性。让狙击手模块能安心的精准打击，同时观察者模块越来越完善之后，可以分担一下狙击手模块的复杂性。