為什麼你應該嘗試“全棧”

　　程式設計師看到“全棧”這個概念，大概會有兩種反應

　　1. 臥槽，這個好，碉堡了

　　2. 你懂毛，全棧就是樣樣稀鬆

　　以上兩種反應其實都有失偏頗。因為即使只學一門技術，水平很菜的人也多的是，而全棧工程師當中樣樣都做，而樣樣都做得不錯的也不少。更別說這個世界還存在另外一種爆棧型的程式設計師，做什麼，什麼都精。

　　從我的個人實踐出發，全棧學徒至少要掌握以下幾種技能：

1. Web 前端開發，至少掌握一種前端框架；
2. Server 後端開發，至少掌握一種後端框架；
3. Server 運維，掌握 Linux Server 的搭建與維護；
4. 客戶端開發，iOS 和 Android 至少掌握一種；
5. 資料庫，掌握 SQL 和 noSQL 資料庫。

　　而獲得全棧這個稱謂則應該至少獨當一面的一個人完成一款產品的構建，並且真的經歷過商業化運作，以及，被自己的愚蠢坑過無數次。

　　由此可見，全棧的門檻還是挺高的，並不是說掌握以上五種技能，就能稱為全棧，至少要加個學徒來修飾一下，也正是因為太多學徒自詡全棧，才令旁人覺得“全棧”就是“樣樣稀鬆”的同義詞。

　　不過，這篇文章的題目是 —— 為什麼你應該嘗試全棧，所以我想討論的並不在要不要做全棧，而是嘗試。

　　外行與內行

　　過去幾年裡，我和不少團隊聊過，發現絕大部分的團隊矛盾都在於——

• Server 端的不懂客戶端，設計出來個 API 後瞎 BB；
• 設計師不懂客戶端，設計個互動瞎 BB；
• 客戶端不懂 Server，對著 API 瞎 BB；
• 客戶端不懂產品，對著需求瞎 BB；
• 產品經理不懂需求，對著 Team 瞎 BB。

　　除了最後的產品經理應該被燒死以外，前四個矛盾都還是有救的。

　　程式設計師是一個上帝模式的職業，每天的工作就是創造，所以這個職業看起來很酷。然而正因為如此，程式設計師多少都會有些自負，自負的結果就是以自己有限的知識去揣測別人的工作該怎麼做。

　　如果 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，安全等等。

　　Rails 的自動化幫了不少忙，很多自己並不知道的地方它已經幫忙做好，而當你想了解的時候，又會發現其實現是如此精妙。更別說 Rails 對新技術的接受程度，使得你總是有新東西可以玩，CoffeeScript 和 Sass 最早就是 Rails 吸收作為自己框架的預設前端技術。

　　隨後由 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）。

　　我並不覺得全棧會使得你全面平庸，每種技術在做的時候都可以為其他的技術提供思路，而在你瞭解各種技術的前提下，深入其中的某個技術，時常能夠帶來對其他技術的反哺。相反，瞭解的技術如果非常狹隘，很可能才是限制自己潛能的原因。

　　尊重與和平

　　在團隊溝通的時候，對對方技術的瞭解能減少非常多的溝通成本，並帶來尊重和和平。

　　很少見大神在一起爭論誰該來讓步，相反往往都是初窺門徑的人整天吵個沒完，脾氣一點就爆。

　　雖然很難講整個行業的水平能很快有質的變化，但是我想如果產品需求能夠詳細的描述清楚，說清楚原因，技術人員之間能夠在一起相互學習，耐心的探討，設計師能夠尊重技術緯度的事情，設計出更符合當下的原型，那一切就會往者好的方向發展，這一切就從瞭解對方的工作開始。