資料科學專案管理中的“黃金標準”
公眾號/大資料文摘
大資料文摘出品
編譯：茶西、陳同學、Aileen
如何建立一個數據科學專案管理？建立的標準又是什麼？
我想大多數人至少承認這一點：“你的研究需要讓其他人能夠輕鬆地理解你在專案中做了什麼，並能複製這些結果”。
此外，你還得對檔案的命名方式多加註意，具體做法如何，我們一起來看看吧。
研究結果的可複製性和分享性
首先，你所做的專案必須具有非常強的可複製性以及可分享性，因為只有這樣才能讓你的同行檢驗專案的成果。
例如，杜克大學的研究人員曾經發表了一項關於將個人基因資訊用於患者化療的研究。來自MD Anderson癌症研究中心的兩位研究人員Baggary和Coombs想要對研究進行復現。但是復現之前必須獲取資料和程式碼是必須的。
經過數月的時間，終於，這兩位認真的研究人員拿到了想要的資料和程式碼。雖然，拿到的時候這些資料還是未經整理、雜亂無章的。
又經過很長時間的實驗驗證，這兩位研究人員發現已發表的研究中的程式碼出現了一個錯誤，這個錯誤嚴重到研究的成果會將患者置於危險境地。
所以，幾個月份來，兩位研究者一直在對一項錯誤的研究進行復現，更重要的是，他們大多數的時間花費到了“無意義”的資料收集與整理上。
這就是弱分享性以及弱複製性帶來的危害，驗證實驗結果可能花費不了多少成本。但是由於研究作者對資料的保護，使得你需要用更長的時間收集相關資料。
那麼，為什麼研究者大多不願意分享研究資料呢？
當你聯絡一個研究員想要獲得他的研究的原始碼和初始資料時，你需要解釋你是誰，你為誰工作，為什麼需要這些資料，以及你要如何處置這些資料。
另外，你還經常收到如下回復：
我不得不說如果沒有解釋的話，這就是一個不太正常的要求。請讓你的導師發一封詳細的，我再強調一遍，詳細的郵件給我來解釋一下。
這些資料檔案是我們的資產，並且不是免費使用的，所以請告訴我們你想要用這些檔案來做什麼，然後我們看看可以如何幫到你。
我們通常不會將我們的內部資料分享給非合作單位。
這些程式碼是我和同事多年努力的結晶，這些資料也是我與合作者們千辛萬苦花了很長時間收集到的，所以也需要得到他們的允可。
通常我們不會提供這類資料給不認識的人。可能你想要查驗資料分析，這可能對於我們也有用，但是在你發表你的研究時請恰當地提到我們。.
感謝你對我們的文章感興趣。在計算中我用的是我們自己的程式碼，目前還沒有公共版本可供下載。鑑於目前的程式碼不是很易用，而且還在持續改進中，所以我傾向於暫不分享。
很抱歉我們的程式碼在建立時並沒有想過給他人使用。程式碼現在並未文件化，我們也沒有時間和資源來文件化。如果你有一個特別的計算要做，且不是我們現在做的東西的主要延伸的話，我們可以幫你跑這個程式碼。
R是一個免費的軟體，你可以在www.r-project.org/找到。我用R是因為XX模型。你可能有所瞭解XX和XX十分複雜。但是我可能不必說這些你已經是個統計學學生了。我都是用Matlab來處理幾何的問題。
所以，建議你在閱讀研究成果時，先看是否有一份附有所有的原始資料和程式碼的可重複性宣告。如果沒有看到一份這樣的東西，你可以暫時忽略這個研究。
可重複使用說明範例
不能讓你的專案具有可複製性是學術上的不端行為，可能會產生嚴重的後果。例如“未能妥善記錄和儲存研究成果”是近日康奈爾大學研究員Brian Wansink的受到的不光彩的指控之一 。
在Daniele Procida關於軟體文件的黃金標準上，他很好地總結了這一點：
“不管你的軟體有多好，如果說明文件不夠好，人們就不會使用它。即使出於某種原因，人們沒有選擇而不得不使用它，沒有好的說明文件的話，大家也不能有效地使用它，更不會按照你希望的方式使用它。”
因此，遵循Procida先生的明智建議，你的研究需要讓其他人能夠輕鬆地理解你在專案中做了什麼，並能複製這些結果。這對於現在和同事的合作至關重要，也對後人有很大幫助(例如，未來某一天你要重新執行一個六個月沒碰過的分析的時候，或者任何其他研究員想要重新看一看你的工作的時候)。Leek認為 “花費資料科學專案中10-20%的時間來對你的工作進行組織與文件化”是非常重要的。
檔案命名
檔案的命名的方式在資料科學專案中也是非常重要的。
一位對R語言指令碼設計、工作流程和檔案組織與命名方面頗有見地的資料科學家Jenny Bryan認為有三個原則是必須遵守的：
- 機器可讀
- 人類可讀
- 很好地處理預設排序
為了機器的可讀性，我們希望避免空格、標點符號、句號和任何其他特殊字元(除了“_”和“-”)。
針對人類的可讀性，需要您給檔案賦予有意義的名稱。當命名R物件時，如果包含了註釋的話，縮寫物件名稱的也是可以的。例如，cv_perf_Recoke_rf是對隨機森林模型的每個交叉驗證的驗證召回的計算。
但是在命名檔案時，我建議除非絕對必要，不要使用縮寫詞；如果使用了的話，請在自述檔案中列明這些資訊。
另外一個建議是將日期和數字放在檔名的開頭。始終使用ISO 8601的日期格式(yyyy-mm-dd)和左起帶0的數字。數字的最大位數取決於一共要生成多少個檔案。假設你想要儲存100個建築MRI影象檔案，那麼它應該看起來如此001_t1_mri.nii.gz。假設你認為你實際上會生成1000個檔案，它看起來應該如此0025_t1_mri.nii.gz。
Leek還指出，應該避免大小寫的敏感性，例如Esophageal-Cancer_Report.md（食道癌報告.md）顯然是一個可怕的檔名(輸入這串包含大小寫的字母和字元真是累死了)。
你也可以用esophagealCancer_report.md，因為它更能看起來更令人愉快，也並未有Leek提到的風險；只要不要忘記在linux中使用find指令時用-iname標誌來忽略大小寫就好。如果你健忘，或者只是效率很高(也就是懶)，你總是可以把它包含在.bashrc檔案中作為別名。
讓檔名以大寫字母開頭顯然是個壞主意，因為它會導致你需要額外的按鍵來生成大寫字母(例如Shift)。然而，使用camelCase方式，您可以通過使用選項卡來自動完成以避免額外的按鍵。
OMT
如果你使用R，你應該讀一讀Jenny Bryan的here()包，它消除了setwd()可能導致的麻煩的工作流程問題。
另外，建議大家去閱讀她的部落格文章“面向專案的工作流程”它清楚明白的告訴我們更多關於“怎樣做”以及“為什麼這樣做”的資訊。
面向專案的工作流程
https://www.tidyverse.org/articles/2017/12/workflow-vs-script/
遵循這個資料科學專案管理黃金標準的建議，在處理“大資料”時你將得心應手許多。