聊聊我和鹅厂的一点往事

同样地，人们已经创建了许多数据工程工具来改善这一过程。函数式编程可让创建的代码重用在许多数据工程任务中。

2. 设计专用型函数

要使函数可重用，编写专用型函数是一种很好的实践。可以设计主要功能，并把不同的部分连接在一起。总的来说，笔者发现通过使函数缩小应用范围(即专门用于某项任务)，可以更快地开发代码，因为识别和修复单个元素的错误更为容易。

功能范围更小也使得交换单个组件变得更容易，可以将它们像乐高积木一样针对不同的用例组合在一起。

3. 正确的命名规则至关重要

将对象进行命名，这样其他人查看代码时就可以立即理解你的意图，这种做法非常不错。但有些缩写可能不是每个人都能理解，所以最好避免使用，而是选择写出全名。我见过的大多数数据工程师倾向于使用以下协议：

• 使用动词作为函数名，ex. get_dataframe_from_google_ads()可能比google_ads()更容易理解——较长的版本不仅能显示源系统，还可指出函数执行的操作和它返回的对象类型(数据框架)。它看起来很冗长，但通常只需要编写两次：一次是在定义时编写，一次是在调用时编写。因此，笔者认为编写那些较长的函数名是值得的。
• 大写全局变量——与笔者工作过的大多数数据工程师都将全局变量定义为大写，以区别于局部变量(例如主函数中的变量)。
• 许多人认为最好只在脚本的顶部定义导入——理论上，可以在函数或类中导入库，但是如果所有的导入都在脚本的顶部，那么跟踪包依赖关系可能会更容易。

理想情况下，命名可以使代码自我记录，这也可以实现高效编程。

4. 简洁而高质量的代码更便于维护

通常，程序员读代码要比写代码更频繁。因此，使代码易于阅读和理解是非常重要的。

通过进行恰当的命名和建立良好的结构，我们可以便利个人未来的工作，其他人在使用我们代码时也会更容易。代码简洁好处多多：编写的代码越少，需要维护的代码就越少。如果可以用更少的代码完成任务，这也是一种潜在的胜利。

5. 文档是关键，但前提是要做得正确

这听起来可能违反直觉，但是我们不应该记录代码在做什么;相反，我们应该记录为什么代码要做它正在做的事情，很多代码注释老在说明一些显而易见的事情。

例如，get_dataframe_from_google_ads()函数不必说明我们正在从谷歌广告下载数据，而应说明这样做的原因，例如“下载广告支出数据以供稍后的营销成本归因”。使用docstring或类型注释来记录函数的预期输入和输出非常有帮助，它能立马让你摇身一变成为更好的数据工程师。

6. 避免硬编码值

许多与ETL相关的SQL查询使用阈值但没有解释原因。例如，假设有一个脚本从某个表中提取数据，但只针对发生在2020年9月30日之后的事件，而且绝对没有文件证明为什么有人选择了这个特定的日期。

在不解释原因的情况下，人们要如何才能发现为什么这个值是硬编码的?这可能是因为，在那天，公司转向了一个新的源系统，新的数据提供商，或者他们可能改变了一些商业策略。笔者并非指在代码中这种业务逻辑是错误的，但如果不记录为什么有人选择了这样一个任意的阈值，这个硬编码的值在未来几年里可能会一直是下一代数据工程师的一个谜。

（编辑：宣城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!