【移動(dòng)應(yīng)用開發(fā)技術(shù)】為什么你應(yīng)該嘗試全棧

【移動(dòng)應(yīng)用開發(fā)技術(shù)】為什么你應(yīng)該嘗試全棧

今日小節(jié)：LANG=Csed-r"s/[\x81-\xFE][\x40-\xFE]//g"（去漢字）程序員看到全棧這個(gè)概念，大概會(huì)有兩種反應(yīng)：1.臥槽，這個(gè)好，碉堡了2.你懂毛，全棧就是樣樣稀松以上兩種反應(yīng)其實(shí)都有失偏頗，即使只做一種技術(shù)，做的很菜的多的是，而全棧但是樣樣都做的不錯(cuò)的也不少，更別說這個(gè)世界還存在另外一種爆棧型的程序員，做什么什么精。全棧學(xué)徒至少要掌握以下幾種技能：Web前端開發(fā)，至少掌握一種前端框架Server后端開發(fā)，至少掌握一種后端框架Server運(yùn)維，掌握LinuxServer的搭建與維護(hù)客戶端開發(fā)，iOS和Android至少掌握一種數(shù)據(jù)庫(kù)，掌握SQL和NoSQL數(shù)據(jù)庫(kù)而獲得“全?！边@個(gè)稱謂則應(yīng)該至少獨(dú)當(dāng)一面的一個(gè)人完成一款產(chǎn)品的構(gòu)建，并且真的經(jīng)歷過商業(yè)化運(yùn)作，被自己的“愚蠢”坑過無數(shù)次。由此可見，全棧的門檻還是挺高的，并不是說掌握以上五種技能，就能稱為全棧，至少要加個(gè)學(xué)徒來修飾一下，也正是因?yàn)樘鄬W(xué)徒自詡?cè)珬?，才?dǎo)致第二種反應(yīng)如此廣泛。不過，這篇文章的題目是——為什么你應(yīng)該嘗試全棧，所以討論點(diǎn)并不在要不要做全棧，而是嘗試。外行與內(nèi)行過去幾年里，我和不少團(tuán)隊(duì)的人聊過，發(fā)現(xiàn)絕大部分的團(tuán)隊(duì)矛盾都在于——Server端的不懂客戶端，設(shè)計(jì)出來個(gè)API后瞎BB設(shè)計(jì)師不懂客戶端，設(shè)計(jì)個(gè)交互瞎BB客戶端不懂Server，對(duì)著API瞎BB客戶端不懂產(chǎn)品，對(duì)著需求瞎BB產(chǎn)品經(jīng)理不懂需求，對(duì)著Team瞎BB除了最后的產(chǎn)品經(jīng)理應(yīng)該被燒死以外，前四個(gè)矛盾都還是有救的。程序員是一個(gè)上帝模式的職業(yè)，每天的工作就是創(chuàng)造，這也正是這個(gè)職業(yè)看起來很酷的原因。但是正因如此，程序員多少都會(huì)有些自負(fù)，自負(fù)的結(jié)果就是以自己有限的知識(shí)去揣測(cè)別人的工作該怎么做。如果Server端不懂客戶端，那么很容易設(shè)計(jì)出來不符合客戶端機(jī)制的API，以網(wǎng)頁(yè)的思維去理解客戶端，這時(shí)候好點(diǎn)的話做客戶端的耐心解釋，每個(gè)API耽誤一兩天的時(shí)間來磨合，不好的話就要吵架了。但Server端并不總是錯(cuò)的，客戶端希望所有數(shù)據(jù)給出來后不需要再加工，而往往按照客戶端需要的結(jié)構(gòu)給的話，有些查詢可能要耗時(shí)一兩秒?？蛻舳巳绻焕斫夥?wù)端的機(jī)制，一味以“服務(wù)端就是給客戶端服務(wù)的”來要求，就又要吵架了。如果說技術(shù)人之間的爭(zhēng)論是冷兵器戰(zhàn)爭(zhēng)的話，那如果碰到更外行的產(chǎn)品經(jīng)理或者老板，那就要爆發(fā)核戰(zhàn)爭(zhēng)了。“你就改個(gè)網(wǎng)頁(yè)，十分鐘能搞定嗎？”“效果怎么可能很難做，我給你做個(gè)”“明天上線，趕緊的”“我不管你技術(shù)上有什么難度，反正你就得給我實(shí)現(xiàn)出來”而這樣的場(chǎng)景，無論是哪家公司，幾乎都在不停上演。嘗試了解對(duì)方的技術(shù)先聊聊我的技術(shù)軌跡吧，從初中開始使用Linux，以Ubuntu作為自己主力系統(tǒng)，而后切換到ArchLinux，再回到Ubuntu，一直使用到大一，這幾年的Linux使用經(jīng)驗(yàn)奠定了Server架構(gòu)的基礎(chǔ)，大一開始嘗試自己做一款產(chǎn)品。那時(shí)候就琢磨，我應(yīng)該先寫一個(gè)網(wǎng)頁(yè)版，然后再寫個(gè)客戶端。所以從后端開始，我使用Django作為起步，不過很快我轉(zhuǎn)移到了Rails陣營(yíng)，Rails的敏捷開發(fā)極大的降低了開發(fā)成本，而其的約定習(xí)慣，也使得菜鳥能夠平安飛過很多危險(xiǎn)區(qū)域。開始寫網(wǎng)頁(yè)前端的時(shí)候，并不知道有前端框架這個(gè)東西，直到用Rails寫完了后才發(fā)現(xiàn)原來有東西叫Ember.js，于是開始用Ember.js來重寫，一開始的理解還是如何用Rails來渲染前端，后來發(fā)現(xiàn)其實(shí)在引入了前端框架后Rails的角色已經(jīng)變成了個(gè)APIServer了。于是由此開始從新的角度去考慮如何設(shè)計(jì)Rails的API，閱讀了大量的API設(shè)計(jì)的資料，怎么樣設(shè)計(jì)前端才好用，怎么樣降低查詢時(shí)間，服務(wù)器緩存，redis，安全等等。Rails的自動(dòng)化幫了不少忙，很多自己并不知道的地方它已經(jīng)幫忙做好，而當(dāng)你想了解的時(shí)候，又會(huì)發(fā)現(xiàn)其實(shí)現(xiàn)是如此精妙。更別說Rails對(duì)新技術(shù)的接受程度，使得你總是有新東西可以玩，CoffeeScript和Sass最早就是Rails吸收作為自己框架的默認(rèn)前端技術(shù)。。隨后由Ember.js又切換到Angular.js，用Angular重寫一遍，期間又接觸了前端工具Grunt（前端的變化一日千里，現(xiàn)在用的東西已經(jīng)不是這個(gè)了）最后到了iOS客戶端，此時(shí)iOS的界面實(shí)現(xiàn)又與網(wǎng)頁(yè)的HTML和CSS有著很多不同，也因此又花費(fèi)了不少時(shí)間去理解iOS的UI概念，把思維從網(wǎng)頁(yè)轉(zhuǎn)換成iOS的界面開發(fā)思想。數(shù)據(jù)庫(kù)也在這個(gè)期間從MySQL換成了MongoDB，因?yàn)槟菐啄甑某绷饕舱檬沁@個(gè)轉(zhuǎn)變。這個(gè)過程里幸好是我一個(gè)人，所以沒人可以吵架，不然我想各個(gè)階段都是有很多值得爭(zhēng)吵的地方。項(xiàng)目上線后，隨著運(yùn)維的復(fù)雜程度逐漸提升，也因此接觸了chef和Ansible這種自動(dòng)化運(yùn)維方式，再往后NewRelic這類的監(jiān)控服務(wù)也上了，為了一個(gè)穩(wěn)定的開發(fā)環(huán)境，繼而使用了Vagrant。而這一切都只發(fā)生在一年的時(shí)間里，不過很有趣的事情是，很多時(shí)候我寫著iOS突然想明白了HTML和CSS的實(shí)現(xiàn)原理，做著Rails突然想出了更好的iOS架構(gòu)方式，不同的技術(shù)之間觸類旁通的感覺在每天都發(fā)生著。在后來的時(shí)間里，這段經(jīng)歷使得我和不同的技術(shù)人溝通都非常輕松，因?yàn)槿ツ辍懊胍暋弊鰹V鏡的原因，我開始研究起openGL，在重拾了Blender之后，很多以前似懂非懂的地方，實(shí)現(xiàn)突然變的像HelloWorld一樣簡(jiǎn)單，因此也干脆玩起Unity來，在這一切的積累之后，Unity的學(xué)習(xí)變的非常輕松，成為了我晚上的休閑項(xiàng)目，或許不久之后，你會(huì)看到一款我做的游戲（可能會(huì)是RPG）。我并不覺得全棧會(huì)使得你全面平庸，每種技術(shù)在做的時(shí)候都可以為其他的技術(shù)提供思路，而在你了解各種技術(shù)的前提下，深入其中的某個(gè)技術(shù)，時(shí)常能夠帶來對(duì)其他技術(shù)的反哺。相反，了解的技術(shù)如果非常狹隘，很可能才是限制自己潛能的原因。尊重與和平在團(tuán)隊(duì)溝通的時(shí)候，對(duì)對(duì)方技術(shù)的了解能減少非常多的溝通成本，并帶來尊重和和平。很少見大神在一起爭(zhēng)論誰(shuí)該來讓步，相反往往都是初窺門徑的人