萬事開頭難，從一個軟件開發(fā)程序員轉(zhuǎn)型為數(shù)據(jù)科學(xué)家，第一年該怎么做？

一位博主就記錄了自己從全棧工程師轉(zhuǎn)行數(shù)據(jù)科學(xué)家第一年的心路歷程，包括好的方面和不好的方面，希望能幫助到同樣處境的人。

我覺得自己非常幸運，雇主給了我一個機會，讓我從一個全棧軟件開發(fā)人員轉(zhuǎn)型變成數(shù)據(jù)科學(xué)家，和內(nèi)部數(shù)據(jù)團隊一起工作。

入職一年，我很享受這份工作給我?guī)淼娜绿魬?zhàn)，完全不同于以前做開發(fā)。我想寫這篇文章，首先是為了回顧過去一年所做的事情：我經(jīng)歷的改變，我做得好的地方，我可以改進的地方。第二，通過記錄我曾經(jīng)遇到過的問題和挑戰(zhàn)，我希望能幫助到和我處境相似的人。

在開始之前，我先介紹一下我的背景：我之前不是做軟件開發(fā)的，我擁有計算機科學(xué)的碩士學(xué)位和博士學(xué)位。因此，我不算冷啟動，我有工具、模型和分析方法方面的相關(guān)經(jīng)驗。我從事開發(fā)工作將近8年。自從我的論文發(fā)表以后，我經(jīng)歷了很多變動。

本文將分為兩部分。進展順利的部分和進展不佳的部分。對于那些只對結(jié)果感興趣的人，也可以拉到底直接看最后的結(jié)論。

Python 和 R

剛開始，我不確定在項目中該使用Python或R。所以一開始我對這兩種語言均作了研究學(xué)習(xí)，并在項目中結(jié)合使用了這兩種語言。

R經(jīng)常讓我想起Matlab，兩者在用來編寫和執(zhí)行代碼的界面非常像（我嘗試了R Studio和Visual Studio的R插件），同時寫代碼和處理數(shù)據(jù)的方法也很像。

但我只在碩士論文中用了R，還在博士學(xué)位論文中用了一些。除此之外，R和其他編程語言相比（這些年來，我在軟件開發(fā)中經(jīng)常使用C#）就沒什么共性了。R這個工具極度以數(shù)據(jù)為中心，與數(shù)據(jù)進行交互的方法也很不一樣。

在R里有：列表，矩陣，向量，數(shù)組和數(shù)據(jù)幀。每個都有不同的使用場景，你需要學(xué)會什么時候使用。R與C#的語法很不一樣，所以剛開始學(xué)R我遇到了不小的困難。我并不是說R不好，只是我使用Matlab10年，并且作為開發(fā)我的腦子已經(jīng)習(xí)慣了某種思維方式，所以比較難轉(zhuǎn)變。所以我剛開始的時候覺得R很難上手。

作為一名有8年C#開發(fā)經(jīng)驗的程序員，我覺得Python比R更容易起步。很可能是因為我的大腦已經(jīng)習(xí)慣了C#的思維方式。python比R更接近于C#，所以我學(xué)Python比R快很多。

在使用這兩個語言時，我沒覺得兩者有明顯區(qū)別，尤其是對于可用的庫，兩者在我想做的工作的實現(xiàn)方面有差不多的處理能力，我也會得到相同的結(jié)果。但在摸索過程中，我對兩個工具分別都有些困惑。

總的來說，編程編久了，Python對于我的程序員思維更友好。

所以我很快放棄了學(xué)習(xí)R，轉(zhuǎn)而專注Python。這有助于我更快地進步，不必再花時間閱讀新語法，事情變得簡單許多，我一直覺得簡單才是王道。這對我應(yīng)對角色的許多其他變化也是有幫助的，因此，這樣做可以最大程度地減少更改。

關(guān)于使用哪種以及何時使用，我敢肯定大家定對此有很多意見，但是對我來說，從開發(fā)人員過渡到數(shù)據(jù)科學(xué)家后，我發(fā)現(xiàn)Python變得更容易掌握和使用，尤其是在我擔任新職位后想快速發(fā)展并取得成果的初期。

所以與R相比，使用Python讓我更快進入狀態(tài)，在輸出方面，我沒有發(fā)現(xiàn)兩者有任何明顯區(qū)別。所以我把這個歸類為進展順利，因為我很早做出了決定，且至今沒有遇到任何情況讓我覺得自己選錯了Python，相反我節(jié)省了不少時間，所以我能更快地開始工作。

