程序員看到"全棧"這個概念，大概會有兩種反應(yīng)
1. 臥槽，這個好，碉堡了
2. 你懂毛，全棧就是樣樣稀松
以上兩種反應(yīng)其實都有失偏頗。因為即使只學(xué)一門技術(shù)，水平很菜的人也多的是，而全棧工程師當(dāng)中樣樣都做，而樣樣都做得不錯的也不少。更別說這個世界還存在另外一種爆棧型的程序員，做什么，什么都精。
從我的個人實踐出發(fā)，全棧學(xué)徒至少要掌握以下幾種技能：
Web 前端開發(fā)，至少掌握一種前端框架；
Server 后端開發(fā)，至少掌握一種后端框架；
Server 運維，掌握 Linux Server 的搭建與維護；
客戶端開發(fā)，iOS 和 Android 至少掌握一種；
數(shù)據(jù)庫，掌握 SQL 和 noSQL 數(shù)據(jù)庫。
而獲得全棧這個稱謂則應(yīng)該至少獨當(dāng)一面的一個人完成一款產(chǎn)品的構(gòu)建，并且真的經(jīng)歷過商業(yè)化運作，以及，被自己的愚蠢坑過無數(shù)次。
由此可見，全棧的門檻還是挺高的，并不是說掌握以上五種技能，就能稱為全棧，至少要加個學(xué)徒來修飾一下，也正是因為太多學(xué)徒自詡?cè)珬＃帕钆匀擞X得"全棧"就是"樣樣稀松"的同義詞。
不過，這篇文章的題目是 —— 為什么你應(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īng)該嘗試“全?！?/p>
程序員是一個上帝模式的職業(yè)，每天的工作就是創(chuàng)造，所以這個職業(yè)看起來很酷。然而正因為如此，程序員多少都會有些自負，自負的結(jié)果就是以自己有限的知識去揣測別人的工作該怎么做。
如果 Server 端不懂客戶端，那么很容易設(shè)計出來不符合客戶端機制的 API。在這時候，做客戶端那邊的程序員耐心解釋，每個 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，主力系統(tǒng)是 Ubuntu，而后切換到 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ù)。
為什么你應(yīng)該嘗試“全棧”
隨后由 Ember.js 又切換到 Angular.js，用 Angular 重寫一遍，期間又接觸了前端工具 Grunt （前端的變化一日千里，現(xiàn)在用的東西已經(jīng)不是這個了）。
最后我開始開發(fā) iOS 客戶端，此時 iOS 的界面實現(xiàn)又與網(wǎng)頁的 HTML 和 CSS 有著很多不同，所以我又花費了不少時間去理解 iOS 的 UI 概念，把思維從網(wǎng)頁轉(zhuǎn)換成 iOS 的界面開發(fā)思想。
數(shù)據(jù)庫也在這個期間從 MySQL 換成了 MongoDB，因為那幾年的潮流也正好是這個轉(zhuǎn)變。
在這個技術(shù)實操的過程里幸好是我一個人，所以沒人可以吵架，不然我想各個階段都是有很多值得爭吵的地方。
在我所開發(fā)的項目上線后，隨著運維的復(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ù)如果非常狹隘，很可能才是限制自己潛能的原因。
? ? ? ? ? ? ? “小編是從事了十年Web前端開發(fā)的前端開發(fā)工程師，現(xiàn)在整理了一整套系統(tǒng)的Web前端學(xué)習(xí)教程從最基礎(chǔ)的到框架再到項目實戰(zhàn)的學(xué)習(xí)資料都有整理，送給每一位小伙伴, 有想學(xué)前端編程的，或是轉(zhuǎn)行，或是大學(xué)生，還有工作中想提升自己能力的，正在學(xué)習(xí)的小伙伴歡迎加入學(xué)習(xí)?！?/p>
? ? ? ? ? ? ?加微?：qianduan899（領(lǐng)取）
為什么你應(yīng)該嘗試“全?！?/p>
尊重與和平
在團隊溝通的時候，對對方技術(shù)的了解能減少非常多的溝通成本，并帶來尊重和和平。
很少見大神在一起爭論誰該來讓步，相反往往都是初窺門徑的人整天吵個沒完，脾氣一點就爆。
雖然很難講整個行業(yè)的水平能很快有質(zhì)的變化，但是我想如果產(chǎn)品需求能夠詳細的描述清楚，說清楚原因，技術(shù)人員之間能夠在一起相互學(xué)習(xí)，耐心的探討，設(shè)計師能夠尊重技術(shù)緯度的事情，設(shè)計出更符合當(dāng)下的原型，那一切就會往者好的方向發(fā)展，這一切就從了解對方的工作開始。
