數據科學家比軟件工程師擅長統計，又比統計學家擅長軟件工程。聽起來牛逼轟轟，事實卻是，許多數據科學家有統計學背景，卻沒有什么軟件工程方面的經驗，因此在編碼時容易犯一些簡單的錯誤。作為一名高級數據科學家，本文作者總結了他在工作中常見數據科學家犯的十大錯誤。

我是一名高級數據科學家，在 Stackoverflow 的 python 編碼中排前 1%，而且還與眾多(初級)數據科學家一起工作。下文列出了我常見到的 10 個錯誤。

1. 沒有共享代碼中引用的數據

數據科學需要代碼和數據。所以為了讓其他人能夠復現自己做出來的結果，你需要提供代碼中涉及的數據。這看起來很簡單，但許多人會忘記共享代碼中需要的數據。

import pandas as pd 
df1 = pd.read_csv('file-i-dont-have.csv') # fails 
do_stuff(df) 

解決方案：用 d6tpipe 共享代碼中的數據文件，或者將數據文件上傳到 S3/網頁/Google 云等，還可以將數據文件保存到數據庫中，以便收件人檢索文件(但不要將數據添加到 git 中，這一點后面的內容會講到)。

2. 硬編碼其他人無法訪問的路徑

和錯誤 1 類似，如果硬編碼其他人無法訪問的路徑，他們就沒法運行你的代碼，而且在很多地方都必須要手動修改路徑。Booo!

import pandas as pd 
df = pd.read_csv('/path/i-dont/have/data.csv') # fails 
do_stuff(df) 
# or  
impor os 
os.chdir('c:\\Users\\yourname\\desktop\\python') # fails 

解決方案：使用相對路徑、全局路徑配置變量或 d6tpipe，這樣其他人就可以輕易訪問你的數據了。

3. 將數據和代碼混在一起

既然數據科學代碼需要數據，為什么不將代碼和數據存儲在同一個目錄中呢?但你運行代碼時，這個目錄中還會存儲圖像、報告以及其他垃圾文件。亂成一團!

├── data.csv 
├── ingest.py 
├── other-data.csv 
├── output.png 
├── report.html 
└── run.py 

解決方案：對目錄進行分類，比如數據、報告、代碼等。參閱 Cookiecutter Data Science 或 d6tflow 項目模板，并用問題 1 中提到的工具存儲以及共享數據。

• Cookiecutter Data Science：https://drivendata.github.io/cookiecutter-data-science/#directory-structure
• d6tflow 項目模板：https://github.com/d6t/d6tflow-template

4. 用 Git 提交數據

大多數人現在都會版本控制他們的代碼(如果你沒有這么做那就是另一個問題了!)。在共享數據時，可能很容易將數據文件添加到版本控制中。對一些小文件來說這沒什么問題。但 git 無法優化數據，尤其是對大型文件而言。

git add data.csv 

解決方案：使用問題 1 中提到的工具來存儲和共享數據。如果你真的需要對數據進行版本控制，請參閱 d6tpipe、DVC 和 Git Large File Storage。

• DVC：https://dvc.org/
• Git Large File Storage：https://git-lfs.github.com/

5. 寫函數而不是 DAG

數據已經討論得夠多了，接下來我們談談實際的代碼。你在學編程時，首先學的就是函數，數據科學代碼主要由一系列線性運行的函數組成。這會引發一些問題，詳情請參閱「4 Reasons Why Your Machine Learning Code is Probably Bad。」

地址：

https://towardsdatascience.com/4-reasons-why-your-machine-learning-code-is-probably-bad-c291752e4953

def process_data(data, parameter): 
    data = do_stuff(data) 
    data.to_pickle('data.pkl') 
data = pd.read_csv('data.csv') 
process_data(data) 
df_train = pd.read_pickle(df_train) 
model = sklearn.svm.SVC() 
model.fit(df_train.iloc[:,:-1], df_train['y']) 

解決方案：與其用線性鏈接函數，不如寫一組有依賴關系的任務。可以用 d6tflow 或者 airflow。

6. 寫 for 循環

和函數一樣，for 循環也是你在學代碼時***學的。這種語句易于理解，但運行很慢且過于冗長，這種情況通常表示你不知道用什么替代向量化。