文檔記錄

記錄一切，我定義的一切是從模型超參數(shù)到從何處以及如何獲得訓(xùn)練數(shù)據(jù)，到在整個項目中做出選擇的理由。另外，以有序的邏輯方式編寫文檔，實現(xiàn)這一目標的一個秘訣是，哪怕你只是寫給自己看（例如，在我的情況下，我是唯一的數(shù)據(jù)科學(xué)家），你應(yīng)該想象有人會讀這份文檔。

此外，記錄時要對自己有一定的約束，不要拖拉，不要走捷徑。不然等你開始寫的時候，你可能已經(jīng)忘記一些需要注意的細節(jié)。因此一定要及時寫下來。在完成文檔之前，我覺得工作就還沒做完。我從一開始就遵循這種方法，我覺得至關(guān)重要。

我發(fā)現(xiàn)一件事是，即使在一個中型企業(yè)，等到一個項目的研究成果在公司開始推廣已經(jīng)是一段時間以后了，利益相關(guān)方因為有其他事要忙，所以不會立刻作出回應(yīng)。

有時候在我完成一個項目幾個月后，有人跑來問我問題，我一時想不起來，但如果我翻看我之前做的文檔記錄就能馬上提供詳盡答案。例如，有一次我與另一位經(jīng)理聊起幾個月前做的一個項目，我向他展示了我已經(jīng)完成的工作，他問我訓(xùn)練集的大小是多少，以及我用來獲取數(shù)據(jù)的日期區(qū)間。我并記不得那些數(shù)據(jù)，但我記得自己已經(jīng)寫下過，而且我也記得寫在了哪里。所以我能馬上把文檔拿給他們看。

我發(fā)現(xiàn)自己遇到的另一種情況是當業(yè)務(wù)優(yōu)先級發(fā)生變化，你可能會需要停下手頭還沒完成的項目去做另一個項目。當你再回到之前開始的項目時，完整的文檔可以讓你從之前停下的地方繼續(xù)進行下去。

數(shù)據(jù)存儲

回顧前一年，進展不順利的一個原因是我處理數(shù)據(jù)的方式（對于數(shù)據(jù)科學(xué)家而言這非常關(guān)鍵）。

當我沒有使用數(shù)據(jù)庫的經(jīng)驗時，我基本上復(fù)用了在博士期間使用數(shù)據(jù)的方式。使用平面文件（特別是CSV）來存儲數(shù)據(jù)。我把從生產(chǎn)環(huán)境中提取的初始數(shù)據(jù)，清洗后的中間過程數(shù)據(jù)，分析后的數(shù)據(jù)和結(jié)果都存在了CSV里。我工作流程中的每一步驟都需要通過Python腳本讀取上一步創(chuàng)建的文件，并創(chuàng)建新的文件。

這種把內(nèi)容存儲在硬盤上，并通過Python腳本與數(shù)據(jù)交互的原始辦法，很快就出現(xiàn)了一些問題：

有時很難在大量文件中找到我要找的那個文件。即使我記錄了文件的內(nèi)容和位置，但有時還是很難找到我想要的確切文件，因為文件實在太多了。

我似乎總是在忙著用Python把從文件中讀取數(shù)據(jù)或者將數(shù)據(jù)寫入文件。我寫了很多文件訪問的命令，但其實是在做重復(fù)勞動，寫這些代碼對我要做的工作并沒什么幫助。

想快速地將數(shù)據(jù)總結(jié)一下似乎都有點費力：讀取數(shù)據(jù)，匯總統(tǒng)計，輸出統(tǒng)計，查看統(tǒng)計結(jié)果。

有些文件很大，用起來很困難（在notepad中打開10GB以上的文件很麻煩）。

第一年，我花了很長時間才意識到SQL是我的解藥。

在從事數(shù)據(jù)科學(xué)家工作之前我使用過SQL，但是我一開始沒有意識到它對我的價值。當我意識到SQL就是我的解決方案后，我花了很多時間來學(xué)習(xí)更多有關(guān)SQL的知識，因為我在做程序員的時候稍微學(xué)了一點SQL。

具體來說，我學(xué)習(xí)了如何查詢數(shù)據(jù)（特別是我以前沒接觸過的高級語句）以及搭建和維護數(shù)據(jù)庫的基礎(chǔ)知識。我甚至通過了兩個Microsoft SQL的考試。我現(xiàn)在主張盡可能用SQL。我把所有項目的數(shù)據(jù)都存在了SQL數(shù)據(jù)庫中，盡量在SQL中做數(shù)據(jù)查詢和操作。

