最近看了不少文章和帖子, 如文:
身邊和朋友圈也不少做前端開發的同事朋友問如何發展和提升 這裡我向大家給一些建議
紮實基礎
首先思考下手上的工作是否做得足夠好了,近幾年前端技術發展迅猛各種框架層出不窮,剛學會jquery還沒用熟, angular 、vue 、react 已經滿大街了。
gulp 還沒明白怎麼回事、webpack 已開始遍地開花了。眼花繚亂的技術不知道從哪裡開始好。
如果你還被這些困擾的話,那請靜下來思考一下,技術的發展總是有規律的,學習也是有規律可循的,我的建議是,把共性和必要的技能先穩固下來,既不浪費時間,又能提高效率,如果這塊還麼穩固好、框架什麼少看幾種吧,先有一樣可用的就好。
對於加強基礎一個可行的方案是,從自己上手的工作開始、除了專注現學現用工作需要的框架技術外加強基礎的學習,如:
- 基本的邏輯(與、或、非)
- 運算操作(加減乘除 Math 下的各種函式)
- 字串處理 (什麼大小寫、編碼、裁剪什麼的)
- 時間處理 (日期的加減、對比、格式轉換等)
- 陣列、集合物件處理 可以瞭解學習一些基礎庫 如: lodash、moment 等、若時間有限可以看看示例有個印象回頭可以查詢,當然最好的方式是實踐練習。
發展全棧的正確姿勢
Javascript 生態鏈對於全棧有一些優勢,但全棧不是貼金的標籤,如果技能不夠硬,必然落得個 前端不強,後端不行 的尷尬局面。
那對於前端是不是不該發展後端呢?
回答當然是否定的,前端有目的、有計劃的發展後端技能,對於系統全域性觀、工作協作能力提升是非常有幫助的,另外切實讓老闆願意為你加工資是非常可能的。
那要如何才能是有目的、有計劃的發展後端技能呢?
首先認清後端技能出發點和關鍵點。
- 出發點: 是主動權和話語權(可能某個後端老是鄙視你,你要的東西,說這個沒辦法,那個不應該,造成了你工作很被動,效率不高,出錯了可能還先找你)。
- 關鍵點: 前後端介面 (如果你能清晰、標準、明確你要的介面,那麼一些都會明朗起來)。 所以我任務,前端切入後端應該從介面開始。
從標準介面開始,什麼樣的介面才是標準的呢?
OpenAPI Specification
這裡我為大家推薦 Swagger 標準介面 (目前有兩個標準 OAS 2.0 和 OAS 3.0)
Swagger 致力於介面的標準化,併為此提供了一系列的工具,方便大家對進口進行標準化。
有什麼好處呢
- 簡化工作流程 (Streamline Your Workflow)。
- 自由構建 (Restraint-Free Build)
- 開放/全球化的支援 (Open & Globally Supported)
我的理解是增強系統的健壯性、降低溝通成本、提高寫作效率,另外介面是系統的一種抽象可以更好的從巨集觀把握系統。
標準化的介面要如何實踐
這裡我安利下我的開源專案 typerx, typerx 是一個輕量註解式的全棧系統、你可以使用他快速的實踐介面標準的全棧開發。
- 建立介面前、我們仍舊還是要考慮介面模組的、模組化的設計能降低我們一次思考的複雜度。 在 typerx 中我們分了 core 模組和 cms 模組。
- 介面的建立從原型開始考慮、確定介面所需的模型 model, 這個模型我們稱之為 DTO(data transform object) 也就是介面的輸入輸出資料物件。 dto 的編寫示例
- 有了模型之後我們就可以確定需要哪些介面方法了,編寫介面的時候先不著急考慮介面的實現,我們只要先提供模型(可以建立一個按模型提供的資料mock)確保必要的介面規格描述就好, account 的介面定義 這裡我們通過直接編寫程式碼的方式來實現文件,這樣方便我們高效、可維護的介面文件(當然先完成文件再來生成程式碼也是可以的,不過程式碼能表述的永遠比文件能描述的多,所以應該是有一套能夠自動生成api 文件的程式碼來維護比較合適,過去也曾從文件開始,但文件的錯漏不方便驗證、而且文件維護資料模型是很累的一個事情無法動態關聯重構)。
- 按要求完成了介面定義之後,你只要輕鬆執行
npm run build
複製程式碼
你就擁有標準的介面文件描述檔案 swagger.json / swagger.yaml 了, 你可以使用 typerx 直接啟動服務端預覽介面 localhost:4700 或者放到線上編輯器上預覽 editor.swagger.io;
- 好了標準話的介面有了你可以保持這個接和後端的介面一致,這樣就可以和後端愉快的協作了,當然如果你喜歡,直接使用 typerx 實現自己真實的後端。
最後歡迎大家關注 typerx 一起討論努力進階。