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