我的原則是：能在SQL中完成的處理，就在SQL中做。SQL處理不了的任務(wù)再用Python（例如，模型訓(xùn)練和執(zhí)行）這里延伸出一個問題：你需要學(xué)會使用Python庫，例如 SQLAlchemy，從 SQL讀取數(shù)據(jù)到Python里。

現(xiàn)在我的后SQL生活變得容易很多：

所有項目數(shù)據(jù)存儲在一個容易找到的地方。

沒有重復(fù)代碼用于讀寫文件。

我能快速查詢數(shù)據(jù)并從數(shù)據(jù)中輕松得到統(tǒng)計結(jié)果。

我能夠很容易地查看大量數(shù)據(jù)，特別是前幾行的數(shù)據(jù)。

額外的好處是現(xiàn)在很容易把不同的數(shù)據(jù)聯(lián)系起來，因為數(shù)據(jù)都已經(jīng)在關(guān)系數(shù)據(jù)庫中了，現(xiàn)在安全性也提高了：把數(shù)據(jù)存在本地磁盤上有潛在的風(fēng)險。數(shù)據(jù)都在服務(wù)器里，安全很多。

因此，我強烈推薦學(xué)好SQL并用起來。

如何展示成果？

還有一個進展不順利的地方是我做的一些展示。從開發(fā)人員到數(shù)據(jù)科學(xué)家的一個變化是，我做演示的場合變多。展示的內(nèi)容各種各樣，有面向技術(shù)人員的demo演示，有面向業(yè)務(wù)相關(guān)人員的項目報告，再到與公司內(nèi)部其他部門討論項目工作，甚至向公司外部的第三方合作方展示工作。

對于這些人我覺得我沒有做好的一點是我沒有根據(jù)受眾來調(diào)整自己的展示方法。有些展示我做得還不錯，比如對開發(fā)人員的技術(shù)演示我覺得我做得還不錯。因為我跟技術(shù)人員擁有差不多的背景所以說技術(shù)的內(nèi)容彼此也聽得懂，交流起來會更容易一些。其他類型的演示更難一些，不幸地是很多時候我在展示的時候才意識到聽眾對我講的內(nèi)容不是很在意。

我的受眾分為四類，從展示的難易程度來分如下：從最簡單的（最左邊）開始，到最難的（最右邊）：開發(fā)人員，業(yè)務(wù)方，其他部門以及外部人員。

我還可以將最左邊的那些受眾標記為最技術(shù)性的，將右邊的那些受眾標記為更“銷售型”的，當從左向右移動時，兩者之間會有一個過渡。我發(fā)現(xiàn)針對左邊受眾的展示是最容易準備的——他們對我正在使用的技術(shù)或所從事的業(yè)務(wù)領(lǐng)域有深刻的了解。

針對外部人員的演示是最難的，因為他們往往相關(guān)知識最少。過去，我與這些聽眾進行交流的時候會直接進入到技術(shù)細節(jié)，就像我和左邊聽眾交流時一樣，但是結(jié)果很不好，因為他們不一定具有任何數(shù)據(jù)科學(xué)或機器學(xué)習(xí)的背景，所以我談?wù)撛S多概念對他們沒有多大意義，他們不知道我在說什么。對這些受眾來說，如果我花點時間介紹一下我正在做的工作以及更多的背景知識，效果會更好。甚至對某些受眾來說，向他們介紹機器學(xué)習(xí)的概念，為什么我們要使用它以及它的好處。有時候，對我來說，不過多討論技術(shù)細節(jié)反而是好事，給他們一些大概的框架概念就好。

在反思了這一點之后，我現(xiàn)在在準備演示材料時，會更多地考慮我的目標受眾。具體來說，我會考慮聽眾可能知道或不知道的內(nèi)容，以及需要向他們呈現(xiàn)的內(nèi)容，以幫助我準備需要討論的內(nèi)容和專業(yè)程度。這樣他們就可以更好地理解我正在談?wù)撌裁?，并從演示中得到一些收獲。為此，在準備演示文稿時我為自己準備了一些有用的問題，如下：

聽眾對于數(shù)據(jù)科學(xué)領(lǐng)域了解多少？

聽眾對于我試圖解決的問題了解多少？

聽眾知道我在使用的技術(shù)嗎？

聽眾對于我采用的技術(shù)細節(jié)或者結(jié)果感興趣嗎？

計劃

