辗转多个公司，我从与数据打交道的工作中学到了什么？( 二 ) 全文共

6.避免硬编码值
许多与ETL相关的SQL查询使用阈值但没有解释原因。例如，假设有一个脚本从某个表中提取数据，但只针对发生在2020年9月30日之后的事件，而且绝对没有文件证明为什么有人选择了这个特定的日期。
在不解释原因的情况下，人们要如何才能发现为什么这个值是硬编码的？这可能是因为，在那天，公司转向了一个新的源系统，新的数据提供商，或者他们可能改变了一些商业策略。笔者并非指在代码中这种业务逻辑是错误的，但如果不记录为什么有人选择了这样一个任意的阈值，这个硬编码的值在未来几年里可能会一直是下一代数据工程师的一个谜。
7. 避免保留僵尸代码
笔者经常遇到的一种常见的反模式是，有人保留了已弃用但遗留在脚本注释中的代码。也许有人想测试一些新的行为，保留旧版本以防新版本不能运行，或者这个人想要保存历史记录。笔者认为最好避免这种情况，因为它可能会使之后的开发人员很难区分哪个才是真正正确的版本。
例如，笔者曾经历过这样一种情况：被注释的代码片段比没有被注释的版本更有意义。但有时情况却往往相反，因为他或她会认为，被注释掉这个更合乎逻辑的版本是错误的。因此，保留僵尸代码可能是危险的。
文章插图
图源：unsplash
8. 正确实现模块化：将业务逻辑与实用程序函数分离
将实用函数和业务逻辑混合在一起具有一定意义，但是将它们分开仍然有用。如果使用得当，公共功能可以被推到不同的包中，并在以后跨多项目重用。这种分离需要更多的前期工作（例如，为这样的包构建一个发布过程) ，但是从长远来看，可重用性和只定义一个功能的好处是值得的。
9. 简化代码
Python的宗旨是“简单比复杂好。 ”
许多数据工程师，特别是那些有计算机科学背景的工程师，可以创建复杂的解决方案，却过于繁复无法不够简单明了。例如，如果某些东西可以表示为一个简单的函数，该函数接受一些数据作为输入，并返回转换后的版本作为输出，那么为这种操作编写自定义类对象可能被认为是一种设计过度的解决方案。
10.放远眼光
有时候我们需要在正确和快速之间做出权衡。创建通用型解决方案，以跨不同用例重用，从长期来看，这将使代码编写工作更为容易，开发更长。
例如，为跨项目共享的模块建立一个发布过程和CI/CD管道可能会在前期花费大量时间，但是这种额外的努力通常会在后期得到回报。花时间创建持续验证和监控数据质量的脚本同样如此。
文章插图
图源：unsplash
本文讨论了数据工程中确保数据的高质量和代码的可维护性的最佳方法。大多数数据工程任务可以表示为函数，这些函数接受输入数据并根据特定的任务需求对其进行转换。理想情况下，这些函数应该被设计为专用型，并进行文档记录，以便任何读代码的人都知道函数的输入项和输出项是什么。希望这篇文章能对你有帮助。
文章插图
留言点赞关注
我们一起分享AI学习与发展的干货
如转载，请后台留言，遵守转载规范