angularjs全栈开发知乎_为什么你要去尝试全栈开发?
程序員看到"全棧"這個概念,大概會有兩種反應
1. 臥槽,這個好,碉堡了
2. 你懂毛,全棧就是樣樣稀松
以上兩種反應其實都有失偏頗。因為即使只學一門技術(shù),水平很菜的人也多的是,而全棧工程師當中樣樣都做,而樣樣都做得不錯的也不少。更別說這個世界還存在另外一種爆棧型的程序員,做什么,什么都精。
從我的個人實踐出發(fā),全棧學徒至少要掌握以下幾種技能:
Web 前端開發(fā),至少掌握一種前端框架;
Server 后端開發(fā),至少掌握一種后端框架;
Server 運維,掌握 Linux Server 的搭建與維護;
客戶端開發(fā),iOS 和 Android 至少掌握一種;
數(shù)據(jù)庫,掌握 SQL 和 noSQL 數(shù)據(jù)庫。
而獲得全棧這個稱謂則應該至少獨當一面的一個人完成一款產(chǎn)品的構(gòu)建,并且真的經(jīng)歷過商業(yè)化運作,以及,被自己的愚蠢坑過無數(shù)次。
由此可見,全棧的門檻還是挺高的,并不是說掌握以上五種技能,就能稱為全棧,至少要加個學徒來修飾一下,也正是因為太多學徒自詡?cè)珬?#xff0c;才令旁人覺得"全棧"就是"樣樣稀松"的同義詞。
不過,這篇文章的題目是 —— 為什么你應該嘗試全棧,所以我想討論的并不在要不要做全棧,而是嘗試。
外行與內(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è),每天的工作就是創(chuàng)造,所以這個職業(yè)看起來很酷。然而正因為如此,程序員多少都會有些自負,自負的結(jié)果就是以自己有限的知識去揣測別人的工作該怎么做。
如果 Server 端不懂客戶端,那么很容易設(shè)計出來不符合客戶端機制的 API。在這時候,做客戶端那邊的程序員耐心解釋,每個 API 耽誤一兩天的時間來磨合還可以,不好的話就要吵架了。
但 Server 端的程序員并不總是錯的,客戶端這邊希望所有數(shù)據(jù)給出來后不需要再加工,但往往按照客戶端需要的結(jié)構(gòu)給的話,有些查詢可能要耗時一兩秒。客戶端如果不理解服務端的機制,一味以 "服務端就是給客戶端服務的" 來要求,吵架就又難以避免了。
如果說技術(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)品。
那時候就琢磨,我應該先寫一個網(wǎng)頁版,然后再寫個客戶端。
所以從后端開始,我使用 Django 作為起步,不過很快我轉(zhuǎn)移到了 Rails 陣營,Rails 的敏捷開發(fā)極大的降低了開發(fā)成本,而其的約定習慣,也使得菜鳥能夠平安飛過很多危險區(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è)計前端才好用,怎么樣降低查詢時間,服務器緩存,redis,安全等等。
Rails 的自動化幫了不少忙,很多自己并不知道的地方它已經(jīng)幫忙做好,而當你想了解的時候,又會發(fā)現(xiàn)其實現(xiàn)是如此精妙。更別說 Rails 對新技術(shù)的接受程度,使得你總是有新東西可以玩,CoffeeScript 和 Sass 最早就是 Rails 吸收作為自己框架的默認前端技術(shù)。
為什么你應該嘗試“全棧”
隨后由 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ā)的項目上線后,隨著運維的復雜程度逐漸提升,也因此接觸了 chef 和 Ansible 這種自動化運維方式,再往后 NewRelic 這類的監(jiān)控服務也上了,而我為了一個穩(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 的學習變的非常輕松,成為了我晚上的休閑項目,或許不久之后,你會看到一款我做的游戲(可能會是 RPG)
我并不覺得全棧會使得你全面平庸,每種技術(shù)在做的時候都可以為其他的技術(shù)提供思路,而在你了解各種技術(shù)的前提下,深入其中的某個技術(shù),時常能夠帶來對其他技術(shù)的反哺。相反,了解的技術(shù)如果非常狹隘,很可能才是限制自己潛能的原因。
“小編是從事了十年Web前端開發(fā)的前端開發(fā)工程師,現(xiàn)在整理了一整套系統(tǒng)的Web前端學習教程從最基礎(chǔ)的到框架再到項目實戰(zhàn)的學習資料都有整理,送給每一位小伙伴, 有想學前端編程的,或是轉(zhuǎn)行,或是大學生,還有工作中想提升自己能力的,正在學習的小伙伴歡迎加入學習。“看我的個性簽名哦~~~
為什么你應該嘗試“全棧”
尊重與和平
在團隊溝通的時候,對對方技術(shù)的了解能減少非常多的溝通成本,并帶來尊重和和平。
很少見大神在一起爭論誰該來讓步,相反往往都是初窺門徑的人整天吵個沒完,脾氣一點就爆。
雖然很難講整個行業(yè)的水平能很快有質(zhì)的變化,但是我想如果產(chǎn)品需求能夠詳細的描述清楚,說清楚原因,技術(shù)人員之間能夠在一起相互學習,耐心的探討,設(shè)計師能夠尊重技術(shù)緯度的事情,設(shè)計出更符合當下的原型,那一切就會往者好的方向發(fā)展,這一切就從了解對方的工作開始。
總結(jié)
以上是生活随笔為你收集整理的angularjs全栈开发知乎_为什么你要去尝试全栈开发?的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: p沟道mos管导通条件_通俗易懂:MOS
- 下一篇: softmax函数_干货 | 浅谈 So