大家好，早在我還是個學生的時候，就經(jīng)常聽到「全棧工程師」的稱號。那時候就覺得這個崗位一定很牛逼，前后端的技術(shù)都會，一定是程序員中的人上上。
后面慢慢也聽說過，全棧工程師實際上就是啥都會點，但啥都不精，就跟我們大學時代的那些專業(yè)一樣。
看起來好像博大精深，但是都只是略懂皮毛。那全棧是不是一個扯淡的事呢？
咱也不過多評論了，反正隨著工作年限的提高，最近我也逐漸接觸并承擔了一些關(guān)于全棧的開發(fā)工作，覺得這個方向還是挺有意思的。
感覺是，沒有程序員人上人這么夸張，但是需要掌握和涉獵的技術(shù)點也的確是挺多的。
這里總結(jié)幾個關(guān)于全棧工程師的特點：
一、大局觀更重要
既然是全棧了，當然前后端的技術(shù)都會懂點，不然怎樣一個人充當一個團隊呢。
但是也不要過于神化這個身份，畢竟還沒幾個人能夠說自己能夠精通前端或者后端技術(shù)的。
全棧工程師更傾向于是一個獨立開發(fā)者，不出意外的話能夠包攬一個小項目中的所有代碼成分。
包括前端的UI渲染、組建封裝、頁面布局、數(shù)據(jù)請求以及必要的邏輯處理，還有后端的接口封裝、數(shù)據(jù)庫設(shè)計、數(shù)據(jù)校驗、服務(wù)構(gòu)建以及架構(gòu)設(shè)計等模塊。
單從技術(shù)點上來說，的確是比單純的前端工程師或后端工程師要了解得更多更全面。
我們都知道，在大型項目的協(xié)作開發(fā)中，溝通聯(lián)調(diào)往往是最麻煩也是最累人的環(huán)節(jié)。
因為前后端同學會經(jīng)常性的只站在自己單端的立場和角度上去思考和規(guī)劃接口以及技術(shù)方案的制定，這樣就會導致方案缺乏整體的可行性。
所以相對來說，全棧工程師能夠省去許多在溝通協(xié)作上花費的精力和時間，自己就能夠進行全鏈路的分析和方案制定。
在這個層面上來說，全棧工程師所帶來的整體項目風險上的評估把控，以及技術(shù)方案上的精簡和融洽是單端工程師無法比擬的。
所以在我看來，全棧工程師所處的視角一定不是傾向于某一端的，而是需要擁有一個全局的視角。從用戶和技術(shù)人雙重身份出發(fā)，全鏈路的審視和評測整個項目的。
許多后端開發(fā)會覺得前端就是切切圖畫畫UI，請求數(shù)據(jù)渲染下圖表；很多前端也會覺得后端就是對數(shù)據(jù)庫的增刪改查，到處調(diào)接口拼湊下數(shù)據(jù)返回。這其實都是因為想法比較片面所造成的。
對于一個全棧工程師，更應(yīng)該能夠區(qū)分前后端的區(qū)別和所擅長的地方，在代碼構(gòu)建上能夠?qū)⑦壿嬤M行合理的劃分。
比如后端就不該無腦透傳，前端也不該做太多太重的數(shù)據(jù)處理的邏輯。在項目整體上避免頭重腳輕。
二、適合小而美的項目
上面也提到過，全棧工程師實際上相當于獨立開發(fā)者，相當于一個團隊。但是按照我的理解，一名全棧工程師其實并不適合去完成一個大型的項目。
全棧工程師由于技術(shù)全面，所以無論是在學習成本還是開發(fā)精力上，都是比單端工程師要高的。這就會導致大家的一種固有印象，“全棧就是雜而不精”。
雖然不能一棒子打死，一言以蔽之，但是至少還是能夠說明全棧在實際的大型項目開發(fā)中，大概率單端能力是比不上單端工程師的。
并且再加上由于人力成本和項目規(guī)劃上的考慮，全棧更適合的是那種小而美的項目。而不是分分鐘幾億日活的超級項目。
所以其實認識到這點之后，全棧能夠做的東西就很多了。在大廠中，全棧往往都不會參與巨無霸app主端的開發(fā)工作，更多是在做各種平臺建設(shè)以及效率工具的研發(fā)。
我們都知道大廠里內(nèi)卷現(xiàn)象嚴重，很多時候卷就卷在平臺建設(shè)上。
各種類型相似的平臺層出不窮，每個團隊想象向全部門甚至全公司推廣自己內(nèi)部的研發(fā)平臺，之后就是各種開源的操作，以提升影響力。
所以千萬不要小看了做平臺建設(shè)和效率工具研發(fā)的這群全棧。當然了，現(xiàn)在真正做平臺的也不只是全棧工程師了，只要會寫點代碼的都會來做平臺。
什么前后端客戶端測試測開，學點前端看下后端，一個個做的飛起。懂得都懂。
三、容易轉(zhuǎn)技術(shù)管理
我們都知道，一般技術(shù)人的一大出路就是做技術(shù)管理。其實這就是當領(lǐng)導了。
現(xiàn)在互聯(lián)網(wǎng)大廠里，特別是比較看重技術(shù)的公司，很多領(lǐng)導實際上都是技術(shù)出身轉(zhuǎn)的管理層。
這樣的方式的好處不言而喻，讓懂技術(shù)的人來帶技術(shù)團隊是最好不過的了。而一個稍微成熟點的技術(shù)團隊，都不會只有一種崗位的。
很多領(lǐng)導管理的都是包括前端后端測試測開等技術(shù)崗位的一個大團隊。
在這樣團隊中，對領(lǐng)導的技術(shù)視野以及技術(shù)廣度的要求是很高的。而一名全棧工程師，天生就有這樣的優(yōu)勢。
全棧從一開始，所處的視角就更為全面，從項目規(guī)劃到技術(shù)方案，從風險評估到排期交付，全棧工程師都擁有更靠近上帝的視角。
實際上就是偏領(lǐng)導的視角，這本質(zhì)上對技術(shù)管理的工作的工作來說是有幫助的。
再加上全棧工程師接觸的技術(shù)點更廣，在技術(shù)上更側(cè)重于廣度，實際上也是理解和協(xié)作不同領(lǐng)域技術(shù)人的基礎(chǔ)。
當然這只是從技術(shù)廣度上來說明全棧工程師擁有相對而言更全面的技術(shù)廣度和相對高的技術(shù)視野。并不意味著全棧更容易得到晉升或者當領(lǐng)導。
畢竟，作為一個技術(shù)管理最重要的還是領(lǐng)導力和管理能力。更多的時候還是需要時運和機會。
四、低代碼輕服務(wù)
上面也提到過，全棧更適合小而美的項目。在這樣的前提之下，誕生了許多能夠幫助全棧工程師快速搭建平臺產(chǎn)物的工具。
比如最常見的就是只需要拖拽組件就能夠快速進行頁面布局的前端工具，現(xiàn)在還有慢慢流行起來的可視化后臺管理配置系統(tǒng)。
這些本質(zhì)上都屬于低代碼甚至是無代碼工具，只需要掌握基本的前后端理論就能夠快速搭建簡易的平臺。
在程序員已經(jīng)成為勞動密集型的新型農(nóng)民工的時代背景下，這種低代碼平臺能夠很容易想象到它在tob端的用武之地。
除此之外，輕服務(wù)也是用來快速構(gòu)建平臺的有利工具?，F(xiàn)在互聯(lián)網(wǎng)大廠基本都離不開各種云服務(wù)，各家大廠也都在發(fā)力云服務(wù)器的研發(fā)的擴展。
因此基于各種成熟云服務(wù)器的輕服務(wù)也隨之流行。輕服務(wù)相比于傳統(tǒng)的后端框架，能夠提供開箱即用的開發(fā)體驗。
開發(fā)者無需考慮服務(wù)器和數(shù)據(jù)庫等基礎(chǔ)設(shè)施的搭建，更不用操心測試環(huán)境配置、數(shù)據(jù)備份和線上運維等一系列繁瑣之事，只需專注于產(chǎn)品開發(fā)本身。
其實輕服務(wù)本質(zhì)上就是相當于部署在云服務(wù)器上的容器，可以在容器中建立云函數(shù)云方法，甚至是云工程，開發(fā)者自身不需要關(guān)心后端各種環(huán)境的搭建。
當然這樣的方式更適用于輕量級的后端，像騰訊云和字節(jié)輕服務(wù)都是類似的所謂后端低代碼的實現(xiàn)方式。
所以對于全棧開發(fā)者而言，低代碼和輕服務(wù)在很大程度上能夠幫助快速便捷的搭建平臺。當然對于單端開發(fā)者而言也可以很輕易的上手構(gòu)建全棧項目。
全棧工程師其實也不是什么十分高大上的崗位，相比于單純的前端或后端工程師，擁有更為廣泛的技術(shù)視野和全局視角。而單端工程師在現(xiàn)在的技術(shù)環(huán)境下，也能夠很容易的去做全棧的工作。
所以全棧工程師的職業(yè)發(fā)展后期也需要保證技術(shù)廣度的前提下，專攻一個方向，提升某個技術(shù)方向的技術(shù)深度。這樣才能更長久。
就像我現(xiàn)在一樣，做業(yè)務(wù)需求或技術(shù)重構(gòu)都是用本職工作的技術(shù)棧，但是在參與研發(fā)工具和研發(fā)平臺的建設(shè)時，往往都是前端后端客戶端一手抓的。
Python、JS/TS、C/C++、Java、Go、Ruby各種語言都是哪樣順手用哪樣。
技術(shù)這種東西本身是不設(shè)限的，并且只要入了這行，就不可能說一直只寫某一種語言，或者只用某一個技術(shù)棧。
在不同場景，不同需求背景以及不同產(chǎn)品上，能夠選擇合適的語言，合適的框架，保持不斷的學習才是持續(xù)進階的基礎(chǔ)。
或許，每一個開發(fā)者都應(yīng)該，并且都可以是一個全棧工程師。
本文作者：業(yè)余碼農(nóng)，感謝分享
聯(lián)系客服
