本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。

數據工程是本世紀發展最快的行業之一。工作以來，筆者在各個公司見識了許多確保數據和代碼質量的方法。每個公司可能遵循不同的流程和標準，但是有一些通用的原則可用于提高開發速度，改進代碼維護，降低數據工作難度。

[[350241]]

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. 設計專用型函數

要使函數可重用，編寫專用型函數是一種很好的實踐。可以設計主要功能，并把不同的部分連接在一起。總的來說，筆者發現通過使函數縮小應用范圍(即專門用于某項任務)，可以更快地開發代碼，因為識別和修復單個元素的錯誤更為容易。

功能范圍更小也使得交換單個組件變得更容易，可以將它們像樂高積木一樣針對不同的用例組合在一起。

3. 正確的命名規則至關重要

將對象進行命名，這樣其他人查看代碼時就可以立即理解你的意圖，這種做法非常不錯。但有些縮寫可能不是每個人都能理解，所以最好避免使用，而是選擇寫出全名。我見過的大多數數據工程師傾向于使用以下協議：

• 使用動詞作為函數名，ex. get_dataframe_from_google_ads()可能比google_ads()更容易理解——較長的版本不僅能顯示源系統，還可指出函數執行的操作和它返回的對象類型(數據框架)。它看起來很冗長，但通常只需要編寫兩次：一次是在定義時編寫，一次是在調用時編寫。因此，筆者認為編寫那些較長的函數名是值得的。
• 大寫全局變量——與筆者工作過的大多數數據工程師都將全局變量定義為大寫，以區別于局部變量(例如主函數中的變量)。
• 許多人認為最好只在腳本的頂部定義導入——理論上，可以在函數或類中導入庫，但是如果所有的導入都在腳本的頂部，那么跟蹤包依賴關系可能會更容易。

理想情況下，命名可以使代碼自我記錄，這也可以實現高效編程。

4. 簡潔而高質量的代碼更便于維護

通常，程序員讀代碼要比寫代碼更頻繁。因此，使代碼易于閱讀和理解是非常重要的。

通過進行恰當的命名和建立良好的結構，我們可以便利個人未來的工作，其他人在使用我們代碼時也會更容易。代碼簡潔好處多多：編寫的代碼越少，需要維護的代碼就越少。如果可以用更少的代碼完成任務，這也是一種潛在的勝利。

5. 文檔是關鍵，但前提是要做得正確

這聽起來可能違反直覺，但是我們不應該記錄代碼在做什么;相反，我們應該記錄為什么代碼要做它正在做的事情，很多代碼注釋老在說明一些顯而易見的事情。

例如，get_dataframe_from_google_ads()函數不必說明我們正在從谷歌廣告下載數據，而應說明這樣做的原因，例如“下載廣告支出數據以供稍后的營銷成本歸因”。使用docstring或類型注釋來記錄函數的預期輸入和輸出非常有幫助，它能立馬讓你搖身一變成為更好的數據工程師。

6. 避免硬編碼值

許多與ETL相關的SQL查詢使用閾值但沒有解釋原因。例如，假設有一個腳本從某個表中提取數據，但只針對發生在2020年9月30日之后的事件，而且絕對沒有文件證明為什么有人選擇了這個特定的日期。

在不解釋原因的情況下，人們要如何才能發現為什么這個值是硬編碼的?這可能是因為，在那天，公司轉向了一個新的源系統，新的數據提供商，或者他們可能改變了一些商業策略。筆者并非指在代碼中這種業務邏輯是錯誤的，但如果不記錄為什么有人選擇了這樣一個任意的閾值，這個硬編碼的值在未來幾年里可能會一直是下一代數據工程師的一個謎。

7. 避免保留僵尸代碼

筆者經常遇到的一種常見的反模式是，有人保留了已棄用但遺留在腳本注釋中的代碼。也許有人想測試一些新的行為，保留舊版本以防新版本不能運行，或者這個人想要保存歷史記錄。筆者認為最好避免這種情況，因為它可能會使之后的開發人員很難區分哪個才是真正正確的版本。

例如，筆者曾經歷過這樣一種情況：被注釋的代碼片段比沒有被注釋的版本更有意義。但有時情況卻往往相反，因為他或她會認為，被注釋掉這個更合乎邏輯的版本是錯誤的。因此，保留僵尸代碼可能是危險的。

8. 正確實現模塊化：將業務邏輯與實用程序函數分離

將實用函數和業務邏輯混合在一起具有一定意義，但是將它們分開仍然有用。如果使用得當，公共功能可以被推到不同的包中，并在以后跨多項目重用。這種分離需要更多的前期工作(例如，為這樣的包構建一個發布過程)，但是從長遠來看，可重用性和只定義一個功能的好處是值得的。

9. 簡化代碼

Python的宗旨是“簡單比復雜好。”

許多數據工程師，特別是那些有計算機科學背景的工程師，可以創建復雜的解決方案，卻過于繁復無法不夠簡單明了。例如，如果某些東西可以表示為一個簡單的函數，該函數接受一些數據作為輸入，并返回轉換后的版本作為輸出，那么為這種操作編寫自定義類對象可能被認為是一種設計過度的解決方案。

10. 放遠眼光

有時候我們需要在正確和快速之間做出權衡。創建通用型解決方案，以跨不同用例重用，從長期來看，這將使代碼編寫工作更為容易，開發更長。

例如，為跨項目共享的模塊建立一個發布過程和CI/CD管道可能會在前期花費大量時間，但是這種額外的努力通常會在后期得到回報。花時間創建持續驗證和監控數據質量的腳本同樣如此。

[[350242]]

圖源：unsplash

本文討論了數據工程中確保數據的高質量和代碼的可維護性的最佳方法。大多數數據工程任務可以表示為函數，這些函數接受輸入數據并根據特定的任務需求對其進行轉換。理想情況下，這些函數應該被設計為專用型，并進行文檔記錄，以便任何讀代碼的人都知道函數的輸入項和輸出項是什么。希望這篇文章能對你有幫助。