作者：Norm Niemer
編譯：ronghuaiyang
無論是初學者還是有經驗的工程師，都會或多或少的犯一些錯誤，這裡總結了一些常犯的錯誤top10，大家可以參考一下。
數據科學家是「比任何軟體工程師都更擅長統計，比任何統計學家都更擅長軟體工程的人」。許多數據科學家具有統計學背景，對軟體工程幾乎沒有經驗。我是一名高級數據科學家，在Stackoverflow的python編程上排名前1%，與許多(初級)數據科學家一起工作。以下是我經常看到的10個常見錯誤。
1. 不要引用共享代碼中的數據
數據科學需要代碼和數據。因此，為了讓其他人能夠複製你的結果，他們需要訪問數據。看起來很簡單，但是很多人忘記了與他們的代碼共享數據。
解決方案：使用d6tpipe與你的代碼共享數據文件，或者上傳到S3/web/谷歌驅動器等，或者保存到資料庫中，以便接收方檢索文件(但不要將它們添加到git中，請參閱下面的內容)。
2. 硬編碼的無效路徑
與錯誤1類似，如果你硬編碼了其他人無法訪問的路徑，他們將無法運行你的代碼，並且必須在許多地方手動更改路徑。
解決方案：使用相對路徑、全局路徑配置變量或d6tpipe使數據易於訪問。
3. 代碼和數據混在一起
既然數據科學代碼需要數據，為什麼不把它轉儲到同一個目錄中呢？當你在做的時候，也要保存圖片、報告和其他垃圾。哎呀，真亂！
解決方案：將目錄組織成數據、報告、代碼等類別。參見Cookiecutter Data Science或d6tflow project templates，並使用1中提到的工具來存儲和共享數據。
4. 把數據和原始碼一起提交到Git上
大多數人對代碼進行版本管理。為了共享數據，可能很容易將數據文件添加到版本控制中。對於非常小的文件，這是可以的，但是git沒有針對數據進行優化，尤其是大型文件。
git add data.csv
解決方案：使用1中提到的工具來存儲和共享數據。如果你真的想對數據進行版本控制，請參見d6tpipe、DVC和Git大文件存儲。
5. 寫方程而不是DAGs
關於數據的討論已經夠多了，讓我們來談談實際的代碼吧！由於在學習編寫代碼時首先要學習的是函數，所以數據科學代碼主要是由一系列線性運行的函數組成的。這會導致一些問題，請參見機器學習代碼可能不好的4個原因。
解決方案：與其使用線性連結的函數，不如將數據科學代碼編寫為一組任務，並在這些任務之間建立依賴關係。使用d6tflow或airflow。
6. 用for循環
像函數一樣，for循環是你學習編碼時要學習的第一件事。容易理解，但是它們很慢，而且過於冗長，通常表示你不知道向量化的替代方案。
解決方案：Numpy、scipy和panda為你認為可能需要循環的大部分內容提供了向量化的函數。
7. 不寫單元測試
當數據、參數或用戶輸入發生變化時，你的代碼可能會中斷，有時你不會注意到。這可能導致錯誤的輸出，如果有人根據你的輸出做出決策，錯誤的數據將導致錯誤的決策！
解決方案：使用 assert語句檢查數據質量。pandas有平等性測試，d6tstack可以檢查數據輸入，d6tjoin可以進行數據連接。數據檢查的代碼示例：
8. 不寫注釋
我很理解，你急著做分析。你把事情拼湊起來，讓你的客戶或老闆知道結果。一周後，他們回來說「你能修改xyz嗎」或者「你能更新一下嗎」。你看著你的代碼，卻不記得你為什麼這麼做。現在想像一下，如果有其他人來運行它。
解決方案：額外花點時間，即使是在你交付分析之後，也要記錄你所做的事情。你會感謝自己，別人也會更加感謝你！你會看起來很專業的！
9. 把數據存為csv或者pickle
再回來說數據，畢竟是數據科學。就像函數和for循環一樣，csv和pickle文件也經常使用，但它們實際上並不好。csv不包含模式，所以每個人都必須重新解析數字和日期。pickle可以解決這個問題，但只能在python中工作，不能壓縮。這兩種格式都不適合存儲大型數據集。
解決方案：使用parquet或其他帶有數據模式的二進位數據格式，最好是壓縮數據的格式。d6tflow會自動任務的數據輸出保存為parquet格式，這樣你就不必處理它了。
10. 使用jupyter notebooks
讓我們以一個有爭議的結論來結束：jupyter notebooks和csv一樣普遍。很多人使用它們。這並不能讓他們變得更好。jupyter notebooks助長了上面提到的許多不良軟體工程習慣，特別是：
使用jupyter notebooks開始做起來很容易，但是擴展規模很困難。
英文原文：https://www.kdnuggets.com/2019/04/top-10-coding-mistakes-data-scientists.html
請長按或掃描二維碼關注本公眾號