與做程序員時相比，做數(shù)據(jù)數(shù)據(jù)家的工作計劃更有挑戰(zhàn)。作為開發(fā)人員，工作相對比較直接，所以也更好估算和排期。你通常知道你要實現(xiàn)的目標以及如何實現(xiàn)。當我還是一名開發(fā)人員的時候，我使用敏捷開發(fā)工具。

因此，工作內(nèi)容可以先評估、計劃，然后排好優(yōu)先級就開始做。在敏捷的方法論指導(dǎo)下，如果工作沒什么意義，或者你不清楚如何做，你就不會把它排進工作計劃。因為無法評估，因為未知，你要等到所有不明確的地方明確后才開展工作。

數(shù)據(jù)科學(xué)的工作并不像這樣簡單，對于給定的問題你不會總是提前知道什么會起作用。也不會總是知道哪種類型的模型最準確。類似這樣的情況與剛才提出的觀點出現(xiàn)矛盾，當你是開發(fā)人員時，只有問題明確后，你才會把他們放入你的工作列表中。作為數(shù)據(jù)科學(xué)家，未知是你工作的一部分，因為你的工作就是要回答這些問題。或者你正在處理的問題可能會隨著項目進展而改變。因此，有時候你提前做的幾周計劃可能很快要重新考慮。

在計劃方面，我喜歡將開發(fā)工作視為線性的——你知道自己在做什么以及如何做。數(shù)據(jù)科學(xué)工作我覺得是分叉樹，可能需要試不同的道路，可能會碰到死胡同。

數(shù)據(jù)科學(xué)家做短期工作計劃還是可行的，比如你正在訓(xùn)練和測試的模型之類的——接下來一兩周的工作，但是，長期計劃很難做。你不可能總是提前知道什么會起作用，什么不會。所以我們才要進行實驗和測試，這是數(shù)據(jù)科學(xué)家工作的核心價值。

最后，花點時間去做不一定會有成果的工作，即使不起作用，也沒什么大不了的。

回答正確的問題

在過去一年中（這讓我栽過很多跟頭），我發(fā)現(xiàn)數(shù)據(jù)科學(xué)工作的關(guān)鍵部分是回答問題，但更重要的是回答正確的問題。

正如我所說，我栽過幾次跟頭，當時我正在回答一個問題，但并沒有回答業(yè)務(wù)方實際想要回答的問題，之所以發(fā)生這種情況，是因為業(yè)務(wù)方使用的業(yè)務(wù)語言跟我用的的技術(shù)語言有差異，有時候我們用一樣的詞但要表達的意思卻不同。

針對這問題我的解決方法是在做項目的實際工作（現(xiàn)在稱為“項目前”工作）之前先做準備性工作，在這個階段，我會從業(yè)務(wù)方那里收集初始需求和信息。做一些初步分析，然后給業(yè)務(wù)方展示。

運用敏捷的工作思路，我希望在每個sprint實現(xiàn)一個可交付的成功，并向業(yè)務(wù)方展示該成果。這樣，我與業(yè)務(wù)方建立了一個有效的循環(huán)反饋機制，向他們展示一些東西并詢問他們的意見，這可以建立一個有效對話，從而更清晰地定義真正要解決的問題。這個方法在項目各個階段都有效，不僅僅是初始階段。當你向業(yè)務(wù)方展示你的工作結(jié)果時，可能會激發(fā)他們不同的想法以及他們之前沒有考慮過的思路。從而你能找到他們真正的痛點。

所以過去一年來我發(fā)展的一項關(guān)鍵技能是與業(yè)務(wù)方的互動交流，深入挖掘他們真正想要的東西。

Python比R更容易學(xué)習(xí)，因為對于程序員來說python與其他編程語言更接近。

邊執(zhí)行邊做文檔

學(xué)習(xí)如何使用關(guān)系數(shù)據(jù)庫，比如SQL，用數(shù)據(jù)庫來查詢，操縱和存儲數(shù)據(jù)。

你需要準備很多展示，不僅是向項目業(yè)務(wù)方的報告，還要向公司其他同事報告，甚至是公司外面的人。

你需要提高演講能力以滿足不同受眾（技術(shù)或非技術(shù)）的需求。

工作計劃不是一帆風(fēng)順的，因為你無法預(yù)知什么起作用什么無效，要有心理準備有時候花了時間不一定取得預(yù)想的結(jié)果。

花時間找你真正要解決的問題，不要不加思考就埋頭開始做，與業(yè)務(wù)方建立反饋閉環(huán)是很有必要的。