国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

微店前端工程化的迭代史

littlelightss / 2701人閱讀

摘要:文章同步在微店前端工程化起步于一個內部產品,對外我們有一個開源版本。這么長時間過去了,我們在前端工程化方面有了哪些變化遇到了哪些問題用怎樣的方案解決這些問題等等,值得為大家再分享。最終產品以命令行的形式發布。

文章同步在:https://github.com/hoperyy/bl...

微店前端工程化起步于一個內部產品 vbuilder,對外我們有一個開源版本 bio-cli。

去年我們也寫過一篇文章介紹該產品: bio: 一站式前端開發工具。

這么長時間過去了,我們在前端工程化方面有了哪些變化、遇到了哪些問題、用怎樣的方案解決這些問題等等,值得為大家再分享。

V0.0

這里也就是介紹下背景,為什么我們會開發 vbuilder。

總體思路就是:將重復性工作集成化。

當時,團隊面臨幾個問題:

重復:每個項目要新開一個腳手架(webpack / gulp 之類)

混雜:工程目錄既包含腳手架文件,也包含業務文件

混雜packge.json 中的依賴既有腳手架的依賴,也有業務依賴,難以區分

難更新:腳手架一旦確定,幾乎不再更新,如 webpack 1.0 的項目極有可能會一直維持在 webpack 1.0 狀態

協作:團隊協作中,項目的技術棧紛雜,不同人員維護同一個項目成本高昂,如:需重新理解對應工程配置等

總結為下圖:

基于以上問題,我們開始了 vbuilder 的研發。

最終產品以命令行的形式發布。

此時的 vbuilder 為 V0.0 狀態。

V1.0

vbuilder V1.0 提供了以下能力:

默認命令集:內置一套命令集,用于常見功能開發,包括 mock / update / help

靜默更新:用戶安裝一次命令即無需關注更新,其更新自行靜默完成

收斂腳手架:將工程內的腳手架配置隱藏,并統一管理,開發者可快速聚焦業務邏輯

開放接入腳手架:不限制技術棧類型(vue / react / angular / weex 等),開放接入不同技術棧

插件化:除內置命令集外,插件化擴展命令集,供團隊同學實現訂制邏輯

vbuilder 的不斷推進下,我們欣喜地看到,團隊發生了一些變化:

便捷:新項目一個命令即創建,直接開始業務開發

純粹:工程目錄只保留了業務文件,腳手架等工程配置被隱藏

更新:腳手架被收斂為統一管理,統一更新,盡可能應用最新的技術棧

協作:絕大部分項目協作的成本范圍收斂到 “業務邏輯”,剔除了 “工程配置邏輯”,協作成本大大降低

開放:在收斂腳手架配置的同時,開放性接入各類技術棧腳手架,如 weex / vms / 后臺管理 / serverside project

協作:團隊統一性的技術更新得以快速進行,不會再遇到因工程配置不同不斷適配的問題

總結為下圖:

V1.0 出現后,推進的很順利,在推進過程中秉持如下原則:

提效:幫助業務開發者節省時間

共擔:開發者參與生態建設(腳手架開發維護、插件開發),至少在績效上會得以加分

好用:使用方式簡單好用,才讓人有用的欲望

V1.0 基本解決了以下角色的痛點:

后端同學:內部系統開發場景被 100% 覆蓋

前端同學:絕大部分業務場景被覆蓋

腳手架開發者:強大的腳手架被開發好后,得以快速推廣

插件開發者:自定義命令,滿足個性化開發

V1.0 的問題

封閉性

高度定制化的工程配置需求實現難度增大

腳手架配置的主題被隱藏,雖然仍然開放給開發者一些配置性文件,對于高度定制化的配置需求而言依然杯水車薪。

此時,就必須新開一個腳手架,重新接入 vbuilder 體系。

在 “開放性” 來說,打了折扣。

插件開發的沖突

由于 vbuilder 是基于命令行開發,插件開發者擴展自定義命令式,依然是自定義命令行,團隊規模不斷擴大的狀態下,很容易出現不同插件使用同一個命令,被同時安裝的狀態下,重復執行該命令。

V2.0

V2.0 至少要解決 V1.0 存在的問題,同時需要有更明確的發展方向。

不過,V2.0 依然基于命令行。

V2.0 如何解決封閉性問題

V1.0 的思路是 “閉合”,雖然有一定的開放性,但仍然不夠。

V2.0 新增 “開放” 的能力,腳手架配置可以被隱藏,也可以隨時在需要的時候暴露在工程配置中,進行定制化開發。

當然,會遇到腳手架難以統一管理的問題,這一點仍然有辦法可以解決。

因為被暴露的工程配置是 vbuilder 提供的,vbuilder 得以方便地統計哪些項目使用了自定義的腳手架,將通用型工具包下發給該工程。

V2.0 如何解決插件開發的沖突

問題 1:插件間的沖突

舉個例子,有兩個插件中,都有一個命令 run。如果用戶安裝了這兩個插件,在執行 run 命令的時候,兩個插件的邏輯均會觸發。

