如何成爲一名頂級戰鬥力的數據分析師？

翻譯 | AI科技大本營（rgznai100）
參與 | reason_W

不知道你們之前聽沒據說過「10x Developer」這個詞，若是你連聽都還沒據說過，那可真是時候考慮放棄本身的程序猿事業了。就像傳說同樣，一些程序猿的戰鬥力能達到同行的10倍，也就是說一個10x程序猿可以替換一個10人的開發團隊。

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

如下正文~~

最近我在PyData Seattle(https://pydata.org/seattle2017/)發表了一個關於如何經過借鑑開發社區的提示和竅門來提升數據科學技能的主題演講。這些建議將幫助開發者成爲一名很是受團隊成員和其餘人歡迎的數據科學方面的老司機。

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

• 10x開發者的歷史和爭議

• 項目設計

• 代碼設計

• 工做工具

• 生產模式

固然，若是你想觀看原始演講的視頻，能夠點擊這裏(https://www.youtube.com/watch?v=nFVjLSvK5po)

10x開發人員，顧名思義，就是比普通開發人員生產力高出10倍的人。

一個10x的開發人員，不僅是能在必定時間內比普通開發人員生產更多代碼，還能像boss同樣調試bug，代碼裏的bug也更少。由於他們會測試代碼，指導初級開發人員，編寫本身的文檔，而且擁有不少其餘技能來讓本身超越僅僅知道如何寫代碼的境界。

H. Sackman，W. J. Erikson和E. E. Grant在1968年進行了一個叫作「比較在線和離線編程性能的探索性實驗研究」的實驗，發現程序員在完成寫代碼的任務上有很大的時間差別。

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

雖然該實驗的設計存在必定的缺陷，例如將使用低級語言的程序員和使用高級語言的程序員混合到了一塊兒，但以後愈來愈多的研究都發現了相似的結果。

雖然關於到底存不存在10x開發人員仍有着普遍的爭論，但本文重點關注的不是這些，而是關注開發人員，如何經過從那些經驗豐富而且被認爲開發速度更快的人那裏獲得的提示和竅門，成爲一名更有生產效率的數據科學家。

你得真正瞭解業務

無論你是爲教育、生物技術仍是金融公司工做，都應該至少對解決問題的業務有一個比較深刻的瞭解。

爲了有效地溝通數據分析背後的故事，你應該瞭解是什麼在驅動業務，而且瞭解業務目標。

例如，若是你負責優化食品卡車的位置，那麼你就須要瞭解客流量，競爭，該地區發生的事件，甚至天氣。你須要想了解公司爲何要優化位置。多是由於公司要增長現有卡車的銷售量，或者是想要增長卡車數量。

哪怕你多是今天在搜索網站工做，明天就到了金融公司去當數據科學家，你也應該爲了使你的分析與利益相關者相關知道是什麼讓業務成爲可能。

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

最後，你應該確保你知道這個項目的利益相關者是誰，而且可以向不懂技術的利益相關者講明白這個項目實際的效果。就像是成爲教育工做者同樣，並可以向不懂技術的利益相關者講明白爲何達成目標可能須要比他們預期的更多時間或資源。

當你瞭解了利益相關方的目標，並可以確保你溝通技術，專業知識和創建解決方案所需的時間，那麼你在大家公司的價值必定會變得更大。

你得真正瞭解數據

瞭解業務很重要，瞭解數據更重要。你須要知道數據該怎樣提取，什麼時候提取，誰負責質量控制，爲何數據會可能存在差距（例如供應商的變化或提取方法的變化），什麼可能會丟失，而且哪些其餘數據源能夠被添加進來以建立一個更準確的模型。

這真的須要你去和不一樣的團隊交談，而且不斷地提出問題。不要懼怕問他們正在作哪些工做，也不要懼怕跟他們討論你正在作哪些工做，由於你永遠不知道你們是否是在作重複的工做，或者他們是否有一個更乾淨的版本的數據，而這偏偏是你須要數據。這樣能夠節省你大量查詢數據庫的時間，例如對SiteCatalyst進行多個API調用。

爲何在項目設計過程當中多花費一些時間和精力可讓你成爲10x數據科學家？

• 你只須要作那些須要完成的工做（在寫代碼以前已經思考過），這樣就能夠快速完成項目，由於你會減小工做量！

• 經過在客戶/用戶認爲他們須要的東西和他們真正須要的東西之間發現不一樣，你就能把本身定位成這個領域的專家和共識的制定者。

• 你會鞏固本身對問題的理解，從而減少犯那些重大錯誤的概率。

你得懂得代碼設計

雖然在設計代碼時有不少很是好的實踐，但其中有一些很是突出的細節將大大增長你的生產效率。

我第一次聽到關於清晰度或清晰度賽過聰明才智的論述是在大學寫做課。 被本身一時的聰明想法抓住，並使用今天剛想到的最新詞彙來表述想法是很容易的一件事，可是像編程同樣，你這樣作不只可能會混淆本身，還會混淆別人。（小編注：好比不按變量命名規則，每次都是a，b，c。。。真的在往後看代碼的時候很崩潰）

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

在第二個例子中，咱們起碼使用了一個參數名稱，加上它還顯示了賦值，咱們能夠看到它是經過序列x中的最後一個元素排序的。

當代碼不怎麼抽象的時候，以後的調試纔會更容易，因此在第三個例子中，我明確命名了個人參數，以便它表示數據。

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

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

.sortBy(x => -x._2)

使用單個字母來命名序列根本提供不了有用的信息，由於當你可能從API，數據庫或Spark中的數據流中提取數據時，你必須運行代碼才能看到」x」到底表明什麼。

因此保持與以前Scala的示例的代碼應該是：

sortBy(clothesCount => -clothesCount._2)

這樣你就能夠知道咱們正在對什麼進行排序，甚至不用運行代碼。

可是，有時使用X做爲變量名稱卻很好。例如，X一般用於機器學習庫，其中X表示觀察到的數據，而y是試圖預測的變量。在這種狀況下，使用這個領域約定俗成的表示，如「模型」，「擬合」，「預測」和「x」和「y」等字段是最好不過的。

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

經過規範你的命名約定，並經過清晰而不是耍小聰明的代碼，它將使重構和調試更容易和更快。按照這兩個代碼設計的竅門，你將走上成爲10x數據科學家的道路。

保持代碼樣式一致，與剛剛咱們說的保持命名約定同樣重要。要得到一些基本的風格點，你應該堅持一種狀況，不要在同一個腳本中混合使用駝峯式大小寫和snake的命名規範，不然的話，你的代碼很快就會變得難以閱讀和瀏覽。另外一種你應該保持一致的方法是同一種任務要堅持使用相同方法。例如，要從字典中刪除重複項，而且須要在代碼的好幾個位置處執行此操做，那麼就不要僅僅由於在Stack Overflow網站上看到過就使用其餘創造性的方法來執行操做。使用最清晰和最不聰明的方法來讓你的代碼和腳本保持一致。而且，我還要再次強調，一致性的目的是爲了不讓你本身和其餘人混淆，這將有助於你更快地進行調試！（請注意，咱們這段話的核心是調試）。

還記住咱們剛剛談到的，必須在代碼中的多個地方刪除字典中的重複項嗎？使用函數，你就不須要屢次重寫代碼。固然，即便你不重用代碼，把代碼封裝在函數中也是相當重要的最佳作法。你的函數應該很小，小到只能作一件事情，以即可以重複調用。

當你不使用函數時，常常會有有全局變量致使命名衝突，代碼不可測試和代碼的不斷重複。

經過使用函數，你的代碼就能夠自由組合，更易於編寫測試單元。

可是不要僅僅止步於寫一些只作一件事情的小函數，請務必抽象你的函數，以便從新使用它們 - 這樣有助於下降代碼冗餘度，並能加快你的開發時間，這樣作下去至少讓你成爲一個2x 程序猿。

儘管不太常見，但代碼設計中很重要的一點是使用樁代碼。樁代碼是簡單的mock類以及函數，能夠顯示輸入，輸出和註釋，併爲代碼提供一個大綱。在你開始實際編寫代碼以前，使用樁代碼會讓你先考慮代碼，並能夠幫助你避免怪異的意大利麪條式的代碼。你會注意到你在編寫代碼以前有哪些重複的代碼，而且會考慮最合適的數據結構。

上面的代碼示例給咱們展現了註釋和文檔。要真正成爲一個被同事喜歡的程序猿，並提升本身做爲一名數據科學家的效率，就要會寫有用的簡明扼要的註釋。這不只應該包括關於代碼段的註釋，還包括其輸入和輸出。

此外，關於docstrings可能最酷的是，它們能夠經過大多數語言的庫轉換爲文檔。例如Python有一個名爲Sphinx的庫，可讓你將docstrings轉換成完整的文檔。

你如今可能知道你的代碼是什麼，但當你嘗試調試或添加函數時，你和其餘人將很是開心有註釋。

不管你使用什麼語言編寫代碼，請記得使用異常處理，併爲你本身，同事和最終用戶留下有用的錯誤信息。上面的代碼顯示了一箇中止函數，可以傳遞來自正在調用的API的錯誤消息。

若是數據不是API須要的，那麼它就會引起一個有用的錯誤消息。在你本身的代碼中，你能夠在中止函數中寫一個消息，幫助用戶：

stop(paste0(「Make sure all your inputs are strings: 」, e))

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

儘管編寫測試單元對於開發人員來講至關廣泛，但這在數據科學領域卻不多使用。固然，你可使用交叉驗證，混淆矩陣和其餘方法來驗證你的模型。 可是，你是否測試了正在爲你獲取數據的查詢？ 你使用的各類方法是如何清理和轉換數據的，你的模型須要它們嗎？ 這些方面對於安全防範「Garbage in, garbage out」（小編注：這兩個單詞的意思是，若是將錯誤的、無心義的數據輸入計算機系統，計算機天然也必定會輸出錯誤、無心義的結果。）相當重要。 當你測試代碼時，不只這兩個將來的證據能夠反映可能引入錯誤的變化，並且當你有能力本身給本身檢查代碼時，每一個人都會認爲你就像一個搖滾明星同樣耀眼，由於一旦代碼被用於實際生產就會發現bug很是少。

爲你的項目使用版本控制是成爲10x數據科學家的重要一步。這最明顯的好處是保存模型的不一樣版本，既能夠輕鬆地進行團隊工做，也能夠經過在存儲庫中使用版本控制進行備份，防止在筆記本電腦被盜或硬盤驅動器墜毀的狀況下丟失工做。

在beta版中，有一個名爲Data Version Control的開源數據版本控制項目，對於數據科學工做流程來講看着頗有但願。 它依靠Git，並容許經過構建數據依賴圖來跨團隊重現項目。你的數據會與你的模型分開保存，它與其餘版本控件同樣工做，容許你回滾到之前保存的備份。

10x開發人員知道使用正確的工具來完成工做，不管是使用庫來節省時間，切換語言以實現性能，仍是使用API，而不是本身從頭構建解決方案。

比方說你如今有一些Twitter或其餘社交數據要用來進行情緒分析。一個選擇是本身標註數據，訓練本身的模型，另外一個則是使用預先訓練的模型。不去本身創建每一個數據模型來從新造輪子是很薄的。使用最適合工做的工具，即便這意味着使用你沒有構建過的工具。

咱們都寫過一個與Cron工做配對的Bash腳原本自動化一些報告，可是，在你花費一些時間嘗試調試由Cron自動執行的其餘人撰寫的報告時，你甚至不知道它在哪裏運行，你會意識到必須有更好的方法才行。經過使用自動化工具，如Puppet，Chef，Ansible或任何其餘流行的自動化工具，你就能夠從集中的位置運行你的工做，所以調試他人（或你本身）的工做就能快不少。

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

雖然上面那副圖中的提供商之間有不少差別，但它們包含了從難以置信的易用性到你須要的更多的設置和知識。本節的內容其實能夠單獨成爲一個話題。若是你想了解有關模型託管的更多細節，能夠查看咱們的其餘幾個不一樣的報告，分別介紹部署模型(https://blog.algorithmia.com/building-intelligent-applications/ )以及部署和擴展你的深度學習模型(https://blog.algorithmia.com/deploying-deep-learning-cloud-services/)。

多是致命傷的事情：

• 易用性

• 成本（包括附加組件和隱藏成本，如託管數據）

• 投標人鎖定

• 語言可用性

經過了解如何部署模型，你纔有能力經過數據來說述故事，輕鬆地與團隊成員共享（無論使用哪一種語言）或將其部署到生產環境中，從而與數千用戶共享。這將幫助你成爲10x-er，由於一旦瞭解了這一點，你就能夠建立更多性能更高的模型，使用戶開心。當用戶開心時，企業主就會開心。

成爲10x數據科學家的技巧

爲了讓這篇文章圓滿，這裏有一些關於如何成爲10x數據科學家的最受歡迎的技巧：

• 模式匹配。這來自於之前遇到相似問題並意識到能夠重用或修改當前問題解決方案的經驗。

• 瞭解如何解釋你的代碼 - 給本身和其餘人。 這意味着你能夠在白板上，作/獲得代碼甚至協同編程。要習慣於談論你的代碼和思考過程。

• 瞭解如何/什麼時候退出並從新開始。若是你意識到有一個更好的方法來解決問題，那就不要懼怕從新開始。最好就是從新開始，作一個更好的方法來完成，而不是放出一些不是最佳或高性能的東西。

• 建立你本身的Gists庫，或經過GitHub或其餘託管服務的存儲庫組織代碼片斷。

最後，回顧整篇帖子，如何成爲一個10x的數據科學家和如何調試實際上是相同的主題。 每一個10x的開發人員均可以想象成一個主調試器，由於這個規則就是不管你的代碼多長，你均可以將它乘以10，並獲得你須要調試的時間。 成爲一個很好的調試器的一個竅門就是使用異常處理，你能夠在IDE中使用調試器，你能夠經過代碼查找邏輯中的錯誤，並檢查涉及錯誤的庫的源代碼，以確保你正在傳遞代碼須要的內容。

即便你從這個帖子只獲得了幾點收穫，恭喜你，你已走上了成爲10x數據科學家的道路。

固然，能不能抵達道路的盡頭，就看你本身咯。

做者 | Stephanie Kim

https://twitter.com/StephLKim