x = range(10) 
avg = sum(x)/len(x); std = math.sqrt(sum((i-avg)**2 for i in x)/len(x)); 
zscore = [(i-avg)/std for x] 
# should be: scipy.stats.zscore(x) 
# or 
groupavg = [] 
for i in df['g'].unique(): 
    dfdfg = df[df[g']==i] 
    groupavg.append(dfg['g'].mean()) 
# should be: df.groupby('g').mean() 

解決方案：NumPy、SciPy 和 pandas 都有向量化函數，它們可以處理大部分你覺得需要用 for 循環解決的問題。

7. 沒有寫單元測試

隨著數據、參數或者用戶輸入的改變，你的代碼可能會中斷，而你有時候可能沒注意到這一點。這就會導致錯誤的輸出，如果有人根據你的輸出做決策的話，那么錯誤的數據就會導致錯誤的決策!

解決方案：用 assert 語句檢查數據質量。Pandas 也有相同的測試，d6tstack 可以檢查數據的獲取，d6tjoin 可以檢查數據的連接。檢查數據的示例代碼如下：

• d6tstack：https://github.com/d6t/d6tstack
• d6tjoin：https://github.com/d6t/d6tjoin/blob/master/examples-prejoin.ipynb

assert df['id'].unique().shape[0] == len(ids) # have data for all ids? 
assert df.isna().sum()<0.9 # catch missing values 
assert df.groupby(['g','date']).size().max() ==1 # no duplicate values/date? 
assert d6tjoin.utils.PreJoin([df1,df2],['id','date']).is_all_matched() # all ids matched? 

8. 沒有注釋代碼

我明白你急著做分析。于是你把代碼拼湊起來得到結果，把結果交給你的客戶或者老板。一周之后他們找到你，問你「你能改掉 xyz 嗎?」或「你能更新一下結果嗎?」。然后你和自己的代碼大眼瞪小眼，既不記得你為什么要這么做，也不記得你做過什么。現在想象一下其他人運行這段代碼時的心情。

def some_complicated_function(data): 
    datadata = data[data['column']!='wrong'] 
    datadata = data.groupby('date').apply(lambda x: complicated_stuff(x)) 
    datadata = data[data['value']<0.9] 
    return data 

解決方案：即便你已經完成了分析，也要花時間注釋一下你做過什么。你會感謝自己的，當然其他人會更加感謝你!這樣你看起來會更專業!

9. 把數據存成 csv 或 pickle

說回數據，畢竟我們討論的是數據科學。就像函數和 for 循環一樣，CSV 和 pickle 文件也很常用，但它們其實并沒有那么好。CSV 不包含模式(schema)，所以每個人都必須重新解析數字和日期。Pickle 可以解決這一點，但只能用在 Python 中，而且不能壓縮。這兩種格式都不適合存儲大型數據集。

def process_data(data, parameter): 
    data = do_stuff(data) 
    data.to_pickle('data.pkl') 
data = pd.read_csv('data.csv') 
process_data(data) 
df_train = pd.read_pickle(df_train) 

解決方案：用 parquet 或者其他帶有數據模式的二進制數據格式，***還能壓縮數據。d6tflow 可以自動將數據輸出存儲為 parquet，這樣你就不用解決這個問題了。

parquet：https://github.com/dask/fastparquet

10. 使用 Jupyter notebook

這個結論還有一些爭議——Jupyter notebook 就像 CSV 一樣常用。很多人都會用到它們。但這并不能讓它們變得更好。Jupyter notebook 助長了上面提到的許多不好的軟件工程習慣，特別是：

• 你會把所有文件存在一個目錄中;
• 你寫的代碼是自上而下運行的，而不是 DAG;
• 你不會模塊化你的代碼;
• 代碼難以調試;
• 代碼和輸出會混合在一個文件中;
• 不能很好地進行版本控制。

Jupyter notebook 很容易上手，但規模太小。

解決方案：用 pycharm 和/或 spyder。

原文鏈接：

https://medium.com/m/global-identity?redirectUrl=https%3A%2F%2Ftowardsdatascience.com%2Ftop-10-coding-mistakes-made-by-data-scientists-bb5bc82faaee

【本文是51CTO專欄機構“機器之心”的原創譯文，微信公眾號“機器之心( id: almosthuman2014)”】 

戳這里，看該作者更多好文