為什么你應(yīng)該嘗試全棧?

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

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

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

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

　　以上兩種反應(yīng)其實都有失偏頗，即使只做一種技術(shù)，做的很菜的多的是，而全棧但是樣樣都做的不錯的也不少，更別說這個世界還存在另外一種爆棧型的程序員，做什么什么精。

　　全棧學(xué)徒至少要掌握以下幾種技能：

1. Web 前端開發(fā)，至少掌握一種前端框架

2. Server 后端開發(fā)，至少掌握一種后端框架

3. Server 運維，掌握 Linux Server 的搭建與維護

4. 客戶端開發(fā)，iOS 和 Android 至少掌握一種

5. 數(shù)據(jù)庫，掌握 SQL 和 NoSQL 數(shù)據(jù)庫

　　而獲得“全?！边@個稱謂則應(yīng)該至少獨當(dāng)一面的一個人完成一款產(chǎn)品的構(gòu)建，并且真的經(jīng)歷過商業(yè)化運作，被自己的“愚蠢”坑過無數(shù)次。

　　由此可見，全棧的門檻還是挺高的，并不是說掌握以上五種技能，就能稱為全棧，至少要加個學(xué)徒來修飾一下，也正是因為太多學(xué)徒自詡?cè)珬?，才?dǎo)致第二種反應(yīng)如此廣泛。

　　不過，這篇文章的題目是 —— 為什么你應(yīng)該嘗試全棧，所以討論點并不在要不要做全棧，而是嘗試。

　　外行與內(nèi)行

　　過去幾年里，我和不少團隊的人聊過，發(fā)現(xiàn)絕大部分的團隊矛盾都在于——

• Server 端的不懂客戶端，設(shè)計出來個 API 后瞎 BB

• 設(shè)計師不懂客戶端，設(shè)計個交互瞎 BB

• 客戶端不懂 Server，對著 API 瞎 BB

• 客戶端不懂產(chǎn)品，對著需求瞎 BB

• 產(chǎn)品經(jīng)理不懂需求，對著 Team 瞎 BB

　　除了最后的產(chǎn)品經(jīng)理應(yīng)該被燒死以外，前四個矛盾都還是有救的。

　　程序員是一個上帝模式的職業(yè)，每天的工作就是創(chuàng)造，這也正是這個職業(yè)看起來很酷的原因。但是正因如此，程序員多少都會有些自負，自負的結(jié)果就是以自己有限的知識去揣測別人的工作該怎么做。

　　如果 Server 端不懂客戶端，那么很容易設(shè)計出來不符合客戶端機制的 API，以網(wǎng)頁的思維去理解客戶端，這時候好點的話做客戶端的耐心解釋，每個 API 耽誤一兩天的時間來磨合，不好的話就要吵架了。

　　但 Server 端并不總是錯的，客戶端希望所有數(shù)據(jù)給出來后不需要再加工，而往往按照客戶端需要的結(jié)構(gòu)給的話，有些查詢可能要耗時一兩秒。客戶端如果不理解服務(wù)端的機制，一味以 “服務(wù)端就是給客戶端服務(wù)的” 來要求，就又要吵架了。

　　如果說技術(shù)人之間的爭論是冷兵器戰(zhàn)爭的話，那如果碰到更外行的產(chǎn)品經(jīng)理或者老板，那就要爆發(fā)核戰(zhàn)爭了。

　　“你就改個網(wǎng)頁，十分鐘能搞定嗎？”

　　“效果怎么可能很難做，我給你做個”

　　“明天上線，趕緊的”

　　“我不管你技術(shù)上有什么難度，反正你就得給我實現(xiàn)出來”

　　而這樣的場景，無論是哪家公司，幾乎都在不停上演。

　　嘗試了解對方的技術(shù)

　　先聊聊我的技術(shù)軌跡吧，從初中開始使用 Linux，以 Ubuntu 作為自己主力系統(tǒng)，而后切換到 ArchLinux，再回到 Ubuntu，一直使用到大一，這幾年的 Linux 使用經(jīng)驗奠定了 Server 架構(gòu)的基礎(chǔ)，大一開始嘗試自己做一款產(chǎn)品。

　　那時候就琢磨，我應(yīng)該先寫一個網(wǎng)頁版，然后再寫個客戶端。

　　所以從后端開始，我使用 Django 作為起步，不過很快我轉(zhuǎn)移到了 Rails 陣營，Rails 的敏捷開發(fā)極大的降低了開發(fā)成本，而其的約定習(xí)慣，也使得菜鳥能夠平安飛過很多危險區(qū)域。

　　開始寫網(wǎng)頁前端的時候，并不知道有前端框架這個東西，直到用 Rails 寫完了后才發(fā)現(xiàn)原來有東西叫 Ember.js，于是開始用 Ember.js 來重寫，一開始的理解還是如何用 Rails 來渲染前端，后來發(fā)現(xiàn)其實在引入了前端框架后 Rails 的角色已經(jīng)變成了個 API Server 了。

　　于是由此開始從新的角度去考慮如何設(shè)計 Rails 的 API，閱讀了大量的 API 設(shè)計的資料，怎么樣設(shè)計前端才好用，怎么樣降低查詢時間，服務(wù)器緩存，redis，安全等等。

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

　　隨后由 Ember.js 又切換到 Angular.js，用 Angular 重寫一遍，期間又接觸了前端工具 Grunt （前端的變化一日千里，現(xiàn)在用的東西已經(jīng)不是這個了）

　　最后到了 iOS 客戶端，此時 iOS 的界面實現(xiàn)又與網(wǎng)頁的 HTML 和 CSS 有著很多不同，也因此又花費了不少時間去理解 iOS 的 UI 概念，把思維從網(wǎng)頁轉(zhuǎn)換成 iOS 的界面開發(fā)思想。

　　數(shù)據(jù)庫也在這個期間從 MySQL 換成了 MongoDB，因為那幾年的潮流也正好是這個轉(zhuǎn)變。

　　這個過程里幸好是我一個人，所以沒人可以吵架，不然我想各個階段都是有很多值得爭吵的地方。

　　項目上線后，隨著運維的復(fù)雜程度逐漸提升，也因此接觸了 chef 和 Ansible 這種自動化運維方式，再往后 NewRelic 這類的監(jiān)控服務(wù)也上了，為了一個穩(wěn)定的開發(fā)環(huán)境，繼而使用了 Vagrant。

　　而這一切都只發(fā)生在一年的時間里，不過很有趣的事情是，很多時候我寫著 iOS 突然想明白了 HTML 和 CSS 的實現(xiàn)原理，做著 Rails 突然想出了更好的 iOS 架構(gòu)方式，不同的技術(shù)之間觸類旁通的感覺在每天都發(fā)生著。

　　在后來的時間里，這段經(jīng)歷使得我和不同的技術(shù)人溝通都非常輕松，因為去年“秒視”做濾鏡的原因，我開始研究起 openGL，在重拾了Blender 之后，很多以前似懂非懂的地方，實現(xiàn)突然變的像 Hello World 一樣簡單，因此也干脆玩起 Unity 來，在這一切的積累之后，Unity 的學(xué)習(xí)變的非常輕松，成為了我晚上的休閑項目，或許不久之后，你會看到一款我做的游戲（可能會是 RPG）。

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

　　尊重與和平

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

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

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