在谈论模块化开发之前，不得不提到近年来火热的数据中台的概念。在众多繁杂的对数据中台的定义中，有的偏重于功能，有的偏重于特点，似乎没有一个权威的定义，我更倾向于用四个字来描述，那就是“共享复用”，虽然很短，却道出了数据中台的本质，这也一直指导着我在数据仓库的具体实践。
云巧标准，包括了自治、云原生、可发现、可编排、健壮、模块化6个维度。其中，复用一词跟其中的模块化开发的核心理念不谋而合。
水无定势，兵无常法，但大的道理总是相通的，并能够随着时间的发展赋予新的生命，但抽丝剥茧之后，留下来的本质东西大同小异，模块化开发的理念便是如此。
我们知道，数据仓库的发展经历了三个阶段，简单报表阶段，数据集市阶段，数据仓库阶段，在报表阶段，数据开发人员为了减轻工作量，在多变的需求中把常用的核心指标逻辑沉淀下来，在下次有相同的需求时，拿来即用，这其实就是复用的思想。
各种编程语言中的函数，数据仓库的标签体系，甚至于数据中台的核心理念，都是把模块化的思想发挥到了极致，避免了我们重复造轮子，消除了数据烟囱，用最小的投入获得了最大的产出。
在具体的项目实践中，深刻理解了模块化开发的好处，并多次从中受益，不管这种思想叫“数据中台”也好，叫云巧也罢，但都体现了模块化组装式开发的思想。
举三个典型的例子：
其一，在中国移动的B域数据治理过程中，有一个场景是需要通过产品实例id,去判断这个产品是移动，固网，宽带还是其它，因为来源系统的数据业务含义不同，不同的省份，甚至同一省份下的不同地市就有不同的判断逻辑，体现到代码里，就需要编写各种case when,以致最后这个代码特别长，当时我们的做法就是把这段逻辑固化下来，在整个数据中台中出现有且仅有一次，以便于能够在需求逻辑变更的时候，变更这一处代码即可，可以想像，如果有多处这样的代码出现，代码冗余不说，极易出现指标不一致，结果不统一，维护困难，那会是一件多么痛苦的事情。
其二、曾经遇到过这样一个需求，因为要计算各种同比环比指标，但牵涉到2月情况特殊，有的28天有的29天，再做环比的时候，如果在3月30号的时候去计算环比，那就得给出明确的业务计算公式。需求如下：
乍一看，会不知所以然，但抛开问题的表面，其实质只是要通过输入一个日期值去返回一个要对比的日期值而已，理解到这个问题的本质后，问题就迎刃而解了，我们把这段逻辑固化到一个udf函数里，对这块儿逻辑进行了封装，如果当初我们一味的用sql去实现，大概率不会如此完美的解决这个问题，这就是模块化思维的重要案例。
其三，有一个场景是计算单车的top排名。数据是共享单车的订单表，核心字段是开始经纬度，结束经纬度，订单的开始时间和结束时间，在做了常规的数据标准化，属性冗余之外，根据业务需求的特点，要经常计算从某个围栏出来的top5目的地和从某个围栏结束的top5出发地，我的做法是加工出来这样一个通用的能力模型，把所有的围栏的出发地和目的地提前加工出来，在使用时稍加限定即可，这样一个模型为后续的业务开展，以及融合其它的业务的时候直接拿来即用，而不是重复的造轮子，节省了很多人力，这也是模块化思想的一个重要案例。
可能有人会说，你的这个模型支撑不了xx场景，我想说的是凡事总有例外，你能解决大多数问题就可以了，生活中的“八二原则”处处可见。
这样的一个能力模型一来稳固，二是便于维护，就像是一棵参天大树的躯干一样，无数的数据看板、大屏指标，可视化应用都是生长在这个躯干下的枝叶，在这个躯干基础上稍微加工即可。有了这样的躯干，我们就能够避免很多的指标不一致问题，这个躯干是我们数据应用的中流砥柱，所有的上层数据应用只是临门一脚问题，这临门一脚准不准，快不快，好不好，完全取决于我们建设的这个躯干是否科学合理。
可以看到，模块化思想的运用，前提是对业务有充分的理解和对问题本质的把握。你只要掌握了模块化思想的本质，并能够在实践中运用，很多事情会事半功倍。
