精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

來自Algorithmia的布道師Stephanie Kim在西雅圖PyData大會上呈現了關于數據工程師如何從開發者社區借鑒經驗來提升數據科學技能的演講。在這篇文章里，她把演講內容通過文字的形式再次呈現給讀者，并進行了歸納總結。內容分為五個部分：

相應的演講視頻可以在YouTube上找到，或者查看英文原文Becoming a 10x Data Scientist。

10x開發者是指那些能夠產生10倍于普通開發者效能的開發者。他們在相同的時間內可以寫出更多的代碼，而且這些代碼質量很高，bug很少。他們測試自己的代碼，輔導初級開發者，自己寫文檔，而且還懂得很多代碼之外的知識。

1968年，H. Sackman、W. J. Erikson和E. E. Grant做過一個叫作“編程效率差異性”的探索性實驗。實驗發現，程序員在完成編碼任務上所花的時間存在很大的差異。

參與實驗的程序員平均擁有7年的編程經驗，在極端情況下，他們之間的差異比達到了20比1。

雖然實驗中也存在“作弊”成分，比如有的程序員使用了低級的編程語言而有的則使用了高級的編程語言，但越來越多的研究也都得出了類似的結論。

關于是否存在10x開發者的爭論一直沒有停息，不過不管怎樣，這篇文章主要是想告訴大家如何從高效率的開發者那里借鑒經驗，讓自己成為卓有成效的數據科學家。

　　了解業務

不管你從事的是哪個領域的工作——教育、生物技術、金融行業——你都起碼應該對所在領域的業務有所了解。

在數據分析的背后，你需要知道是什么在推動著業務的發展，需要了解業務的目標是什么。

舉個例子，如果你要優化小吃售賣車的位置，就需要對人流、競爭者、目標區域內發生的事件和天氣都有很好的了解。你要明白為什么要優化位置，這么做可能是為了增加當前售賣車的售貨量，也有可能是因為要增加新的售賣車。

你今天可能是一個搜索網站的數據科學家，而明天可能會跑去金融公司，但不管到了哪里，你都需要了解業務，讓你的數據分析為利益相關者帶來好處。

你還需要了解業務流程，比如誰應該對最終結果負責、在你完成你的工作后誰來接手后續的部分、時間表是怎么安排的。

最后，你要知道利益相關者是誰，并向那些不懂技術的利益相關者說明現實的期望是什么。把自己當成是一個老師，教會那些不懂技術的利益相關者，告訴他們為什么達成目標需要更多的時間和資源。

在了解了利益相關者的目標并在技術和時間方面達成一致之后，你無疑會成為公司更有價值的無形資產。

　　了解數據

了解業務固然重要，而了解數據的重要性也是有過之而無不及。你需要知道數據是如何以及何時被抽取出來的、是誰在負責質量管控、數據之間可能存在的差異（如數據提供者發生變化或數據抽取方式發生變化）、數據可能丟失掉哪些信息，以及可以通過增加哪些數據源來提高數據模型的準確性。

這個需要與團隊展開溝通。你可以大膽地問他們在做什么，也告訴他們你在做什么，避免大家做了重復性的工作，也讓他們對你想要訪問的數據有個清晰的了解。這樣可以為你節省很多時間。

　　為什么說在進行項目設計時多費點心能夠讓你成為10x數據科學家？

代碼設計

在設計代碼時有很多最佳實踐可供參考，其中有幾個比較突出的技巧可以讓你的效率提升若干倍。

在我的一次大學寫作課上，我第一次聽說條理清晰（clearness）比靈巧（cleverness）更加重要。人們很容易就陷入自作聰明的陷阱，使用最新穎的詞匯表達自己的想法，但如果把這種習慣帶到了編程里，不僅可能給自己造成迷惑，也會給別人帶來麻煩。

