想成為一名戰鬥力超強數據分析師?讓公司程式白痴聽懂程式碼在幹嘛,保證你立刻成為最強人才

Photo via VisualHunt

【我們為什麼挑選這篇文章】 這篇文章是全球女性工程師組織 PyLadies 的創始人 Lynn Root 在 PyData London 大會上的演講摘錄,她主要從事數據挖掘和分析工作。在這次演講裡她分享了幾個數據分析師的工作優化方法,同時分享了如何成為一個超高效率的工程師?(責任編輯:劉庭瑋)

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

這篇文章分為五部分,其中包括:

  1. 10x 開發者的歷史和爭議
  2. 項目設計
  3. 代碼設計
  4. 工作工具
  5. 生產模式

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

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

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

H. Sackman,WJ Erikson 和 EE Grant 在 1968 年進行了一個叫做「比較線上和離線編程性能的探索性實驗研究」的實驗,發現工程師在完成同樣 coding 任務上有很大的時間差異。

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

雖然該實驗的設計存在一定的缺陷,例如將使用低級語言的工程師和使用高級語言的工程師混合到了一起,但之後越來越多的研究都發現了類似的結果。

雖然關於到底存不存在 10x 開發人員仍有著廣泛的爭論,但本文重點關注的不是這些,而是 關注工程師,如何透過從那些經驗豐富並且被認為開發速度更快的人那裡得到的提示和竅門,成為一名更有生產效率的數據科學家。

你得了解業務

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

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

例如,如果你負責優化食品卡車的位置,那麼你就需要了解客流量、競爭、該地區發生的事件、甚至天氣。 你需要想了解公司為什麼要優化位置。 可能是因為公司要增加現有卡車的銷售量,或者是想要增加卡車數量。

哪怕你可能是今天在搜尋引擎網站工作,明天就到了金融公司去當數據科學家,你也 應該為了使你的分析與利益相關者知道是什麼(數據)讓業務成為可能。

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

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

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

你得真正了解數據

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

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

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

  1. 定義有意義的工作 :你只需要做那些需要完成的工作(在寫 Coding 之前已經思考過),這樣就可以快速完成項目,因為你會減少工作量!
  2. 透過在客戶/用戶認為他們需要的東西和他們真正需要的東西之間發現不同,你就能把自己定位成這個領域的專家和共識的制定者。
  3. 你會鞏固自己對問題的理解,從而減小犯那些重大錯誤的機率。

你得懂得代碼設計

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

我第一次聽到關於清晰度或清晰度勝過聰明才智的論述是在大學寫作課。被自己一時的聰明想法抓住,並使用今天剛想到的最新詞彙來表述想法是很容易的一件事,但是像編程一樣,你這樣做不僅可能會混淆自己,還會混淆別人。(小編註:比如不按變量命名規則,每次都是 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))

以上示例來自「itchhikers 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/)。

可能是致命傷的事情:

  1. 易用性
  2. 成本(包括附加組件和隱藏成本,如託管數據)
  3. 投標人鎖定
  4. 語言可用性

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

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

為了讓這篇文章圓滿,這裡有一些關於如何成為 10x 數據科學家的最受歡迎的技巧:

  • 模式匹配 。這來自於以前遇到類似問題並意識到可以重用或修改當前問題解決方案的經驗。
  • 了解如何解釋你的代碼 – 給自己和其他人。這意味著你可以在白板上,做/得到代碼甚至協同編程。 要習慣於談論你的代碼和思考過程。
  • 了解如何/何時退出並重新開始。 如果你意識到有一個更好的方法來解決問題,那就不要害怕重新開始。 最好就是重新開始,做一個更好的方法來完成,而不是放出一些不是最佳或高性能的東西。
  • 創建你自己的 Gists 庫 ,或通過 GitHub 或其他託管服務的存儲庫組織代碼片段。

最後,回顧整篇文章,如何成為一個 10x 的數據科學家和如何調試其實是相同的主題。每個 10x 的開發人員都可以想像成一個主調試器,因為這個規則就是無論你的代碼多長,你都可以將它乘以 10,並得到你需要調試的時間。成為一個很好的調試器的一個竅門就是使用異常處理,你可以在 IDE 中使用調試器,你可以透過代碼查找邏輯中的錯誤,並檢查涉及錯誤的庫的源代碼,以確保你正在傳遞代碼需要的內容。

即使你從這篇文章得到了一點收穫,恭喜你,你已走上了成為 10x 數據科學家的道路。

當然,能不能抵達道路的盡頭,就看你自己囉!

(本文經 AI 科技大本營    授權轉載,並同意 TechOrange 編寫導讀與修訂標題,原文標題為 〈 經驗| 如何成為一名頂級戰鬥力的數據分析師? 〉。Photo via VisualHunt)

延伸閱讀

想當資料科學家?除了 Python 之外,你還應該要認識這 6 個資料界的超強 coding 語言
神經網絡之父 Geoff Hinton 推翻畢生心血「反向傳播演算法」:打掉重來,AI 才有未來!
打敗 R 語言,Python 是如何登基成為史上最熱門數據分析語言?
數據分析也能預測美劇劇情?博士生神預測《冰與火之歌》龍媽要領飯盒了
IBM、Google、Amazon 人工智慧技術遭質疑!AI 和機器學習、數據分析差別究竟在哪?

 


我們正在找夥伴!

2019 年我們的團隊正在大舉擴張,需要你的加入跟我們一起找出台灣創新原動力! 我們正在徵 《採訪社群編輯》、《助理編輯》,詳細職缺與應徵辦法 請點我

點關鍵字看更多相關文章: