簡介：如何成為一名全堆疊工程師？需要具備哪些技識訓累？成為全堆疊工程師有哪些好處？希望本文能為期望成為全堆疊工程師的同學提供一點幫助，和同學們一起分享交流，
作為開發者，我們不過度區分服務端 server 客戶端 client，我們是 web developer，從事 web 開發，多去理解技術和實踐落地，
成為全堆疊工程師的道路
成為全堆疊工程師說不上難也說不上容易，其中技識訓累占了很大一部分：
緊跟前沿
掌握足夠多的輸入，
關注海外社區新訊息發布，業界的新產品新技術，學會高質量的獲取資訊，堅持做和習慣做，
注重學習 & 不斷實踐
有屬于自己的思考和嚴謹的產出，
掌握高效學習方法，比如我們最近在做 k8s 容器集群相關的事情，需要理解底層設計和做集群調度，需要學習 Golang，新技術的學習程序：
- 投資一個好的 IDE，例如 Webstorm、Goland、IntelliJ IDEA 等，堅持使用，
- 認準官方檔案，堅持學習，
- API 手冊查看，不斷熟悉和記憶，
- 寫學習總結，形成良性回圈：定義功能 -> 代碼設計 -> 完成功能 -> 重構優化 -> 優化代碼設計 -> 完成 -> 重構 -> 完整掌握，
總結：實踐貴在堅持，面對新的未知的領域，也要迎難而上，
重視基礎知識 & 多做總結
理解清楚，事半功倍，
例如作為 Web Developer：
- 必備知識：語言基礎，Web 應用的基礎，熟悉 Linux 運行環境，網路傳輸程序 HTTP 協議，TCP 協議，
- 進階知識：熟悉瀏覽器請求程序，Web Server 埠監聽原理，資料庫原理，瀏覽器請求原理，應用程式安全通信 TLS 協議，資料加密解密方案，資料簽名方案，
- 架構層面：應用分層模式，資料模型定義模式，微服務劃分思路，系統設計模式，
作為無線團隊：收益最大的和最值得投資的部分
把這些最常見的問題背后的原理理解清楚，就能獨立解決絕大多數問題，提升全鏈路研發效率，和各個崗位的人溝通無障礙，協作無阻力，
要做一件事情，出什么方案最合適，什么角色來做最適合，采用什么樣的技術架構更合適：
- 語言是最基礎的：HTML/CSS/Javascript/ECMAScript/Typescript/Node.js/Golang/Java 等，
- 網路協議層 HTTP 協議，DNS，7層/4層負載均衡，這里會涉及到服務端，前端，SRE，網路安全等各個崗位的基礎知識，
- 框架層原理和細節：應用框架 React/Koa/Spring，資料庫框架，安全組件，
- 結合公司技術體系衍生的框架層約定和業務框架：阿里/螞蟻中間件，
- 工程化 ：CI/CD 持續集成，自動化測驗，代碼構建發布程序，
- 基礎設施 IaaS：私有云、混合云、公有云，AWS、阿里云等，
對團隊帶來的價值：
- 由于無線的特點：會遇到的問題 HTTP 協議相關的占比很大，端上的性能優化，網路例外處理，前后端互動的基本程序，線下除錯遇到時能快速定位和修復，線上遇到問題時，能第一時間做出快速的決策，
- 不是所有問題都是靠經驗可以彌補的，人在很多時候會重復犯錯，就怕遇到重復的問題還是找不到根因，所以需要從源頭上解決，還是要掌握全堆疊基礎知識，
總結：
- 基礎知識理解清楚，在使用上層的技術，例如各種框架和運維體系時，可以快速看到使用的技術背后的本質是什么，
- 能減少犯錯幾率，做更多正確的決策，
全堆疊技術體系實踐
三人行必有我師，向身邊的人學習，
舉個我現實中身邊的人例子：在做登錄鑒權用戶體系，先把系統設計好，資料模型設計，介面設計，最后是實作，最重要也有價值的部分是前期的設計階段，最后分別用 Node.js、Java、Golang 實作了一遍，不同語言和框架間的實作都是類似的，功能的移植非常快，可以并行進行，
而設計出好的代碼需要的先決條件，也是和前面的基礎部分的掌握完全匹配的，基礎越好，設計得也越好，
總結：
- 優秀的設計不僅做出的系統可靠，設計得也簡單清晰易懂，
- 寫的時候沒有負擔，維護的時候也沒有高昂成本，
避免陷阱
全堆疊不代表降低要求，全堆疊是為了提升開發效率，如果質量差，不好維護，反而降低了團隊效率，
- 避免只是多涉獵，而缺少實戰，看過不等于會運用，
- 能寫全堆疊不代表寫出的代碼能上生產環境，避免給自己下意識地降低要求，寫出的代碼質量不過關就違背了全堆疊的初衷，
成為全堆疊工程師的好處
掌握前后端服務端全鏈路知識體系和核心知識點
- 提高研發效率，提升解決問題能力，提高排查問題效率，可以快速偵破問題，及時處理問題，
能理解不同崗位的同學的訴求
- 后端同學：能理解為什么前端同學會對介面欄位提出很高要求，期望后端提供的介面按照開源社區的標準來定義（好的介面是自說明的，不用過多的檔案，遵循業界 API 設計規范，使用介面符合人的直覺，介面欄位穩定），
- 前端同學：能理解為什么后端同學不愿意輕易寫特殊邏輯判斷（一套模型已經定義得很優雅了，加個特殊分支就破壞了代碼的一致性），
- 研發同學：能理解為什么運維同學不愿意輕易給運維權限（底層運維一旦操作不當，做成的破壞力太大，需要深厚的技識訓累），
知識面不全面的反例
真實的反例：全堆疊有助于減少低級錯誤的出現，
- 這里的例子都是我曾經參與解決過問題的，程序中我看到的是：這些都不是什么高深的問題，這些都是由于知識面不全面才發生問題：
- 應用服務上線，服務器配置 nginx 代理線上 CDN，回傳 502 了，開發和 SRE 一起排查下來是沒有開公網訪問權限（原因：應用 owner 不熟悉網路知識和運維體系，沒有和 SRE 打好配合），
- 前端域名和后端域名不同，瀏覽器請求失敗，因為有跨域問題（原因：不熟悉 HTTP 協議中的 header 運用），
- 后端介面名字設計有歧義，不規范，不滿足 RESTful API 規范（原因：不熟悉基于 HTTP 協議的規范，本質上是 HTTP 的 中 method 的運用），
- 其他例如 websocket 問題，前端性能優化，快取相關等問題排查效率低（原因：絕大多數跟不熟悉 HTTP header 有關），
最后
我始終覺得全堆疊不是認證證書，不需要有人給你做認證，當你能獲得不同技術堆疊的同學的信任時，就是對你最大的肯定，
原文鏈接：https://developer.aliyun.com/article/775697?
著作權宣告：本文內容由阿里云實名注冊用戶自發貢獻，著作權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任，具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》，如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻洗掉涉嫌侵權內容，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/176623.html
標籤：其他
上一篇：Pycharm下載安裝教程