6月安卓手機好評榜：魅族20 Pro蟬聯(lián)冠軍
性能榜和性價比榜之后，我們來看最后的安卓手機好評榜，數(shù)據(jù)來源安兔兔評測，收集時間2023年6月1日至6月30日，僅限國內(nèi)市場。第一名：魅族20 Pro好評率：95%5月份的時候魅族20 Pro就是
隨著業(yè)務的發(fā)展，組織規(guī)模的擴大，越來越多的企業(yè)開始意識到協(xié)作效率對于企業(yè)團隊的重要性，甚至是決定其在某個行業(yè)競爭中突圍的關鍵，是企業(yè)長久生存的根本。
得物效率工程運用產(chǎn)品、技術、數(shù)據(jù)等手段，全面提升公司的效率。在管理效率、協(xié)同效率、跨團隊溝通效率、產(chǎn)研協(xié)作效率、辦公效率等各方面持續(xù)探索，高效驅(qū)動公司發(fā)展。
上面提到，效率工程為提升企業(yè)協(xié)作效率而生，因此會面臨大量中后臺應用場景。
這些中后臺應用體現(xiàn)為「PC 站點、H5 站點、飛書應用、特定機器環(huán)境」等，面向所有內(nèi)部員工和部分外部用戶。
在面向多類型用戶和使用場景等條件下，效率工程技術產(chǎn)品在穩(wěn)定性、體驗、擴展性等方面面臨的挑戰(zhàn)非常多。
效率工程主要的業(yè)務形態(tài)是「PC 站點的大型中后臺應用」，此類應用的布局大多數(shù)是這樣的：
圖片
針對這類場景，有此類產(chǎn)品研發(fā)經(jīng)驗的同學，對其面對的問題也會比較熟悉：
a.個別底層依賴的升級是難以避免的，尤其是涉及穩(wěn)定性、可維護性、用戶體驗方面，在某個節(jié)點會爆發(fā)問題影響線上
經(jīng)過調(diào)研后，我們引入微應用來解決目前遇到的問題：
一個基于“monorepo & 微前端 & 基座與業(yè)務分離”的、包括“文檔 & 工具”的一套體系化降低研發(fā)成本和提升用戶體驗的技術產(chǎn)品。
這是面向得物效率工程業(yè)務場景下，我們對微應用的定義。
得物效率工程的學習平臺，是面向得物員工、勞務人員、鑒別師、客服等人群的大型中后臺應用，產(chǎn)品形態(tài)是 PC / H5 / 飛書應用等。是非常典型的適用于「微應用」推進的項目。
圖片
學習平臺原來是非 monorepo 結(jié)構(gòu)，只用一個 package.json 做依賴管理，底層依賴 antd 等的版本極難更新，很難享受到最新版本的快樂。
學習平臺 Layout 和各個頁面內(nèi)容部分代碼是強耦合的，Layout 中也有部分頁面的業(yè)務邏輯。
學習平臺的多個頁面對外投放是整體性投放，需要對 Layout 做特殊處理、權限特殊處理等方式處理后，才能開始投放，投放成本高，而且投放方案不通用。
根據(jù) SMART 原則，我們制定了如下目標（時間限制在 3 個月內(nèi)）：
1. 降低微應用化遷移成本，中大型應用的微應用化遷移耗時降低 30%
耗時降低計算公式：1 - (有 SOP 時微應用化遷移估時 / 無 SOP 時微應用化遷移估時)
2. 降低學習平臺維護成本，管理端和學員端公共依賴升級時的測試耗時降低 50%
耗時降低計算公式：1 - (微應用化后的測試估時 / 微應用化前的測試估時)
經(jīng)過以上分析，我們的推進方案在「輸出、里程碑、技術架構(gòu)、測試方案、效果預估」等方面進行了確認。
a.《效率前端微應用最佳實踐》文檔：幫助業(yè)務開發(fā)者可以在 0.5D 理解遷移所需的各類背景
b.「微應用遷移技術產(chǎn)品 monopower」：幫助業(yè)務開發(fā)者完成應用 monorepo 化過程 90% 的工作量
a.「在線巡檢能力和報告」：幫助 Leader 查看項目完成微應用遷移后，工程質(zhì)量是如何的，這里包括了一系列的指標
里程碑
圖片
如上圖，里程碑整體分為 2 個階段：
第一階段，通過業(yè)務的少量落地完成方案驗證，側(cè)重在驗證
第 1 步：以 1 個項目試點，跑通流程、輸出“最佳實踐（初版）”、輸出“遷移工具（初版）”，落地 1 ~ 2 個頁面
第 2 步：以 1 個項目驗證全套方案，輸出“最佳實踐（修正版）”、輸出“遷移工具（修正版）”，落地 3 ~ 10 個頁面
以 1 個項目完成全套方案，輸出“最佳實踐（完整版）”、輸出“遷移工具（完整版）”，落地該應用全部頁面
技術架構(gòu)
即最小知識原則，在 SOLID 設計原則中符合 「Single，單一職責；Open-Close：開閉原則」的思想。
我們在考慮微應用技術架構(gòu)所具備的特征時，更注重簡單、可靠、閉環(huán)，也就是迪米特法則。
簡單：輸出的技術產(chǎn)品和文檔，需要面向真正用戶，易于理解，使用門檻低
可靠性：業(yè)內(nèi)微前端產(chǎn)品（qiankun / wujie / micro-app / ...）對比，各自的優(yōu)缺點，是否滿足業(yè)務需求
閉環(huán)：當項目進行微應用化后，定時巡檢和告警會觸發(fā)運行，定期掃描工程質(zhì)量并通知到相關方
圖中綠色區(qū)域是需要開發(fā)的產(chǎn)品或文檔。
圖片
整體架構(gòu)包括以下核心模塊：
a.新增微應用倉庫
不在老倉庫進行微應用化改造，保證穩(wěn)定性。
b.monopower cli/server
i.一鍵改造非 monorepo 項目為 monorepo 項目
圖片
ii.掃描項目質(zhì)量，并輸出報告和告警
圖片
c.微應用遷移最佳實踐文檔
3. 一鍵 monorepo 化
比如，原工程中有 import utils from '@/utils'，新工程可能需要變?yōu)?import utils from '@monorepo/utils'
圖片
a.對原工程做依賴解析后，會生成包含依賴樹的 json 文件存儲在本地
b.基于 json 文件 和 monorepo 結(jié)構(gòu)規(guī)范，生成新的 monorepo 化的工程結(jié)構(gòu)
c.基于 json 文件和 monorepo 結(jié)構(gòu)規(guī)范，對新的 monorepo 化的工程中的引用路徑做修正
圖片
多次 monorepo 化
由于學習平臺的微應用化持續(xù)近 3 個月，期間會經(jīng)歷多次迭代。
比如 A/B/C 3 個頁面是待微應用化的頁面，用 3 個迭代分別對 A/B/C 3 個頁面進行微應用化。
那么，A 頁面上線后，假如第二個迭代，原倉庫依然需要對 A 頁面修改，就意味著，第二個迭代要同時上線 A/B 頁面。
為了減少回歸測試成本，我們用 monopower transfer 做了一個轉(zhuǎn)換后的 diff 展示，如果 A 頁面在兩次迭代被進行了兩次 transfer，且 diff 沒有變化，就不需要回歸測試。
測試方案
a. 以單個路由為粒度，每次全量切換該路由的流量到微應用版本 b. 以整個工程為粒度，按照人群/流量分布為維度，定向灰度到微應用版本
最終我們用第一個測試方案。原因如下：
a. 學習平臺是微應用推進的第一個驗證型項目，短時間內(nèi)全量完成改造的難度太大
b. 以單個路由為粒度，能夠逐步修復問題，驗證整體方案的可行性
使用第一個方案，在整個微應用落地過程中是比較順利的，平穩(wěn)地將近 40 個頁面逐批次切換到微應用模式。
這里也頻繁用到了「推進方案 -- 技術架構(gòu) -- 一鍵 monorepo 化」中提到的“多次 monorepo 化”，利用 monopower transfer 的 diff 結(jié)果，來減少回歸測試成本。
改造前：
圖片
改造后：
圖片
系統(tǒng)自檢：
圖片
i.安裝命令行 monopower
ii.在當前項目執(zhí)行 monopower transfer，執(zhí)行 monorepo 化
iii.逐個頁面測試
圖片
正向依賴分析：
比如入口文件 index.tsx，可以基于該入口文件做依賴樹的可視化分析
圖片
反向依賴分析：
用于分析某個文件被哪些文件引用，用于分析該文件的重要性等
圖片
定期巡檢，輸出巡檢報告，包括且不限于「工程化配置、代碼質(zhì)量、公共依賴引用、依賴收斂、穩(wěn)定性、性能、用戶體驗」等分析結(jié)果。
巡檢工具內(nèi)部，可以結(jié)合靜態(tài)文件掃描和運行時模擬，對當前項目做全方位掃描，當然側(cè)重在微應用方面的健康度。
上文中提到了「微應用」推進的目標，這里分開演示效果。
耗時降低計算公式：1 - (有 SOP 時微應用化遷移估時 / 無 SOP 時微應用化遷移估時)
改造前
圖片
用 monopower transfer 對學習平臺進行 monorepo 化改造：
圖片
圖片
改造后
圖片
耗時降低計算公式：1 - (微應用化后的測試估時 / 微應用化前的測試估時)
很顯然，這是利用了 monorepo 類工程的天然優(yōu)勢：依賴隔離。
圖片
學習平臺可以針對管理端和學員端做依賴隔離，從而可以單獨升級學員端、管理端業(yè)務的底層依賴。
上述推進方案確認后，剩下的就是根據(jù)各個里程碑完成對應進度即可，因此在推進過程中，沒有遇到「進度」方面的問題。
當然在推進途中，隨時會面臨實際的技術問題、人員調(diào)整、業(yè)務壓力等，除了保持足夠的心理準備外，在“技術調(diào)研”階段，為關鍵鏈路做好多個方案對比和意外狀況的預案尤為重要。
比如，在微前端選型中，社區(qū)中有諸多方案可選（iframe / qiankun / wujie / micro-app 等），在初期擬定某個微前端方案后，如果中途遇到難以解決的問題，就需要及時復盤、調(diào)整到備選方案。
備選方案也要做足功課，這是我們在推進微應用落地過程中的重要經(jīng)驗
Babel在實際應用中的劣勢
在上文介紹「推進方案 - 技術架構(gòu)- 一鍵 monorepo 化」時，我們提到了: 在對原工程做 monorepo 化時，需要對原工程進行“依賴解析”和“代碼引用路徑修正”。其中專門強調(diào)了「基于 AST 或正則」。
圖片
圖片
這部分其實是團隊管理和項目管理部分了，如果推進人是比較資深的同學是能很快地完成中大型項目的核心難點工作的，但也有不少同學有成長的意愿以及完成挑戰(zhàn)的能力。
那負責推進的同學，就要學會拆解、放手，讓有意愿有潛力的同學多多承擔重要工作，同時把控風險，保證項目的順利推進。
很榮幸，這個項目在推進的 3 個月內(nèi)，涌現(xiàn)了多位成長明顯的同學，在整個項目高質(zhì)量完成的結(jié)果上，貢獻了自己的力量，而且很多問題的發(fā)現(xiàn)、解決、通用化方案輸出是這些同學主動推動的。
值得思考的是，以效率前端微應用推進為例，成功推進一個中大型項目，需要具備怎樣的能力和工作方式？
下圖能力模型是我比較喜歡參考的：
圖片
基于這個能力模型，衍生出的比如：主動性、技術儲備、任務分解等各類能力都是可以納入這個模型參考的。
以下是上述能力模型在具體事務上的工作技巧實踐：
本文介紹的技術方案，是效率前端微應用推進的初期設計的，推進 3 個月以來，中途經(jīng)歷了各種各樣的困難，也有額外的技術小項被納入微應用推進方案，但整體的方向沒有大的變化。
除了技術方面，我有個心得：“推進的同學，需要有良好的心理素質(zhì)，并能為自己尋找資源”。
「Everything is under control」，我想這是設計技術方案的同學需要慢慢具備的心理素質(zhì)。
在推進過程中，你對遇到的困難是否有心理準備？比如技術方案被挑戰(zhàn)、研發(fā)體驗變化帶來的反彈、回滾難度是否都考慮過。“出現(xiàn)各類問題是很正常的”，是我在推進任何項目都有的心理準備。
在各方對推進項目價值沒有太大異議的前提下，推進的同學需要假設任何人包括 Leader 對你需要的幫助是完全不了解的，此時，你需要作為需求方向各個具備資源或者能夠調(diào)動資源的人尋求合理的幫助。
本文從背景出發(fā)，詳細介紹了效率前端微應用推進初期設定的技術方案。在推進的 3 個月中，除了完成上述工作外，有多個很重要的技術小項、人員陸續(xù)加入。
在下一階段，得物效率前端微應用的推進將重點關注業(yè)務微服務化能力的建設。
微服務化在后端領域已經(jīng)講了很久，在前端領域通常大家提到的是微前端，但本文中提到的「前端微服務化」更側(cè)重業(yè)務的多端投放能力。
比如，某個中后臺應用的報表能力很強，在其他平臺上，想接入這些報表的話，有幾個方式可以做：
后續(xù)要推進的即是第二個方案類似的方向，這是部分實現(xiàn)思路：
圖片
在業(yè)務場景中，如果能夠做到「布局 與 內(nèi)容」的松耦合，對于業(yè)務本身的多場景接入大有益處，這也是「微應用」推進面臨的一個深水區(qū)，值得重度投入，后續(xù)有不錯進展的話，我們會及時分享。
本文鏈接：http://www.rrqrq.com/showinfo-26-100-0.html得物效率前端微應用推進過程與思考
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 分享六款相見恨晚的PPT模版網(wǎng)站, 祝你做出精美的PPT!
下一篇： Flowable工作流引擎的科普與實踐
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號