街口第一代低碼系統 「超管」上線 — 改革流程心得篇
本文會注重在推行新架構和流程上所遇到的管理和執行問題，以及其背後的解決方案，關於低碼系統和微前端技術相關文章請鎖定我們頻道，不久後會推出相關文章。
以下內容是描述如何一步步導入微前端和低碼開發的關鍵流程。
什麼是超管？
SuperAdmin 以下簡稱 超管，是集合低碼架構的微前端中後台。super-admin只是一開始我對這個系統最直觀的詮釋，它就是所有後台系統的「後台」，最後久而久之，也懶惰想名字，所以就一直沿用。
為什麼要做超管？
一個目標，降低成本。
不管是維運、建立、溝通、迭代，後台系統作為業務平日維運的工具，本身的目的就是降低直接和工程師的溝通成本，透過系統更有效的達成操作人員的業務目標，
第一個問題，系統從何來？
按照我們的正常思路，應該是透過以下的流程。
以上都只是簡化過的流程，但可以從這個流程圖上不難發現，即便再簡單的一個功能，都必須跑完一個「正常」的開發流程，從體需求到上線，快則一個月，慢則半年，好不容易上線了，交接斷層或升級又是另外一個工程問題，說好的便利和自動化呢？
為了解決這些問題，超管歷經了好幾個階段。
超管的發展階段
階段一
打散再組合 不知為知之
在這個階段，我們主要是焦點在部門內的效率和管理問題
- 目標 ：降低開發風，增加開發效率
- 現況：既有已經有多個後台系統，而且後台是一個長期維護，持續開發的平台。
— 久而久之，系統的複雜性高，每次新增功能都是一個挑戰。
— 不斷重構的同時必須要確保其他不被影響。 - 實現 : 使用微前端重新設計一個後台系統，把每一次新作的系統，都獨立添加和上線。
- 驗收 : 新後台運作穩定 、開發流程不改變/影響/既有流程太多（其他合作方無感知為佳）
階段一我們先實驗一個小系統開始，從實驗結果我們得知，這種開發方式不但效率高，而且大大降低測試和錯誤的風險。（詳情查看《使用微前端，快速響應業務需求》一文）
缺點就是這套系統需要一定的知識基礎才能正常操作，雖然大部分新同事都可以在一週內快速上手，除了微前端的domain know-how以外，開發工作則和一般SPA無異，基本上沒有門檻。
微前端架構的本質上是 Principle of Least Knowledge 另外一種體現，正如沒有一個人能真正理解這個後台系統的全部功能。
他們也不需要知道，甚至連權限、路由、都不需要怕衝突，只要依照一般SPA網頁開發流程，任何工程師都可以快速開發完成一個後台系統。
所以在這個階段，我們不可能做到盡善盡美，所以把改動幅度極可能的降低其他團隊和合作時無感，減少不必要的流程變動，以免帶來團隊不適，僅對內部開發指定規則（而這些規則，都必須在日後的改善流程中消除）
一個新手要學習開發一個微前端後台需要學習以下全部規則。
看起來很多，但藍色的部分大部分都是常見工具，很快就上手，紫色的區塊是為了配合公司的部署機制而訂的規則，而特別設計這些規則是有原因的。
階段二
抽象需求 需求抽象
在這個階段，我們的主要焦點是在協助其他協作方，將流程帶入標準化。
- 目標
— 對外統整需求；對內規劃和定義流 - 現況
— 每個專案的PM不同，需求文件和內容都有些差異
— 大量客製化的需求導致系統容易出現過度設計
— 實踐需求的RD不理解其他專案的執行方式 - 實現
— 製作產生器；收斂需求；將部分設定轉為 remote config - 驗收
— 產生器效率不佳
— 需求無法收斂
— 權限設定無法和既有系統串接
— 交接和持續開發出現困難
我們試圖尋找一個方式，讓需求進入時能更快被分析和理解，讓PM更可以集中在業務需求上，也同時減少測試資源的消耗，但我們發現，即便是「搜尋」這個功能，在不同的人處理時，也可能出現不同的呈現和交互體驗，同樣的情形也反應在其他模組上。
在這裏我們做過好幾種嘗試，但成效不佳，我們檢討後，得出以下結論：
- 後台需求各異，根本無法統一
- 工程師做了後台UI的範本，但太陽春，根本無法的反應出實際需求。
- 我們做了模板產生器，但推行不易，實用性也不大（理由同上），和實際需求落差太大。
解決方案一：模板可否解決？
可以，除非你的模板庫的量足夠大，足夠豐富（那誰來豐富模板呢？）
確實，我們從實作的工程師得到的回饋是：
「需求需要大量的客製化，模板基本上只能是一個基礎結構」
在大部分時候，故事到這裡，就結束了。
只要我們稍微理解業務，就會理解，業務的客製化並非刻意而為之，甚至大部分時候，需求只講求目的和易用性，實際上如何操作，是並沒有多大的限制。
解決方案二：UI模組化可否解決？
然而，一開始工程師的思路，並非如此，我們是想說，假設模板太固化，需要很多客製化，那我們把全部變成小單元呢？！
當客製化需求太多，只會增加模組的數量和維護成本，甚至大部分模組可能出現，只用過一次，就再也沒有用過的情況。
說到底，需求是如此抽象，我們又做不到抽象需求，看起來就是一個死迴旋，短期成本最低的作法，就是全部都照單全收，一律客製化。
事實上，這樣做的維護成本是累加的，時間越久，維護的人力和時間就必須越多。
階段三
最終解 平台化
— 從起點開始，我們要做一些不一樣的事。
階段三就是進行中的階段，我們把管理微前端的能力轉成GUI，同時也把建構畫面和部署的能力轉為視覺建構和系統。
在開始前，我們必須先要釐清「需求」是什麼，也就是第二階段我們沒有做好的事，才能決定我們需要做怎麼的平台。
此階段也是阻力最大的一個階段，實作這種系統的前期投入非常大，也非常困難，但後期收益會很顯著。
本篇心得不細說每一個步驟的技術難點，就在執行上遇到的難處就有:
- 盡量減少設定（通用建構器的毛病）同時，保持最大彈性。
- 盡可能完成全部需求，可持續擴充
- 如何轉化既有需求為平台功能
- 如何轉移全部既有的專案到平台
- …
其中，經過好幾個工程師來實作這個平台，遇到的第一個難題。
如何讓需求抽離？他們的功能都不同，TLDR，就舉上面汽車的 🌰
需求很多時候會自帶說明範例和設計，只是為了更好的表達他們的需求，而非確實就要那樣，所以我們可以換一個溝通的方式。
且慢，這不是一個客製化嗎？
是，也不是。
我們剛剛說過，最後的成品是怎樣，應該是有非常好的商討空間的，維運後台更專注在結果和產出。所以我們需要做幾件事，來確定需求。
- 第一步：從過往的專案30幾個後台系統中，篩選出性質相同的元件。
- 第二步：把這些元件再抽象出邏輯和UI（我們UI用Ant Design，所以可以大大省略了這個步驟的時間）
- 第三步：把專案的流程抽象出N個步驟
- 第四步：收集需求方的意見和期望效果
- 第五步：篩選出要做的模組後，再反推是否能達到舊有功能的效果。
- 第六步：反覆驗證第五步，收斂到完全符合為止。
做完以上的步驟，我們就成功踏出一小步咯。
經過分析後，我們把所有的元件分為四個類別，分別是一般區塊（Presentational Component）、 資料操作、資料顯示、媒體，一共四種。
然後再從這四種分類去講元件歸納起來，得出只有7個元件，透過這七個大元件。
配合流程的話，我們最終得出這樣的流程。
從流程中可以看到，在推行平台化的過程中，我們需要一些回報問題和修正的機制，這種容錯機制可能會維持一段時間，如果方向正確，錯誤越來越少，如果發現問題越來越多，表示設計有問題，需要重新做一次歸納和分析。
至於要怎麼實作這些東西，我們需要具備什麼條件，之後再跟大家分享。
而這就是為了第一階段的時候，有一些工具，我們選擇自製，不採用開源工具，是因為那些環節都是高度客製化的區塊，而後台最大量出現的就是表單，所以表單引擎是我們早在3年前就開始實踐的工具。
除此之外，其他UI都是用Ant Design，那是一個非常適合做後台的UI系統。
做一個平台工具很簡單，步驟大概如下。
一步一步來，最後再加上一些細節，就大功告成。
