[做者:DeepLearningStack,阿里巴巴算法工程師,開源TensorFlow Contributor]前端
「作算法的人要熟悉算法框架源碼嗎?算法工程師難道不該該會使用框架建模就能夠了嗎?如何成爲具備必定競爭力的算法工程師?」...git
我常常被不一樣的人問相似這樣的問題。坦白地說從我我的經驗來看,身邊算法作的不錯的人對算法框架源碼廣泛熟悉,並且算法建模這件事在當前來看還並不能純粹的與底層隔離,由於你會常常與計算性能,算法實現原理打交道。固然,我也見過一些比較浮躁的從業者,認爲算法工程師應該只作建模不碰源碼,這些人通常都只是根據網上教程跑通了個MNIST,ImageNet的例子就認爲本身能夠勝任算法工程師的工做了,這種人其實不是想作算法,而是不想寫代碼而已。算法門檻表面上在下降,可實際上是不斷升高的。一方面,學術界算法創新競爭愈來愈激烈,主要表如今AI相關的頂會變多,accept的paper也愈來愈多,多到根本看不過來,你如今所想到的模型創新,沒準在另外一家公司或者學校已經走到實驗驗證階段了;另外一方面,性能優化和定製的功能開發等工程能力愈來愈重要。如今來看,市場上作想要算法的人很是多,但到面試經過的機率很低,這也側面說明了競爭門檻實際上是比較高的。github
但這也是機會。若是你是作算法的,請趁此機會提高本身的工程能力和算法領域內的影響力。How?其實很簡單——爲算法領域的知名開源軟件貢獻代碼。由於我我的是TensorFlow的contributor,因此我以TensorFlow爲例爲你們介紹。面試
首先,進入TensorFlow的GitHub頁面,地址以下:https://github.com/tensorflow/tensorflow ,能夠看到以下頁面。算法
紅色框內表示當前TensorFlow這個開源項目已經有1844我的貢獻過代碼,想要加入這個行列的coder們請努力吧,這並無想象中那麼難。由於咱們沒法直接對開源項目clone開發,而只能在咱們本身的倉庫中開發,因此咱們須要點擊Fork按鈕,將該項目Fork到本身的GitHub倉庫名下,而後咱們就能夠在咱們本身的倉庫中看到這個項目。性能優化
成功Fork以後,咱們就能夠將它Clone下來進行開發了。每次開發以前最好切出一個分支出來,避免直接在master上作修改。架構
自從咱們Fork新項目起,咱們本身倉庫的master將再也不與開源master有任何聯繫,也就是說咱們本身倉庫的master代碼將再也不隨着開源master自動更新。那麼如何及時更新本身的倉庫呢?這須要爲咱們clone下來的項目添加upstream,即上游遠程倉庫。這很是簡單,只須要一句命令便可搞定。咱們須要將開源master的git地址複製下來而後添加到當前項目的,對於TensorFlow來講執行下面命令便可。框架
git remote add upstream git@github.com:tensorflow/tensorflow.git
這樣就與開源社區master創建起了聯繫,咱們能夠看到配置文件.git/config文件中確實添加了upstream。分佈式
這一步比較常規,在本地切出開發分支,編寫代碼,提交到咱們本身的倉庫中。性能
當咱們將本身的commit提交到本身的GitHub倉庫以後,就能夠向Fork源master提交Pull Request(簡稱PR)申請了。首先進入本身的GitHub倉庫頁面,點擊New pull request按鈕。
點擊後進入Comparing頁面,咱們選擇須要往Fork源merge的分支,以下所示。因爲我當前這個分支已經提交了PR,但還處於review期間,因此生成的頁面不太同樣。
這是最後一步,須要在生成的頁面中填寫本身要貢獻這段代碼的緣由,而後引入相關的reviewer進行討論。不得不說,這一部分很是關鍵,由於大部分reviewer只會review代碼規範,而這段代碼的做用自己須要你們本身解釋清楚。若是你曾經在該項目中貢獻過代碼,那麼會顯示Contributor字樣。
自此,你成功的向開源社區提交了一個PR,離成爲Contributor走進了一步。
通常狀況下,TensorFlow的reviewer響應都是比較快的,並且他們對於技術討論很是開放,也很是願意社區積極貢獻代碼。Reviewer會在你的PR上提出各類Comments,在不斷的代碼refine以後,代碼將最終成功merge到開源master中,從狀態上看你的PR將會顯示紫色的Merged。若是到了這一步,那麼恭喜你,成功成爲了TensorFlow社區的Contributor!
TensorFlow社區master天天都會更新,因此建議天天作一次代碼同步,很是簡單,兩行git命令就能搞定。
git pull upstream master
git push origin master
分別是將upstream(也就是Fork源)代碼更新到本地,向origin(本身的倉庫遠端)更新代碼。
由於你的貢獻讓TensorFlow更加完善,因此在以後的發佈通告中會出現你的名字。下面的這段發佈通告來自於TensorFlow 1.13.0 RC2,其實你能夠從描述中看到,在1800+名Contributor中,絕大部分是Google內部的人,因此Google外部的Contributor很是少。
其實很是多。TensorFlow一大特色是通用性,但願可以在各類場景下均可以變得成熟。可是這個目的工程量浩大,難免存在Bug,設計不完善,性能不理想,功能不全面等狀況。其實在使用TensorFlow建模時就會遇到他們,並且機率還真不小。固然你能夠遇到問題選擇繞開它們,但這可能也意味着你錯失了一個提PR的機會。提PR的前提是你必須對源碼有所瞭解,因此算法工程師們在讀paper讀累了的時候不妨換換思路,天天看一點TensorFlow源碼多提高一些工程素養。
TensorFlow是Google重要的算法軍火庫,Google圍繞着TensorFlow自己還作了其餘子項目,他們也很是重要。另外,也能夠加入討論組。
TensorFlow生態中子項目至關豐富,有前端TensorBoard,有易用性框架Estimator等等。這些子項目也一樣須要社區貢獻力量。
Community子項目其實就是TensorFlow的RFC文檔,它是TensorFlow 2.0的標準,裏面含有一些模塊和接口的設計。爲何要關注RFC文檔?這是由於TensorFlow的發展比較快,常常出現某些模塊被棄用,某些新模塊將要大力發展的狀況。這些信息對於開發者很是重要,若是你想共享一段代碼,但它與社區的發展標準背道而馳,那麼將是無用功,因此RFC文檔對於避免虛工是很是有用的。但一個標準的提出也須要通過社區的審覈和討論,因此若是有本身的想法,能夠在Community中提出本身的comments,引入更多的人蔘與討論。
從TensorFlow項目這一個點出發,咱們能夠不怎麼費力氣地學習到更多的開源項目,並且TensorFlow架構和源碼設計足夠複雜,這使得咱們在看其餘相關項目時變得相對輕鬆。好比當你對TensorFlow使用單機多卡GPU通訊感興趣時,能夠參考NCCL。當你對多機分佈式感興趣時,你或許能夠看看Uber開源的Horovod。當你想要研究不一樣框架之間的差別時,你也許能夠看看Pytorch,caffe2和MXNet。這種輻射式的積累會讓咱們學習更多的軟件設計哲學。
因爲本人也是算法工程師,工做中不只是TensorFlow的用戶,也在本身所任職的公司參與TensorFlow的定製開發與性能優化。從我我的角度來看,算法工程師這個職位不得不說是含有大量水分的,一方面真正懂算法可以在AI頂會發一些高質量paper的人佔比並不高,另外一方面,在算法工程上理解較深的人也並很少,而在算法和工程兩方面都比較強的人就更少了。如今屬於算法領域較熱的時段,這方面的油水,薪資競爭力和需求量都很大,因此市場上存在不少想要進入這個領域的人,這是好事。可是若是一我的本身跑幾個模型例子就聲稱本身能夠作算法而且十分反感寫代碼的話,那他在算法領域也不會有很好的發展。除非,你是一個算法造詣很是高的天才而且可以勝任算法科學家的人。不然,請不要欺騙本身,認真培養你的算法能力和工程能力,畢竟你的目標仍是一個合格的算法工程師。