為什么你應該嘗試全棧?

今日小節：　LANG=C sed -r "s/[\x81-\xFE][\x40-\xFE]//g" （去漢字）

程序員看到全棧這個概念，大概會有兩種反應：

　　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）。

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

　　尊重與和平

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

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

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