在某些情況下,這不是用戶希望看到的場景,可能 TA 希望的只是運行插件 A 的命令 run

問題 2:插件命令集與內置命令的沖突

例如,內置命令集中有命令 init,而某個插件也有 init

那么在用戶執行 init 命令時,依然會執行兩遍邏輯。

怎樣解決?

我們組合使用了以下方案:

vbuilder 檢測是否有重復命令,如有,提示用戶是都運行、還是選擇運行某一個插件中的命令

為命令圈定生效條件

vbuilder 的命令行基于 commander。我們基于 commander 擴展了一些方法。

假如我們希望,插件中的命令 show 只在工程目錄中 xx.show 文件存在的情況下生效,那么代碼如下:

commander
.command("show [param]")
.effect(cwd  => fs.existsSync(path.join(cwd, "xx.show"))) ---- 這是我們擴展的命令
.description("我的自定義命令")
.action((param, options) => {
    console.log("my show");
});

為內置命令集聲明其為“內置命令”,插件命令可以阻止內置命令執行

假如插件中有個命令 init,而 vbuilder 內置命令中也有 init,我們希望插件中的 init 命令生效,內置命令不生效,該怎么做呢?

我們擴展了 commander 的 2 個方法:declareDefault 聲明內置命令、preventDefault 阻止內置命令執行。

定義內置命令時,代碼如下:

commander
.command("init [param]")
.declareDefault() --- 聲明內置命令
.description("內置的 init 命令")
.action((param, options) => {
    console.log("init inside");
});

開發插件命令時,代碼如下:

commander
.command("init [param]")
.preventDefault() --- 阻止內置命令執行
.description("內置的 init 命令")
.action((param, options) => {
    console.log("init inside");
});

Commander 的源碼只有 1000 行左右,邏輯還是很清晰的,擴展起來非常方便,這里不再列舉實現。

V2.0 的新功能

在命令行這個場景下,我們把 vbuilder 定義為公司內部開發的一個“水電煤”性質的基礎設施。

通過 vbuilder,我們新增了以下場景:

支持 chrome 插件 es6/7 化開發

支持組件庫快速開發

支持 js 工具庫快速開發

支持快速打開文檔庫等等

得益于插件化,通過充分調動開發者積極性,我們可以將其能力無限延展。

V3.0

我們目前還沒有進入 3.0 的開發,但有一些方向是我們可以嘗試的:

cloudIDE(內部已有該類平臺)

vscode 定制化 IDE,該類場景在超大型團隊比較適合,IDE 定制化開發有更多的應用場景,更快的開發效率

云化(其實不算新了,很多公司已經實現了云化)

這是目前我們在微店前端工程化領域的一些實踐和思考,希望對大家有幫助。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/106591.html

相關文章

  • serverless在微店node領域探索應用

    摘要:參與者流量來自于內部系統和外部流量,其中大部分來自于外部流量。水平擴容服務的水平擴容重要性不言而喻。 背景 目前微店中臺團隊為了滿足公司大部分產品、運營以及部分后端開發人員的嘗鮮和試錯的需求,提供了一套基于圖形化搭建的服務端接口交付方案,利用該方案及提供的系統可生成一副包含運行時環境定義可立即運行的工程代碼,最后,通過 某種serverless平臺 實現生成后代碼的部署、CI、運行、反...

    mikyou 評論0 收藏0
  • CI Weekly #8 | CI/CD 技能進階路線

    摘要:微店技術團隊公眾號容器化之路這是一套以阿里云為基礎,為核心,第三方服務為工具的開發測試部署流程,以及內部的代碼提交,版本管理規范。如何打造安全的容器云平臺對,微服務,來說都是非常好的落地實踐技術。 在使用 flow.ci 進行持續集成的過程中,也許你會遇到一些小麻煩。最近我們整理了一些常見問題在 flow.ci 文檔之 FAQ,希望對你有用。如果你遇到其他問題,也可以通過「在線消息」或...

    FuisonDesign 評論0 收藏0
  • bio: 一站式前端開發工具

    摘要:本文發表在微店前端團隊是什么注意目前只兼容平臺地址地址前端開發一站式解決方案。使用,您將只需關注業務邏輯,無需關注腳手架配置信息,即可快速完成前端開發。該命令會完成以下動作在本地安裝腳手架,以確保腳手架存在。 本文發表在 微店前端團隊 blog bio 是什么 注意:bio 目前只兼容 Mac 平臺 github 地址:bio-cli npm 地址:bio-cli 前端開發一站式解決方...

    vboy1010 評論0 收藏0
  • 3月份前端資源分享

    摘要:面試如何防騙一份優秀的前端開發工程師簡歷是怎么樣的作為,有哪些一般人我都告訴他,但是他都不聽的忠告如何面試前端工程師 更多資源請Star:https://github.com/maidishike... 文章轉自:https://github.com/jsfront/mo... 3月份前端資源分享 1. Javascript 使用judge.js做信息判斷 javascript...

    nanchen2251 評論0 收藏0

發表評論

0條評論

littlelightss

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<