在上面的例子里，第一行代碼使用了簡短的sortBy方法，它確實很簡短，但很難讓人想明白下劃線代表的是什么意思。很多人在匿名函數的參數上也使用了這種方式，初級開發者（或者你很久沒有看過自己寫的代碼）很難猜出這些代碼是干什么用的。

第二行代碼使用了一個參數名，還寫出了賦值的過程，這樣我們起碼可以知道它要將序列x按照倒序來排列。

代碼可讀性越好就越容易調試，于是第三行代碼就給出了具體的參數名，表明了它的含義。

在進行調試或添加新功能時，你的大腦需要不斷回顧那些短代碼代表的是什么意思，這樣會占用你更多的時間。雖然代碼看起來很簡短，可以少敲幾次鍵盤，但從長遠來看，其實是得不償失的。

Phil Karlton曾經說過：“計算機科學領域有兩大難題——如何讓緩存失效和如何命名事物”。

在這里我們不講緩存，所以就讓我們來講講命名的重要性。以上述的第一行代碼為例：

使用單個字母來命名一個序列并不會為我們提供任何有用的信息，如果你的數據是從某處的API、數據庫或Spark的數據流里抽取出來的，那么你就需要運行這行代碼才能知道x代表的是什么。

再來看看第三行代碼：

我們甚至不需要運行代碼就可以知道我們正在對什么進行排序。

不過，有時候使用x作為變量名也是很有必要的。例如，x經常被用在機器學習的軟件包里，x表示被觀測的數據，而y表示被預測的變量。在這種情況下，應該首選“x”和“y”作為字段名。

不過，在數據科學領域之外，你應該更多地遵循編程語言本身的約定。如果你使用的是Python，那么就應該通過查閱PEP文檔來了解Python的最佳實踐。

良好的命名風格和清晰的代碼邏輯讓重構和調試都變得更加簡單和快速。憑借這兩個代碼設計原則，你離成為10x數據科學家又近了一步。

保持代碼風格一致性也很重要。為了保持代碼風格一致，你要始終如一，比如不要在同一個腳本里混雜駝峰式命名方式和蛇形命名方式，這樣只會讓代碼變得難以閱讀。另外要注意，不要使用多種方式來完成同一種任務。例如，你要在代碼的多個地方給字典去重，為了表現你的創新，你使用了一種很不一樣的方式，只是因為你在Stack Overflow上看到有人這么做，但其實完全沒有必要這樣。你要做的應該是在你的整個代碼里使用一種清晰而不取巧的方式。再次強調，保持一致性是為了避免讓你自己和他人感到困惑，也是為了讓調試變得更簡單。

剛才我們說過，在代碼的多個地方給字典去重應該要怎么做？我們可以使用函數，這樣就不需要寫重復的代碼。即使寫函數不是為了重用代碼，把代碼包裝成函數也算是一個最佳實踐。函數體應該保持緊湊，每個函數只做一件事情，這樣它們更有可能被重用。

如果不使用函數，就會出現很多全局變量，進而導致命名沖突，讓代碼變得難以測試，而且會出現很多重復代碼。

如果把代碼包裝成函數，就很容易進行單元測試。

不僅要保持函數緊湊，讓每個函數只做一件事情，而且要對函數進行抽象，這樣才能重用它們，讓開發速度得到2倍的提升。

雖然人們不是很經常使用代碼樁（stub），但它對于代碼設計來說其實是很重要的。簡單地說，代碼樁就是模擬用的類和函數，它們提供輸入、輸出，描繪了代碼的框架結構。在寫真正的代碼之前使用代碼樁有助于你展開思考，避免寫出怪異的意面式代碼。在寫代碼之前你會注意到哪些地方可能出現重復代碼，并考慮使用更合適的數據結構。

接下來要講講注釋和文檔。要讓你的同事喜歡你并讓自己成為更高效的數據科學家，你就應該在代碼里加入簡潔的注釋。不僅要寫明代碼的用處，還要指出輸入和輸出是什么。

