想成為全棧工程師,你要做到哪幾點?
作為開發(fā)者,我們不過度區(qū)分服務(wù)端 server 客戶端 client,我們是 web developer,從事 web 開發(fā),多去理解技術(shù)和實踐落地。
成為全棧工程師的道路
成為全棧工程師說不上難也說不上容易,其中技術(shù)積累占了很大一部分:
緊跟前沿
掌握足夠多的輸入。
關(guān)注海外社區(qū)新消息發(fā)布,業(yè)界的新產(chǎn)品新技術(shù),學(xué)會高質(zhì)量的獲取信息,堅持做和習(xí)慣做。
注重學(xué)習(xí) & 不斷實踐
有屬于自己的思考和嚴(yán)謹(jǐn)?shù)漠a(chǎn)出。
掌握高效學(xué)習(xí)方法,比如我們最近在做 k8s 容器集群相關(guān)的事情,需要理解底層設(shè)計和做集群調(diào)度,需要學(xué)習(xí) Golang,新技術(shù)的學(xué)習(xí)過程:
- 投資一個好的 IDE,例如 Webstorm、Goland、IntelliJ IDEA 等,堅持使用。
- 認(rèn)準(zhǔn)官方文檔,堅持學(xué)習(xí)。
- API 手冊查看,不斷熟悉和記憶。
- 寫學(xué)習(xí)總結(jié),形成良性循環(huán):定義功能 -> 代碼設(shè)計 -> 完成功能 -> 重構(gòu)優(yōu)化 -> 優(yōu)化代碼設(shè)計 -> 完成 -> 重構(gòu) -> 完整掌握。
總結(jié):實踐貴在堅持,面對新的未知的領(lǐng)域,也要迎難而上。
重視基礎(chǔ)知識 & 多做總結(jié)
理解清楚,事半功倍。
例如作為 Web Developer:
- 必備知識:語言基礎(chǔ),Web 應(yīng)用的基礎(chǔ),熟悉 Linux 運行環(huán)境,網(wǎng)絡(luò)傳輸過程 HTTP 協(xié)議,TCP 協(xié)議。
- 進(jìn)階知識:熟悉瀏覽器請求過程,Web Server 端口監(jiān)聽原理,數(shù)據(jù)庫原理,瀏覽器請求原理,應(yīng)用程序安全通信 TLS 協(xié)議,數(shù)據(jù)加密解密方案,數(shù)據(jù)簽名方案。
- 架構(gòu)層面:應(yīng)用分層模式,數(shù)據(jù)模型定義模式,微服務(wù)劃分思路,系統(tǒng)設(shè)計模式。
作為無線團(tuán)隊:收益最大的和最值得投資的部分
把這些最常見的問題背后的原理理解清楚,就能獨立解決絕大多數(shù)問題,提升全鏈路研發(fā)效率,和各個崗位的人溝通無障礙,協(xié)作無阻力。
要做一件事情,出什么方案最合適,什么角色來做最適合,采用什么樣的技術(shù)架構(gòu)更合適:
- 語言是最基礎(chǔ)的:HTML/CSS/Javascript/ECMAScript/Typescript/Node.js/Golang/Java 等。
- 網(wǎng)絡(luò)協(xié)議層 HTTP 協(xié)議,DNS,7層/4層負(fù)載均衡,這里會涉及到服務(wù)端,前端,SRE,網(wǎng)絡(luò)安全等各個崗位的基礎(chǔ)知識。
- 框架層原理和細(xì)節(jié):應(yīng)用框架 React/Koa/Spring,數(shù)據(jù)庫框架,安全組件。
- 結(jié)合公司技術(shù)體系衍生的框架層約定和業(yè)務(wù)框架:阿里/螞蟻中間件。
- 工程化 :CI/CD 持續(xù)集成,自動化測試,代碼構(gòu)建發(fā)布過程。
- 基礎(chǔ)設(shè)施 IaaS:私有云、混合云、公有云。AWS、阿里云等。
對團(tuán)隊帶來的價值:
- 由于無線的特點:會遇到的問題 HTTP 協(xié)議相關(guān)的占比很大,端上的性能優(yōu)化,網(wǎng)路異常處理,前后端交互的基本過程。線下調(diào)試遇到時能快速定位和修復(fù),線上遇到問題時,能第一時間做出快速的決策。
- 不是所有問題都是靠經(jīng)驗可以彌補的,人在很多時候會重復(fù)犯錯,就怕遇到重復(fù)的問題還是找不到根因,所以需要從源頭上解決,還是要掌握全?;A(chǔ)知識。
總結(jié):
- 基礎(chǔ)知識理解清楚,在使用上層的技術(shù),例如各種框架和運維體系時,可以快速看到使用的技術(shù)背后的本質(zhì)是什么。
- 能減少犯錯幾率,做更多正確的決策。
全棧技術(shù)體系實踐
三人行必有我?guī)?,向身邊的人學(xué)習(xí)。
舉個我現(xiàn)實中身邊的人例子:在做登錄鑒權(quán)用戶體系,先把系統(tǒng)設(shè)計好,數(shù)據(jù)模型設(shè)計,接口設(shè)計,最后是實現(xiàn),最重要也有價值的部分是前期的設(shè)計階段。最后分別用 Node.js、Java、Golang 實現(xiàn)了一遍,不同語言和框架間的實現(xiàn)都是類似的,功能的移植非???,可以并行進(jìn)行。
而設(shè)計出好的代碼需要的先決條件,也是和前面的基礎(chǔ)部分的掌握完全匹配的,基礎(chǔ)越好,設(shè)計得也越好。
總結(jié):
- 優(yōu)秀的設(shè)計不僅做出的系統(tǒng)可靠,設(shè)計得也簡單清晰易懂。
- 寫的時候沒有負(fù)擔(dān),維護(hù)的時候也沒有高昂成本。
避免陷阱
全棧不代表降低要求,全棧是為了提升開發(fā)效率,如果質(zhì)量差,不好維護(hù),反而降低了團(tuán)隊效率。
- 避免只是多涉獵,而缺少實戰(zhàn),看過不等于會運用。
- 能寫全棧不代表寫出的代碼能上生產(chǎn)環(huán)境,避免給自己下意識地降低要求,寫出的代碼質(zhì)量不過關(guān)就違背了全棧的初衷。
成為全棧工程師的好處
掌握前后端服務(wù)端全鏈路知識體系和核心知識點
- 提高研發(fā)效率,提升解決問題能力,提高排查問題效率,可以快速偵破問題,及時處理問題。
能理解不同崗位的同學(xué)的訴求
- 后端同學(xué):能理解為什么前端同學(xué)會對接口字段提出很高要求,期望后端提供的接口按照開源社區(qū)的標(biāo)準(zhǔn)來定義(好的接口是自說明的,不用過多的文檔,遵循業(yè)界 API 設(shè)計規(guī)范,使用接口符合人的直覺,接口字段穩(wěn)定)。
- 前端同學(xué):能理解為什么后端同學(xué)不愿意輕易寫特殊邏輯判斷(一套模型已經(jīng)定義得很優(yōu)雅了,加個特殊分支就破壞了代碼的一致性)。
- 研發(fā)同學(xué):能理解為什么運維同學(xué)不愿意輕易給運維權(quán)限(底層運維一旦操作不當(dāng),做成的破壞力太大,需要深厚的技術(shù)積累)。
知識面不全面的反例
真實的反例:全棧有助于減少低級錯誤的出現(xiàn)。
這里的例子都是我曾經(jīng)參與解決過問題的,過程中我看到的是:這些都不是什么高深的問題,這些都是由于知識面不全面才發(fā)生問題:
- 應(yīng)用服務(wù)上線,服務(wù)器配置 nginx 代理線上 CDN,返回 502 了,開發(fā)和 SRE 一起排查下來是沒有開公網(wǎng)訪問權(quán)限(原因:應(yīng)用 owner 不熟悉網(wǎng)絡(luò)知識和運維體系,沒有和 SRE 打好配合)。
- 前端域名和后端域名不同,瀏覽器請求失敗,因為有跨域問題(原因:不熟悉 HTTP 協(xié)議中的 header 運用)。
- 后端接口名字設(shè)計有歧義,不規(guī)范,不滿足 RESTful API 規(guī)范(原因:不熟悉基于 HTTP 協(xié)議的規(guī)范,本質(zhì)上是 HTTP 的 中 method 的運用)。
- 其他例如 websocket 問題,前端性能優(yōu)化,緩存相關(guān)等問題排查效率低(原因:絕大多數(shù)跟不熟悉 HTTP header 有關(guān))。
最后
我始終覺得全棧不是認(rèn)證證書,不需要有人給你做認(rèn)證,當(dāng)你能獲得不同技術(shù)棧的同學(xué)的信任時,就是對你很大的肯定。