如何成為一名頂級戰(zhàn)斗力的數(shù)據(jù)分析師

不知道大家以前聽沒聽說過“10x Developer”這個詞，如果你連聽都還沒聽說過，那可真是時候考慮放棄自己的程序猿事業(yè)了。就像傳說一樣，一些程序猿的戰(zhàn)斗力能達到同行的10倍，也就是說一個10x程序猿能夠替換一個10人的開發(fā)團隊。

本篇文章我們就針對數(shù)據(jù)科學，來談一談如何才能成為一名傳說中的10x老司機。本文作者主要從事數(shù)據(jù)挖掘及處理方面的開發(fā)工作，是西雅圖女性程序員俱樂部PyLadies創(chuàng)始人，曾在PyData Seattle 2015上做過關于通過自然語言處理和機器學習調查用戶體驗的主題演講。

以下正文

最近我在PyData Seattle(https://pydata.org/seattle2017/)發(fā)表了一個關于如何通過借鑒開發(fā)社區(qū)的提示和竅門來提高數(shù)據(jù)科學技能的主題演講。這些建議將幫助開發(fā)者成為一名非常受團隊成員和其他人歡迎的數(shù)據(jù)科學方面的老司機。

這篇文章分為五部分，其中包括：

10x開發(fā)者的歷史和爭議

項目設計

代碼設計

工作工具

生產(chǎn)模式

當然，如果你想觀看原始演講的視頻，可以點擊這里

10x開發(fā)人員，顧名思義，就是比普通開發(fā)人員生產(chǎn)力高出10倍的人。

一個10x的開發(fā)人員，不只是能在一定時間內(nèi)比普通開發(fā)人員生產(chǎn)更多代碼，還能像boss一樣調試bug，代碼里的bug也更少。因為他們會測試代碼，指導初級開發(fā)人員，編寫自己的文檔，并且擁有很多其他技能來讓自己超越僅僅知道如何寫代碼的境界。

H. Sackman，W. J. Erikson和E. E. Grant在1968年進行了一個叫做“比較在線和離線編程性能的探索性實驗研究”的實驗，發(fā)現(xiàn)程序員在完成寫代碼的任務上有很大的時間差異。

雖然該實驗選取的被研究人員平均開發(fā)經(jīng)驗已經(jīng)達到了七年之久，但相互之間的時間差異卻能達到驚人的20倍。

雖然該實驗的設計存在一定的缺陷，例如將使用低級語言的程序員和使用高級語言的程序員混合到了一起，但之后越來越多的研究都發(fā)現(xiàn)了類似的結果。

雖然關于到底存不存在10x開發(fā)人員仍有著廣泛的爭論，但本文重點關注的不是這些，而是關注開發(fā)人員，如何通過從那些經(jīng)驗豐富并且被認為開發(fā)速度更快的人那里得到的提示和竅門，成為一名更有生產(chǎn)效率的數(shù)據(jù)科學家。

你得真正了解業(yè)務

不管你是為教育、生物技術還是金融公司工作，都應該至少對解決問題的業(yè)務有一個比較深入的了解。

為了有效地溝通數(shù)據(jù)分析背后的故事，你應該了解是什么在驅動業(yè)務，并且了解業(yè)務目標。

例如，如果你負責優(yōu)化食品卡車的位置，那么你就需要了解客流量，競爭，該地區(qū)發(fā)生的事件，甚至天氣。你需要想了解公司為什么要優(yōu)化位置?？赡苁且驗楣疽黾蝇F(xiàn)有卡車的銷售量，或者是想要增加卡車數(shù)量。

哪怕你可能是今天在搜索網(wǎng)站工作，明天就到了金融公司去當數(shù)據(jù)科學家，你也應該為了使你的分析與利益相關者相關知道是什么讓業(yè)務成為可能。

你還應該了解你所在項目的業(yè)務流程，例如知道誰需要簽署最終結果，一旦你負責的部分完成，數(shù)據(jù)模型被傳遞給誰，以及預期的時間表是如何安排的。

最后，你應該確保你知道這個項目的利益相關者是誰，并且能夠向不懂技術的利益相關者講明白這個項目實際的效果。就像是成為教育工作者一樣，并能夠向不懂技術的利益相關者講明白為什么達成目標可能需要比他們預期的更多時間或資源。

當你了解了利益相關方的目標，并能夠確保你溝通技術，專業(yè)知識和建立解決方案所需的時間，那么你在你們公司的價值一定會變得更大。

你得真正了解數(shù)據(jù)

了解業(yè)務很重要，了解數(shù)據(jù)更重要。你需要知道數(shù)據(jù)該怎樣提取，何時提取，誰負責質量控制，為什么數(shù)據(jù)會可能存在差距(例如供應商的變化或提取方法的變化)，什么可能會丟失，并且哪些其他數(shù)據(jù)源可以被添加進來以創(chuàng)建一個更準確的模型。

這真的需要你去和不同的團隊交談，并且不斷地提出問題。不要害怕問他們正在做哪些工作，也不要害怕跟他們討論你正在做哪些工作，因為你永遠不知道大家是不是在做重復的工作，或者他們是否有一個更干凈的版本的數(shù)據(jù)，而這恰恰是你需要數(shù)據(jù)。這樣可以節(jié)省你大量查詢數(shù)據(jù)庫的時間，例如對SiteCatalyst進行多個API調用。

為什么在項目設計過程中多花費一些時間和精力可以讓你成為10x數(shù)據(jù)科學家?

你只需要做那些需要完成的工作(在寫代碼之前已經(jīng)思考過)，這樣就可以快速完成項目，因為你會減少工作量!

通過在客戶/用戶認為他們需要的東西和他們真正需要的東西之間發(fā)現(xiàn)不同，你就能把自己定位成這個領域的專家和共識的制定者。

你會鞏固自己對問題的理解，從而減小犯那些重大錯誤的幾率。

你得懂得代碼設計

雖然在設計代碼時有很多非常好的實踐，但其中有一些非常突出的細節(jié)將大大增加你的生產(chǎn)效率。

我第一次聽到關于清晰度或清晰度勝過聰明才智的論述是在大學寫作課。 被自己一時的聰明想法抓住，并使用今天剛想到的最新詞匯來表述想法是很容易的一件事，但是像編程一樣，你這樣做不僅可能會混淆自己，還會混淆別人。(小編注：比如不按變量命名規(guī)則，每次都是a，b，c。。。真的在日后看代碼的時候很崩潰)

在上面的Scala示例中，第一行顯示了使用簡寫語法的sortBy方法。雖然簡明扼要，但很難想象下劃線代表什么。雖然這是許多人在匿名函數(shù)中表示參數(shù)名稱的常見模式，但對于不太高級的開發(fā)人員(或者當你過了一段時間再看你的代碼)時，搞明白代碼到底代表什么的做法就變得很頭痛了。

在第二個例子中，我們起碼使用了一個參數(shù)名稱，加上它還顯示了賦值，我們可以看到它是通過序列x中的最后一個元素排序的。

當代碼不怎么抽象的時候，之后的調試才會更容易，所以在第三個例子中，我明確命名了我的參數(shù)，以便它表示數(shù)據(jù)。

當你的大腦必須要經(jīng)歷每一步，或者查找或回想代碼的簡寫代表什么的時候，調試會需要更長的時間，添加新函數(shù)也會需要更長的時間，因此即使使用上述示例的簡寫可以簡潔而快速地輸入，從長遠來看，明確命名參數(shù)對你和他人都會是有利的，從而避免你們耍小聰明犯下的錯。

雖然我們不會檢查緩存，但我們將介紹命名的重要性。想象一下，你正在查看一些舊的代碼，你會看到序列按Scala示例進行排序：

sortBy(x => -x._2) 

使用單個字母來命名序列根本提供不了有用的信息，因為當你可能從API，數(shù)據(jù)庫或Spark中的數(shù)據(jù)流中提取數(shù)據(jù)時，你必須運行代碼才能看到”x”到底代表什么。

所以保持與之前Scala的示例的代碼應該是：

sortBy(clothesCount => -clothesCount._2) 

這樣你就可以知道我們正在對什么進行排序，甚至不用運行代碼。

但是，有時使用X作為變量名稱卻很好。例如，X通常用于機器學習庫，其中X表示觀察到的數(shù)據(jù)，而y是試圖預測的變量。在這種情況下，使用這個領域約定俗成的表示，如“模型”，“擬合”，“預測”和“x”和“y”等字段是最好不過的。

除了數(shù)據(jù)科學方面的要求，你還要遵循你所使用的語言的編程語言慣例。例如，我建議你去檢查一下文檔，如PEP for Python，來了解最佳做法。

通過規(guī)范你的命名約定，并通過清晰而不是耍小聰明的代碼，它將使重構和調試更容易和更快。按照這兩個代碼設計的竅門，你將走上成為10x數(shù)據(jù)科學家的道路。

保持代碼樣式一致，與剛剛我們說的保持命名約定一樣重要。要獲得一些基本的風格點，你應該堅持一種情況，不要在同一個腳本中混合使用駝峰式大小寫和snake的命名規(guī)范，否則的話，你的代碼很快就會變得難以閱讀和瀏覽。另一種你應該保持一致的方法是同一種任務要堅持使用相同方法。

例如，要從字典中刪除重復項，并且需要在代碼的好幾個位置處執(zhí)行此操作，那么就不要僅僅因為在Stack Overflow網(wǎng)站上看到過就使用其他創(chuàng)造性的方法來執(zhí)行操作。使用最清晰和最不聰明的方法來讓你的代碼和腳本保持一致。并且，我還要再次強調，一致性的目的是為了避免讓你自己和其他人混淆，這將有助于你更快地進行調試!(請注意，我們這段話的核心是調試)。

還記住我們剛剛談到的，必須在代碼中的多個地方刪除字典中的重復項嗎?使用函數(shù)，你就不需要多次重寫代碼。當然，即使你不重用代碼，把代碼封裝在函數(shù)中也是至關重要的最佳做法。你的函數(shù)應該很小，小到只能做一件事情，以便可以重復調用。

當你不使用函數(shù)時，經(jīng)常會有有全局變量導致命名沖突，代碼不可測試和代碼的不斷重復。

通過使用函數(shù)，你的代碼就可以自由組合，更易于編寫測試單元。

但是不要僅僅止步于寫一些只做一件事情的小函數(shù)，請務必抽象你的函數(shù)，以便重新使用它們 - 這樣有助于降低代碼冗余度，并能加快你的開發(fā)時間，這樣做下去至少讓你成為一個2x 程序猿。

盡管不太常見，但代碼設計中很重要的一點是使用樁代碼。樁代碼是簡單的mock類以及函數(shù)，可以顯示輸入，輸出和注釋，并為代碼提供一個大綱。在你開始實際編寫代碼之前，使用樁代碼會讓你先考慮代碼，并可以幫助你避免怪異的意大利面條式的代碼。你會注意到你在編寫代碼之前有哪些重復的代碼，并且會考慮最合適的數(shù)據(jù)結構。

上面的代碼示例給我們展示了注釋和文檔。要真正成為一個被同事喜歡的程序猿，并提高自己作為一名數(shù)據(jù)科學家的效率，就要會寫有用的簡明扼要的注釋。這不僅應該包括關于代碼段的注釋，還包括其輸入和輸出。

此外，關于docstrings可能最酷的是，它們可以通過大多數(shù)語言的庫轉換為文檔。例如Python有一個名為Sphinx的庫，可以讓你將docstrings轉換成完整的文檔。

你現(xiàn)在可能知道你的代碼是什么，但當你嘗試調試或添加函數(shù)時，你和其他人將非常開心有注釋。

無論你使用什么語言編寫代碼，請記得使用異常處理，并為你自己，同事和最終用戶留下有用的錯誤信息。上面的代碼顯示了一個停止函數(shù)，能夠傳遞來自正在調用的API的錯誤消息。

如果數(shù)據(jù)不是API需要的，那么它就會引發(fā)一個有用的錯誤消息。在你自己的代碼中，你可以在停止函數(shù)中寫一個消息，幫助用戶：

stop(paste0(“Make sure all your inputs are strings: ”, e)) 

以上示例來自“Hitchhikers Guide to Python”，它使用Python測試庫Pytest。

盡管編寫測試單元對于開發(fā)人員來說相當普遍，但這在數(shù)據(jù)科學領域卻很少使用。當然，你可以使用交叉驗證，混淆矩陣和其他方法來驗證你的模型。 但是，你是否測試了正在為你獲取數(shù)據(jù)的查詢? 你使用的各種方法是如何清理和轉換數(shù)據(jù)的，你的模型需要它們嗎? 這些方面對于安全防范“Garbage in, garbage out”(小編注：這兩個單詞的意思是，如果將錯誤的、無意義的數(shù)據(jù)輸入計算機系統(tǒng)，計算機自然也一定會輸出錯誤、無意義的結果。)至關重要。 當你測試代碼時，不僅這兩個未來的證據(jù)可以反映可能引入錯誤的變化，而且當你有能力自己給自己檢查代碼時，每個人都會認為你就像一個搖滾明星一樣耀眼，因為一旦代碼被用于實際生產(chǎn)就會發(fā)現(xiàn)bug非常少。

為你的項目使用版本控制是成為10x數(shù)據(jù)科學家的重要一步。這最明顯的好處是保存模型的不同版本，既可以輕松地進行團隊工作，也可以通過在存儲庫中使用版本控制進行備份，防止在筆記本電腦被盜或硬盤驅動器墜毀的情況下丟失工作。

在beta版中，有一個名為Data Version Control的開源數(shù)據(jù)版本控制項目，對于數(shù)據(jù)科學工作流程來說看著很有希望。 它依靠Git，并允許通過構建數(shù)據(jù)依賴圖來跨團隊重現(xiàn)項目。你的數(shù)據(jù)會與你的模型分開保存，它與其他版本控件一樣工作，允許你回滾到以前保存的備份。

10x開發(fā)人員知道使用正確的工具來完成工作，無論是使用庫來節(jié)省時間，切換語言以實現(xiàn)性能，還是使用API，而不是自己從頭構建解決方案。

比方說你現(xiàn)在有一些Twitter或其他社交數(shù)據(jù)要用來進行情緒分析。一個選擇是自己標注數(shù)據(jù)，訓練自己的模型，另一個則是使用預先訓練的模型。不去自己建立每個數(shù)據(jù)模型來重新造輪子是很薄的。使用最適合工作的工具，即使這意味著使用你沒有構建過的工具。

我們都寫過一個與Cron工作配對的Bash腳本來自動化一些報告，但是，在你花費一些時間嘗試調試由Cron自動執(zhí)行的其他人撰寫的報告時，你甚至不知道它在哪里運行，你會意識到必須有更好的方法才行。通過使用自動化工具，如Puppet，Chef，Ansible或任何其他流行的自動化工具，你就可以從集中的位置運行你的工作，因此調試他人(或你自己)的工作就能快很多。

有時你可能找不到一個團隊來負責你設計的模型，這個時候就需要知道如何自己部署自己的模型。

雖然上面那副圖中的提供商之間有很多差異，但它們包含了從難以置信的易用性到你需要的更多的設置和知識。本節(jié)的內(nèi)容其實可以單獨成為一個話題。如果你想了解有關模型托管的更多細節(jié)，可以查看我們的其他幾個不同的報告，分別介紹部署模型(https://blog.algorithmia.com/building-intelligent-applications/ )以及部署和擴展你的深度學習模型(https://blog.algorithmia.com/deploying-deep-learning-cloud-services/)。

可能是致命傷的事情：

易用性

成本(包括附加組件和隱藏成本，如托管數(shù)據(jù))

投標人鎖定

語言可用性

通過了解如何部署模型，你才有能力通過數(shù)據(jù)來講述故事，輕松地與團隊成員共享(不管使用哪種語言)或將其部署到生產(chǎn)環(huán)境中，從而與數(shù)千用戶共享。這將幫助你成為10x-er，因為一旦了解了這一點，你就可以創(chuàng)建更多性能更高的模型，使用戶開心。當用戶開心時，企業(yè)主就會開心。

成為10x數(shù)據(jù)科學家的技巧

為了讓這篇文章圓滿，這里有一些關于如何成為10x數(shù)據(jù)科學家的最受歡迎的技巧：

模式匹配。這來自于以前遇到類似問題并意識到可以重用或修改當前問題解決方案的經(jīng)驗。

了解如何解釋你的代碼 - 給自己和其他人。 這意味著你可以在白板上，做/得到代碼甚至協(xié)同編程。要習慣于談論你的代碼和思考過程。

了解如何/何時退出并重新開始。如果你意識到有一個更好的方法來解決問題，那就不要害怕重新開始。最好就是重新開始，做一個更好的方法來完成，而不是放出一些不是最佳或高性能的東西。

創(chuàng)建你自己的Gists庫，或通過GitHub或其他托管服務的存儲庫組織代碼片段。

最后，回顧整篇帖子，如何成為一個10x的數(shù)據(jù)科學家和如何調試其實是相同的主題。每個10x的開發(fā)人員都可以想象成一個主調試器，因為這個規(guī)則就是無論你的代碼多長，你都可以將它乘以10，并得到你需要調試的時間。 成為一個很好的調試器的一個竅門就是使用異常處理，你可以在IDE中使用調試器，你可以通過代碼查找邏輯中的錯誤，并檢查涉及錯誤的庫的源代碼，以確保你正在傳遞代碼需要的內(nèi)容。

即使你從這個帖子只得到了幾點收獲，恭喜你，你已走上了成為10x數(shù)據(jù)科學家的道路。

當然，能不能抵達道路的盡頭，就看你自己咯。