2016 程序人生大串燒

01-28

12月是 tubitv 最為繁忙的一個月份。在這個月，廣告金主們留下了充沛的預算，揮舞著支票衝進節日的市場；可愛的用戶們，一年間就尋覓著這麼一個機會，半推半就的休上十天半個月的假，吃喝玩樂，不亦樂乎。高富帥白富美自然是在夏威夷，坎昆，阿斯本等地和大自然一起消磨時光，而屌絲群體，多數在家呆著，只好看！電！視！了！要說美國人對電視的熱愛，那簡直到了令人髮指的地步 —— 根據 Nilson 的統計，平均每人每天看 4.3 小時。所以你可以想像，像我們這樣的 video streaming service 是多麼歡迎聖誕季，同時又是多麼為之忐忑：求求菩薩保佑我，服務千萬不要掛。。。

寫這篇文章的時候，我瞅了一眼 github，12月份我竟然發了 35 個 pull request，review 了 38 個。元旦休息這幾天，我還發了 3 個 pull request，添了 3800 行代碼，刪了 1400 行。

所以，原本計划上月末撰寫的串燒文章，一拖再拖，拖到了現在。

（一）

2016 年我文章的產量不如 2015，但質量在穩步上升（自誇臉）。寫公眾號近三年，公眾號後台的素材總數已達到 340 篇。如果說 2014 年我寫文章更多是為了完成目標，2015 年寫文章為了迎合讀者的口味，那麼，2016 年我的文章大多是為了自己而寫，或者說，對思想的留此存照（冥想盆）。對我而言，自利的同時能夠利他，是最好的選擇。這也是為何我非常推崇 learning by teaching 的原因。

先來點形而上的：

你要避免的軟體開發模式
技術債：the good, the bad, and the tao
談談面向對象編程
談談我對工程和管理的看法
軟體隨想錄：代碼與數據

軟體隨想錄：代碼與數據等數篇文章從宏觀上談談軟體開發，設計，以及管理，不管入行深淺，都值得一讀。

形而上最後還是要落地，作為一個程序員，首當其衝的就是代碼命名問題。這是個終極問題，弄懂的同學可以接下來研究：

我是誰？我生從何來，死往何處，我為何要出現在這個世界上，我的出現對這個世界來說意味著什麼，是世界選擇了我，還是我選擇了世界。我和宇宙有必然的聯繫嗎？宇宙是否有盡頭，時間是否有長短，過去的時間在哪裡消失了，未來的時間又在何處停止，我在這一刻提出的問題，還是你剛才聽到的問題嗎？

言歸正傳。

我們都說名如其人，不要小看命名，糟糕的命名會導致糟糕的代碼。我公眾號第一篇閱讀過萬（汗）的文章：代碼命名：僧敲月下門講的就是這個問題。我想，很多人讀後有種於我心有戚戚焉的感覺，才力捧以及在朋友圈力薦它。

除了命名，另外一件但凡程序員都或多或少會遇到的事情就是重構。我特地為你準備了：代碼重構之道，重構：撰寫合格的代碼。希望能夠對你有所啟發。

隨著編程功力的提升，程序員需要隨之提升的是抽象的能力，以及元編程的能力（來來來，咱們元編程入個門）。可惜，寫到這裡已經曲高和寡了。

（二）

如果要硬生生把程序員分成兩個群體：會寫代碼的，不會寫代碼的。也可以這麼分：調 API 的，寫 API 的 —— 做 UI 的調完 SDK，調後端給的 API；做系統的一層層封裝 API，最後包個 REST 的皮膚扔出去。其實廣義說來，每個程序員即是寫 API 的，也是調 API 的。每一個你寫就的函數，都是一個 API。

撰寫 API，尤其是 REST API，如今越來越成為程序員的一大主要工作。為此，我準備了一套全家桶，詳細闡述我做 API 的心得：

撰寫合格的REST API （2015年舊文）
再談 API 的撰寫 - 總覽
再談 API 的撰寫 - 架構
再談 API 的撰寫 - 架構再談 API 的撰寫 - 子系統
再談 API 的撰寫 - 契約

