最近看了不少文章和帖子， 如文：
身邊和朋友圈也不少做前端開發的同事朋友問如何發展和提升 這裡我向大家給一些建議
紮實基礎
首先思考下手上的工作是否做得足夠好了，近幾年前端技術發展迅猛各種框架層出不窮，剛學會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 一起討論努力進階。