程式設計師看到全棧這個概念，大概會有兩種反應：
1. 臥槽，這個好，碉堡了
2. 你懂毛，全棧就是樣樣稀鬆
以上兩種反應其實都有失偏頗，即使只做一種技術，做的很菜的多的是，而全棧但是樣樣都做的不錯的也不少，更別說這個世界還存在另外一種爆棧型的程式設計師，做什麼什麼精。
全棧學徒至少要掌握以下幾種技能：
web 前端開發，至少掌握一種前端框架
server 後端開發，至少掌握一種後端框架
server 運維，掌握 linux server 的搭建與維護
客戶端開發，ios 和 android 至少掌握一種
資料庫，掌握 sql 和 nosql 資料庫
而獲得「全棧」這個稱謂則應該至少獨當一面的乙個人完成一款產品的構建，並且真的經歷過商業化運作，被自己的「愚蠢」坑過無數次。
由此可見，全棧的門檻還是挺高的，並不是說掌握以上五種技能，就能稱為全棧，至少要加個學徒來修飾一下，也正是因為太多學徒自詡全棧，才導致第二種反應如此廣泛。
不過，這篇文章的題目是 —— 為什麼你應該嘗試全棧，所以討論點並不在要不要做全棧，而是嘗試。
過去幾年裡，我和不少團隊的人聊過，發現絕大部分的團隊矛盾都在於——
除了最後的產品經理應該被燒死以外，前四個矛盾都還是有救的。
程式設計師是乙個上帝模式的職業，每天的工作就是創造，這也正是這個職業看起來很酷的原因。但是正因如此，程式設計師多少都會有些自負，自負的結果就是以自己有限的知識去揣測別人的工作該怎麼做。
如果 server 端不懂客戶端，那麼很容易設計出來不符合客戶端機制的 api，以網頁的思維去理解客戶端，這時候好點的話做客戶端的耐心解釋，每個 api 耽誤一兩天的時間來磨合，不好的話就要吵架了。
但 server 端並不總是錯的，客戶端希望所有資料給出來後不需要再加工，而往往按照客戶端需要的結構給的話，有些查詢可能要耗時一兩秒。客戶端如果不理解服務端的機制，一味以 「服務端就是給客戶端服務的」 來要求，就又要吵架了。
如果說技術人之間的爭論是冷兵器戰爭的話，那如果碰到更外行的產品經理或者老闆，那就要爆發核戰爭了。
「你就改個網頁，十分鐘能搞定嗎？」
「效果怎麼可能很難做，我給你做個」
「明天上線，趕緊的」
「我不管你技術上有什麼難度，反正你就得給我實現出來」
而這樣的場景，無論是哪家公司，幾乎都在不停上演。
先聊聊我的技術軌跡吧，從初中開始使用 linux，以 ubuntu 作為自己主力系統，而後切換到 archlinux，再回到 ubuntu，一直使用到大一，這幾年的 linux 使用經驗奠定了 server 架構的基礎，大一開始嘗試自己做一款產品。
那時候就琢磨，我應該先寫乙個網頁版，然後再寫個客戶端。
所以從後端開始，我使用 django 作為起步，不過很快我轉移到了 rails 陣營，rails 的敏捷開發極大的降低了開發成本，而其的約定習慣，也使得菜鳥能夠平安飛過很多危險區域。
開始寫網頁前端的時候，並不知道有前端框架這個東西，直到用 rails 寫完了後才發現原來有東西叫 ember.js，於是開始用 ember.js 來重寫，一開始的理解還是如何用 rails 來渲染前端，後來發現其實在引入了前端框架後 rails 的角色已經變成了個 api server 了。
於是由此開始從新的角度去考慮如何設計 rails 的 api，閱讀了大量的 api 設計的資料，怎麼樣設計前端才好用，怎麼樣降低查詢時間，伺服器快取，redis，安全等等。
隨後由 ember.js 又切換到 angular.js，用 angular 重寫一遍，期間又接觸了前端工具 grunt （前端的變化一日千里，現在用的東西已經不是這個了）
最後到了 ios 客戶端，此時 ios 的介面實現又與網頁的 html 和 css 有著很多不同，也因此又花費了不少時間去理解 ios 的 ui 概念，把思維從網頁轉換成 ios 的介面開發思想。
資料庫也在這個期間從 mysql 換成了 mongodb，因為那幾年的潮流也正好是這個轉變。
這個過程裡幸好是我乙個人，所以沒人可以吵架，不然我想各個階段都是有很多值得爭吵的地方。
專案上線後，隨著運維的複雜程度逐漸提公升，也因此接觸了 chef 和 ansible 這種自動化運維方式，再往後 newrelic 這類的監控服務也上了，為了乙個穩定的開發環境，繼而使用了 vagrant。
而這一切都只發生在一年的時間裡，不過很有趣的事情是，很多時候我寫著 ios 突然想明白了 html 和 css 的實現原理，做著 rails 突然想出了更好的 ios 架構方式，不同的技術之間觸類旁通的感覺在每天都發生著。
在後來的時間裡，這段經歷使得我和不同的技術人溝通都非常輕鬆，因為去年「秒視」做濾鏡的原因，我開始研究起 opengl，在重拾了blender 之後，很多以前似懂非懂的地方，實現突然變的像 hello world 一樣簡單，因此也乾脆玩起 unity 來，在這一切的積累之後，unity 的學習變的非常輕鬆，成為了我晚上的休閒專案，或許不久之後，你會看到一款我做的遊戲（可能會是 rpg）。
我並不覺得全棧會使得你全面平庸，每種技術在做的時候都可以為其他的技術提供思路，而在你了解各種技術的前提下，深入其中的某個技術，時常能夠帶來對其他技術的反哺。相反，了解的技術如果非常狹隘，很可能才是限制自己潛能的原因。
在團隊溝通的時候，對對方技術的了解能減少非常多的溝通成本，並帶來尊重和和平。
很少見大神在一起爭論誰該來讓步，相反往往都是初窺門徑的人整天吵個沒完，脾氣一點就爆。
雖然很難講整個行業的水平能很快有質的變化，但是我想如果產品需求能夠詳細的描述清楚，說清楚原因，技術人員之間能夠在一起相互學習，耐心的**，設計師能夠尊重技術緯度的事情，設計出更符合當下的原型，那一切就會往者好的方向發展，這一切就從了解對方的工作開始。
為什麼你應該嘗試「全棧」
程式設計師看到 全棧 這個概念，大概會有兩種反應 1.臥槽，這個好，碉堡了 2.你懂毛，全棧就是樣樣稀鬆 以上兩種反應其實都有失偏頗。因為即使只學一門技術，水平很菜的人也多的是，而全棧工程師當中樣樣都做，而樣樣都做得不錯的也不少。更別說這個世界還存在另外一種爆棧型的程式設計師，做什麼，什麼都精。從我...
為什麼你應該嘗試「全棧」
程式設計師看到 全棧 這個概念，大概會有兩種反應 1.臥槽，這個好，碉堡了 2.你懂毛，全棧就是樣樣稀鬆 以上兩種反應其實都有失偏頗。因為即使只學一門技術，水平很菜的人也多的是，而全棧工程師當中樣樣都做，而樣樣都做得不錯的也不少。更別說這個世界還存在另外一種爆棧型的程式設計師，做什麼，什麼都精。從我...
譯 為什麼你應該關注 Docker
注 該文原文為 why you should care about docker 由 chris dawson 編寫。當我在 dockercon 上陶醉於那些令人激動地議題時，我想到了乙個問題 我該如何向在波特蘭家中的妻子去解釋 docker 呢？我的妻子這時正在照料我們只有18個月大的生病的孩子。...