拿去不謝。2016 API 界比較重大的事件是 GraphQL 終於 production ready 了：GraphQL，你準備好了么？那麼，是不是意味著 REST API 未來有可能被淘汰呢？我覺得幾年內不會。未來更會發生的事情是 REST / GraphQL 並存。GraphQL 作為一層對外的窗口，包裹住 REST API。一個 GraphQL API，其數據源可能來自若干 REST API。二者互補。

（三）

我最最最推崇的 Professor Randy Pausch 說過：

「Fundamentals, fundamentals, fundamentals. You』ve got to get the fundamentals down because otherwise the fancy stuff isn』t going to work.」

對此，我確定一定以及肯定地贊同。在基礎知識這塊，程序君為你精心熬制了：

Concurrency
非同步處理的腦力遊戲談談編譯和運行
Pipe 之美
從 Pipe 到 Flow
ZeroMQ及其模式

ZeroMQ及其模式ZeroMQ 看上去是某個特定的應用，但其構建消息系統的思路和使用場景，如：pub / sub，router / dealer 等概念，一定要掌握。另外，都 2017 年了，如果還弄不明白 at least once / at most once 的消息傳遞機制，趕緊再翻回去看看。

程序員這一行，最怕的不是人老色衰，是未老先衰。技術從來都不是保值的，技術背後的知識才是駐顏術。當你要學習一門新的技術時，你該怎麼做？希望如何學習一門新的技術能夠幫到你。在過去的一年裡，我遇到很多朋友後台留言詢問學習某種技術的方法，尤其是 phoenix 在社區越來越火後，很多人尋思著放下手頭學到一半的 rails，django，來學 phoenix。對此，我發了篇文章 rails, django, phoenix，你們錯了來闡述為何 web framework 不該是你學習甚至開發產品的中心。借用「中學為體，西學為用」的概念，我覺得「思想為體，框架為用」，切不可本末倒置，迷失在框架的茫茫苦海中跳脫不開。

（四）

代碼寫得多了，要注意打造屬於你自己的樂高積木。這是老司機和新手最大的區別。為啥同一個功能，老司機三下五除二就能搞定？因為老司機寫代碼在搭積木，而新手手頭沒有積木，也找不到積木，只好不斷造輪子。

老人說：常在河邊走，哪能不濕鞋。作為文明時代為數不多的在刀鋒（blade）上行走的職業人，程序員繞不過去的一道坎是把系統搞崩潰。你刪除過 production database 沒？看看這篇文章：需要多麼強大的內心才能經受這一切，有則改之，無則加勉。

如果前一篇文章嚇到了你，我這備著幾碗熱騰騰，口味各異的雞湯為您雅靜：

old soldiers never die
那堵嘆息的牆壁
像經營企業一樣打造職業生涯：開播導言
用Lean Canvas 自我剖析（一）

嫌之前的文章太沉悶，技術犯太濃？來來來，咱們上完陽春白雪，上下里巴人：

程序員和拉條子
漫談工程師的三觀
春假，是每個爹的噩夢

對新產品感興趣的，2016 年您可要失望了，我總共也就寫了兩篇和新產品有關的文章：Hololens，愛之初體驗，pay as you go：當程序員盯上了車險。

（五）

2016 技術圈除了 ZeroMQ 作者的去世，對我而言還有件大事就是 rethinkdb 的亡故。我挺喜歡它的技術以及圍繞 rethinkdb 做的 horizon，還寫過一篇文章：後端傻瓜化？為其搖旗吶喊。可惜了。再一次，技術敗給了市場；理想主義的 geek 輸給了世俗。

年底前的 aws re:invent，我寫了三篇文章，都值得一讀：

AWS re:invent 2016：對面的序員看過來
AWS reinvent 2016：Primitives not framework
snowmobile 狂想曲

可惜時間關係，我沒空展開寫更多的內容。大家自己上 youtube 看視頻吧。

新一年了，有沒有跳槽的想法？談談系統設計的面試幫你梳理一下如何去應對系統設計的面試，向左走，向右走赤果果地為俺們 tubitv 做廣告招聘。偷偷地告訴你，我們今年又要開始在中國（北京）招募工程師了，nodejs 後端和 web 前端為主，懂 erlang / elixir / scala 優先，稍後我會發文詳述。

最後，老少咸宜，人見人愛的長日無痕系列：長日無痕（一），長日無痕（二），長日無痕（三）

新年快樂，謝謝讚賞！