在大部分編程語言里，可以通過一些工具包將docstring轉成文檔，這真是太酷了。比如，Python里有一個叫作Sphinx的工具包就可以將docstring轉成詳盡的文檔。

在寫代碼的時候你當然知道這些代碼是干什么用的，但過了一段時間之后，當你要調試代碼或往里面添加新功能的時候，不管是你自己還是別人都會因為這些詳盡的注釋而感激你。

不管你使用的是哪一門編程語言，都要進行異常處理，并為自己和他人留下有用的錯誤信息。上面的代碼將API的錯誤信息傳給了stop函數。

如果輸入數據不是API所期望的，它就會拋出一個錯誤消息。你可以在代碼里傳一個消息給stop函數：

　　上面的例子來自Hitchhikers的Python指南，并使用了Python測試框架Pytest。

編寫單元測試對于開發者來說是一件很平常的事情，但在數據科學領域就不是這樣的。你一般會使用交叉驗證、混淆矩陣等方式來驗證模型，但你有對抽取數據的方式進行過測試嗎？你有對清理數據和轉換數據的方式進行過測試嗎？這些地方都是對垃圾數據進行攔截的關鍵關卡。測試代碼不僅意味著可以移除bug，當你的高質量代碼進入到生產環境，其他人會看在眼里，你會成為他們眼中的明星。

使用版本控制系統對于成為一個10x數據科學家來說也是至關重要的。你可以保存多種版本的模型，還可以很輕松地進行跨團隊合作，你的代碼保存在代碼倉庫里，如果電腦被偷或者硬盤損壞，代碼仍然是安全的。

有一個叫作Data Version Control的數據版本控制系統，它專注于數據科學工作流，現在還處在beta測試階段。它是基于Git構建的，因此可以通過建立數據依賴圖在多個團隊間共享項目。你的數據與模型是單獨保存的，就像其他版本控制系統一樣，支持回滾到之前的任意一個保存點。

10x開發者知道如何選擇合適的工具，知道如何使用軟件工具包來節省時間，知道如何通過更換編程語言來提升性能，或調用已有的API而不是自己從頭開始開發相同的功能。

假設你要基于Twitter或其他社交媒體數據展開文本傾向性分析，可以自己給數據打標簽然后自己訓練模型，也可以使用別人預先訓練過的模型。不重復發明輪子是最好不過的了。選擇合適的工具，即使那些工具不是你自己開發的。

我們都會通過Crob作業運行Bash腳本來自動生成報告，但當你在調試別人生成的報告時，卻不知道它是從哪里開始運行的，于是你開始意識到我們應該使用更好的工具。我們可以使用Puppet、Chef、Ansible或其他任何一個流行的自動化工具，這樣可以加快調試速度。

　　有時候，不一定會有團隊幫你部署模型，所以你需要自己知道怎么部署模型。

有很多廠商提供了模型部署服務，有些很簡單，有些比較復雜。如果你想知道更多相關細節，可以參考我們的其他演講內容，如“intro to deploying your model”和“deploying and scaling your deep learning model”。

一旦知道如何部署模型，你就可以很容易地與團隊成員分享你的數據模型，或者把模型部署到生產環境，把它們分享給成千上萬的用戶。你會因此成為一個10x的數據科學家，因為你知道如何有效地改進模型來滿足用戶需求。只要用戶開心了，業務所有者也會開心。

　　接下來再總結一下如何成為一個10x的數據科學家。

最后，每一個10x開發者都是調試高手，他們調試代碼的時間通常是寫代碼時間的10倍。要成為一個調試高手，需要做好異常處理，利用IDE的調試器，在代碼邏輯當中尋找錯誤，查看發生錯誤的軟件包源代碼，確保傳入的參數是正確的。

即使你只是從這篇文章里學到了其中幾點，它們也能幫助你在成為10x數據科學家的道路上走得更遠。