首發於微信公衆號《前端成長記》,寫於 2020.01.22html
PPT地址前端
內容源自做者上個月部門內部的分享,本文將圍繞着如下四個角色來聊:數據庫
京東數科CEO陳生強在杭州烏鎮互聯網大會上說道:產業數字化核心本就是去解決企業的效率問題。後端
所謂「工欲善其事,必先利其器」。有了一些開發工具的輔助,咱們能更高效地進行工做。微信
交互和前端合做起來有個最大的痛點,就是原型更新同步須要人力溝通,出錯率高,因此咱們能夠經過一下兩種方式來解決。數據庫設計
Axure Interactive Redline Tool工具
能夠類比 Sketch 中的 Measure 插件。主要優勢以下:佈局
基於 Nginx 搭建局域網一體化文檔平臺開發工具
交互同窗在本機搭建 Nginx 服務,配置好目錄後,每次生成文件導出到該指定目錄便可完成更新。前端同窗能夠經過 IP 完成局域網訪問。這樣均可以免更新傳遞過程致使的問題。測試
視覺和前端合做的時候,有時候會利用率不高,須要重複設計或者重複開發,因此爲了解決這個問題,一般會採用下面的方式。
設計元素庫 + 協同修改
在某種程度上統一設計規範,提供多套色系模版,以便快速生成對應的設計元素庫,再配合開發 Sketch 插件,便可作到實時協同。本質上也是解決的是協同的效率和準確性。
元素 -> 組件 -> 系統模版
有了元素庫之後,元素組合或者調整就能夠發佈成新的組件。組件組合加頁面約束就能夠生成系統,可以高效複用,快速完成類似度高的中後臺系統的搭建與開發。
這裏的頁面約束指的是邊距等一些基本設計約束定義。
GUI 工具
使用現有模版或者自行拖拽組合現有的組件,快速初始化對應項目UI及基本交互。這裏能夠參考阿里的飛冰。
Sketch 插件進行發佈維護
經過 Sketch 插件進行組件的發佈維護,將組件的維護權交給設計端,解決設計稿的還原度問題,解放前端花在 UI 上的時間。
這裏咱們有遇到這麼一個痛點:交互的初稿過程是帶有邏輯性的,若是給產品看原型的話可能不夠直觀,而且說服力不足。這裏咱們有一個解決方案以下:
原型 -> 頁面
經過原型導出成 Markdown 文件,而後針對該文件作解析,而後拿到結構自動生成帶導航內容的預覽頁面。
前端也總結了幾種方式來提升效率。
功能抽象,反饋交互和視覺
針對功能性需求,儘量將其進行抽象,反饋給交互和視覺拓展組件元素,提升複用性。
Git Hooks + ESlint
相似設計,約定一套代碼規範。在多人協做過程當中,經過 BeforeCommit 鉤子,自動進行代碼質量檢查,保障合做效率。
JSON + 組件 + 頁面約束
經過 JSON 配置來創建組件的引用關係,加上頁面閱讀便可快速高效地生成一些偏固化的流程頁。好比:實名認證、修改密碼、風險評估等。
協議平臺
之前的協議須要設計排版和前端製做,費時費力。經過將協議編譯成 HTML,加上基本的設計約束和設計樣式便可自動生成協議頁面,大大提升效率,節省了時間。
前端和後端最大的一個吐槽點就是接口文檔,格式良莠不齊,交付方式千奇百怪。
接口文檔平臺
先後端的接口溝通每每是最費時且容易出錯的。咱們經過代碼註釋,生成可維護可預覽的接口文檔,在線對比測試,下降了出錯率和溝通成本,同時也能夠接入 Mock 進行更爲完善的測試,節約測試資源。
網關平臺
讓後端只須要關心服務提供,前端只須要關心接口調用。中間的差別抹平交由網關層,同時也支持多接口調用,也能提升開發效率。
後端因爲只是略有涉獵,在這大膽作兩個設想。
GraphQl + 可行的數據庫設計
以前可能會出現需求微調,致使先後端都須要作字段更新等操做。引入 GraphQl 後,取什麼數據由前端來決定。接口服務與數據庫的連接能夠參考 Restful 風格設計,或者其餘可行的設計方式。
結合 GUI 工具快速完成簡單項目
能夠利用以前提到的 GUI 工具,經過拖拽實現自動佈局,快速生成無複雜交互的項目,如一些表單項目:EBS、保單填寫等。
咱們首先要作的事:
須要咱們長期作的事:
在業務相對趨於平穩的時期,提高各方面效率依然能夠持續地創造價值。
最後,一句話共勉:有你有我,將來可期。
以上是分享的所有內容,感謝!
(完)
本文爲原創文章,可能會更新知識點及修正錯誤,所以轉載請保留原出處,方便溯源,避免陳舊錯誤知識的誤導,同時有更好的閱讀體驗
若是能給您帶去些許幫助,歡迎 ⭐️star 或 ✏️ fork
(轉載請註明出處:https://chenjiahao.xyz)