杂谈 | 聊聊数仓建设中那些屎山代码

原创内容

No.781

杂谈 | 聊聊数仓建设中那些屎山代码

最近工作在忙着重构前人的屎山代码，分享一点心得。

图片由夸克AI绘制

最近没怎么更新，在忙别的事情，外加偷懒去了。

总得来说最近工作上稍微有点闹心，在重构一些积攒了很久的屎山代码，和跑了很久突然有人冒出来说逻辑有问题的脚本。

总的来说在回看一个传了好几年好几代开发的脚本的时候还是有一些比较有趣的发现的。

数仓迭代本身就是一个会逐渐变成屎山的过程。

最近在回看的代码大概是经过了3年左右的迭代，因为指标逻辑的特殊性，统计逻辑和统计指标基本是一年一大改，一季度一小改这样的改动频率，经过了大概4个开发人员开发维护之后，脚本已经变得让人头秃了——层层嵌套，每一层都是几千行的逻辑。

在仔细研读了前人的代码之后我大概已经推测了脚本会变成这样的原因：每一次改动提出的时候时间要求都比较紧张，于是开发都选择了在之前已有的脚本上做个小补丁，让脚本能够跑下去就行了。随着时间的推移，这种小补丁就会越打越多，时间久了连开发自己都记不清一些小补丁为什么要存在了。

在不换人的情况下，这种在之前的脚本的基础上不断打补丁的做法可能还不会引起什么巨大的问题。但是一旦出现人员的离职交接各种隐患就开始埋下了。按照常理来说，一个刚入职的新人通常的做法都是不会去动前人一些看起来有点反常识的代码，在时间紧任务重的情况下，做法就是继续在前人的脚本基础上继续打补丁。

在辗转了很多人之后，我看到得这个代码就已经变成了难以理解的版本：一个很简单得逻辑写得巨复杂，中间有很多大可不必的步骤，脚本比我命都长，看得人头昏眼花。外加文档的缺失，基本都是死无对证的悬案。

作为后来者，我可以站着说话不腰疼地在这里批判前人的代码是屎山代码，但是平心而论，我几乎可以确定的是我手里的代码在经过了一段时间之后这段代码也终将成为一个新的屎山。

原因是我们无可避免的遇到业务部门在一些指标定义的细节问题上反复横跳，导致每次调整都是时间紧任务重的情况，这种时候对于代码的逻辑上必然不会那么考究，而这种不那么考究的做法一定到导致代码迟早有一天变成屎山代码。

文档&修改日志真的非常重要。

说起来挺好玩，我听过很多次“我们是敏捷开发，我们不写文档”的说辞。真的不是某一个团队的问题，我感觉我接触过的所有所谓敏捷开发的团队都跟我说过这么个说辞。

敏捷宣言的原文是：Working software over comprehensive documentation，而我实际看到的情况是文档一个字都没有，或者有和没有区别不大。

按说敏捷开发下，文档的内容应该是简单清晰切中要害的，而不是一个拘泥于形式的的文档。我实际看到的文档是有一大段内容说项目背景，扣了很多很大的帽子，但是没写最关键的信息：项目需求方对接人是谁。或者文档长达几百页，打开一看满屏都是对表结构的罗列，一点关键的信息比如某一个字段是怎么定义没写，就写了是varchar还是int，这种文档真的是有和没有一样。

数仓的搭建和传统软件开发还是有很大的区别的，逻辑上有太多的细节问题，比如对于某一种特殊情况我们做了取高的处理，为什么要这么处理，基于什么样的考虑等信息，没有相应的记录就会导致后人不敢动前人的代码——我觉得逻辑有点不合理，但是我不知道当时是不是有什么特殊的约定，所以还是不动为妙。

解决屎山最高效的方案是直接拿着需求重写一遍。

在项目中我的角色其实不是去coding的ETL开发，我的角色更多的偏向于把业务需求转为技术需求，并且跟进开发进度和质量的角色。

接下重构代码任务的ETL开发最常问我的一个问题是：你知道之前为什么要这样写么？在经历了一段非常痛苦的看代码之后，我们发现还不如从需求出发去重写代码。

不再关心前人为什么要这样写，而是把思路改成优先从某一个指标的统计逻辑是XXX出发，在写脚本得时候可以参考之前的某一段代码中的逻辑，这样在整个开发过程中能够避免被一些前人不知道理由的逻辑给误导。

我们很容易陷入一种误区，那就是我一定要先看懂前人的怎么写得，才能想到怎么去修改。但是对于ETL里很偏统计逻辑的这种任务，很多时候看懂别人怎么写还不如直接从需求本身出发。也算是在完成这个坑爹的任务的过程中的一点踩坑经验吧。