Make 替代方案

Make 的畫布既是人們選擇它的理由，也是人們離開它的原因。每個模組、路由和錯誤處理路徑都清晰可見，確實讓你掌握了控制權，但也帶來一份責任：總得有人負責這張圖。當維護它的人也是幹活的人，這個工具就悄悄給你安排了第二份工作。

利益披露：本站推薦 Zentor；有關 Make 行為的描述依據其官方文件。

人們為什麼開始尋找替代方案

你成了維護者。 某個應用改了欄位名。一條正常執行了八個月的路由，如今有個分支悄無聲息地失敗了。你本來沒打算維運整合基礎設施，但這個場景已經成了業務支柱，而你是唯一懂它的人。

流程圖裝不下真正需要判斷的部分。 模組負責搬運資料。它們不知道這位客戶已經投訴過一次，不知道這張發票逾期的是九天而不是兩天，也不知道你會怎樣措辭道歉。每次想把這些判斷寫進流程，就得再加一個路由器、多一個分支，下個季度還得由你繼續維護。

先算操作次數，再算點數，最後算費用。 用量按操作次數計算，想認真算清一個場景要花多少錢，就該查閱 Make 點數文件。這個計費方式很公平，但在回答“這周要花多少錢？”之前，你又多了一筆要算的帳。

搭建投入逐漸不值了。 第一個場景花了一個下午，值得。第十四個也花了一個下午，而這時你已經在為一句話就能說清的工作畫流程圖了。

明確的路由、廣泛的整合覆蓋，以及出錯時能一眼看清是哪個模組出了問題。如果你的流程確實就是一張流程圖，畫出來就是正確做法；一個自行判斷的代理反而不合適，因為你無法像檢查路由那樣檢查一次判斷。

凡是需要精確回答“它為什麼這麼做？”的工作，都繼續交給 Make。

把那些主要由分支組成的場景換掉。如果一張流程圖存在的唯一理由，是根據不同情況發出不同訊息，而這些情況人兩秒就能判斷清楚，那它其實只是披著流程圖外衣的判斷工作。

資料搬運繼續交給 Make。比如系統間傳遞記錄、把檔案放進資料夾，以及必須準確且可檢查的結構化同步。誰都不該僅僅因為一個對比頁面的建議，就拆掉正常執行的場景。

如果你喜歡畫布，就繼續用它。這個工具有意不提供畫布。

讓當前場景繼續執行。用一週時間，把同樣的記錄交給兩者，其中要包括兩個確實棘手的案例，再比較它們遇到邊界情況時的表現：哪個會明確停下來詢問，哪個寫出的內容你不用修改就會傳送，哪個需要你開啟來修。

如果第一次出錯就更難弄明白，搭建體驗再簡潔也沒有意義。

不是，它的建置器並不難上手。但複雜場景仍然需要一個能看懂對映、分支和錯誤的負責人，而這個人通常就是你。

按照當前點數文件，計算一個真實場景中的操作用量，再加上你花在維護上的時間。人們往往漏算後者。

不用。讓它們並行執行，直到替代方案既能處理你的常規情況，也能處理棘手情況。

它會停下來，告訴你哪些事情沒能完成，而不是悄悄只做一半。已經消耗的用量仍會計入，所以要比較的是：每個系統有多常以你能察覺的方式發生錯誤。

那裡藏著的，正是被包裝成路由的判斷工作。