数据工程是本世纪开展最快的行业之一。任务以来，笔者在各个公司见识了许多确保数据和代码质量的办法。每个公司能够遵照不同的流程和标准，但是有一些通用的准绳可用于提高开发速度，改良代码维护，降低数据任务难度。
1. 函数式编程
笔者学习的第一种编程言语是Java。虽然深知面向对象编程与创立可重用类和模块相关的益处，但其在处置数据时不便运用。两年后，笔者偶然发现了R言语——一种函数式编程言语，笔者立刻就被它迷住了。
R言语可以运用dplyr包并复杂地经过管道传输函数来转换数据并快速查看结果，大大便利了任务。但如今，Python要求将二者结合，编写面向对象的模块化脚本，同时应用函数式编程，这种编程在与R言语中的数据交互时运转良好。
函数式编程极端适用于处置数据，缘由就在于简直任何数据工程义务都可以经过输入数据完成，运用一些函数(也就是说，完成ETL中的T环节，即数据的转换,清洗及加载)，将其输入加载到某个集中存储库，或许用于撰写报告或数据迷信用例。
函数式编程范型在数据工程中十分常见，许多博客都写过关于它的文章。例如，下面链接的文章，是Apache气流的开创人马克西姆·博切宁在2018年终宣布的：https://medium.com/@maximebeauchemin/functional-data-engineering-a-modern-paradigm-for-batch-data-processing-2327ec32c42a
异样地，人们曾经创立了许少数据工程工具来改善这一进程。函数式编程可让创立的代码重用在许少数据工程义务中。
2. 设计公用型函数
要使函数可重用，编写公用型函数是一种很好的实际。可以设计主要功用，并把不同的部分衔接在一同。总的来说，笔者发现经过使函数增加运用范围(即专门用于某项义务)，可以更快地开发代码，由于辨认和修复单个元素的错误更为容易。
功用范围更小也使得交流单个组件变得更容易，可以将它们像乐高积木一样针对不同的用例组合在一同。
图源：unsplash
3.正确的命名规则至关重要
将对象停止命名，这样其别人查看代码时就可以立刻了解你的意图，这种做法十分不错。但有些缩写能够不是每团体都能了解，所以最好避免运用，而是选择写出全名。我见过的大少数数据工程师倾向于运用以下协议：
· 运用动词作为函数名，ex. get_dataframe_from_谷歌_ads()能够比谷歌_ads()更容易了解——较长的版本不只能显示源系统，还可指出函数执行的操作和它前往的对象类型(数据框架)。它看起来很冗长，但通常只需求编写两次：一次是在定义时编写，一次是在调用时编写。因此，笔者以为编写那些较长的函数名是值得的。
· 大写全局变量——与笔者任务过的大少数数据工程师都将全局变量定义为大写，以区别于部分变量(例如主函数中的变量)。
· 许多人以为最好只在脚本的顶部定义导入——实际上，可以在函数或类中导入库，但是假设一切的导入都在脚本的顶部，那么跟踪包依赖关系能够会更容易。
理想状况下，命名可以使代码自我记载，这也可以完成高效编程。
4. 繁复而高质量的代码更便于维护
通常，顺序员读代码要比写代码更频繁。因此，使代码易于阅读和了解是十分重要的。
经过停止恰当的命名和树立良好的结构，我们可以便利团体未来的任务，其别人在运用我们代码时也会更容易。代码繁复益处多多：编写的代码越少，需求维护的代码就越少。假设可以用更少的代码完成义务，这也是一种潜在的成功。
5. 文档是关键，但前提是要做得正确
这听起来能够违犯直觉，但是我们不应该记载代码在做什么;相反，我们应该记载为什么代码要做它正在做的事情，很多代码注释老在阐明一些不言而喻的事情。
图源：Reddit
例如，get_dataframe_from_谷歌_ads()函数不必阐明我们正在从谷歌广告下载数据，而应阐明这样做的缘由，例如“下载广告支出数据以供稍后的营销成本归因”。运用docstring或类型注释来记载函数的预期输入和输入十分有协助，它能立马让你摇身一变成为更好的数据工程师。
6.避免硬编码值
许多与ETL相关的SQL查询运用阈值但没有解释缘由。例如，假定有一个脚本从某个表中提取数据，但只针对发作在2020年9月30日之后的事情，而且相对没有文件证明为什么有人选择了这个特定的日期。
在不解释缘由的状况下，人们要如何才能发现为什么这个值是硬编码的?这能够是由于，在那天，公司转向了一个新的源系统，新的数据提供商，或许他们能够改动了一些商业策略。笔者并非指在代码中这种业务逻辑是错误的，但假设不记载为什么有人选择了这样一个恣意的阈值，这个硬编码的值在未来几年里能够会不断是下一代数据工程师的一个谜。
7. 避免保留僵尸代码
笔者常常遇到的一种常见的反形式是，有人保留了已弃用但遗留在脚本注释中的代码。也许有人想测试一些新的行为，保留旧版本以防新版本不能运转，或许这团体想要保存历史记载。笔者以为最好避免这种状况，由于它能够会使之后的开发人员很难区分哪个才是真正正确的版本。
例如，笔者曾阅历过这样一种状况：被注释的代码片段比没有被注释的版本更有意义。但有时状况却往往相反，由于他或她会以为，被注释掉这个更契合逻辑的版本是错误的。因此，保留僵尸代码能够是风险的。
图源：unsplash
8. 正确完成模块化：将业务逻辑与适用顺序函数别离
将适用函数和业务逻辑混合在一同具有一定意义，但是将它们分开依然有用。假设运用妥当，公共功用可以被推到不同的包中，并在以后跨多项目重用。这种别离需求更多的前期任务(例如，为这样的包构建一个发布进程)，但是从长远来看，可重用性和只定义一个功用的益处是值得的。
9. 简化代码
Python的宗旨是“复杂比复杂好。”
许少数据工程师，特别是那些有计算机迷信背景的工程师，可以创立复杂的处置方案，却过于繁复无法不够复杂明了。例如，假设某些东西可以表示为一个复杂的函数，该函数接受一些数据作为输入，并前往转换后的版本作为输入，那么为这种操作编写自定义类对象能够被以为是一种设计过度的处置方案。
10.放远目光
有时分我们需求在正确和快速之间做出权衡。创立通用型处置方案，以跨不同用例重用，从长期来看，这将使代码编写任务更为容易，开发更长。
例如，为跨项目共享的模块树立一个发布进程和CI/CD管道能够会在前期破费少量时间，但是这种额外的努力通常会在前期失掉报答。花时间创立继续验证和监控数据质量的脚本异样如此。
图源：unsplash
(责任编辑：admin)