爲何你應該嘗試全棧

　原文摘自http://kb.cnblogs.com/page/527518/?plg_nld=1&plg_uin=1&plg_auth=1&plg_nld=1&plg_usr=1&plg_vkey=1&plg_dev=1

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

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

　　我並不以爲全棧會使得你全面平庸，每種技術在作的時候均可覺得其餘的技術提供思路，而在你瞭解各類技術的前提下，深刻其中的某個技術，時常可以帶來對其餘技術的反哺。相反，瞭解的技術若是很是狹隘，極可能纔是限制本身潛能的緣由。

　　尊重與和平

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

　　不多見大神在一塊兒爭論誰該來讓步，相反每每都是初窺門徑的人成天吵個沒完，脾氣一點就爆。

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