engineering-economylisted

# 工程經濟(Engineering Economy) ## 什麼時候用 每一個「怎麼做」的決策。工程的成本不只是「寫出來」,還有**改的成本、驗的成本、將來錯的成本**。 這技能是一組讓四件事同時成立的法則:**更改少、功能佳、測試時間少、完善不出錯**——省下來的力氣 拿去做更多真正的功能。 --- ## 一、更改少(改動面越小,越好驗、越不易壞) ### 法則 1:優先複用已驗證的既有路徑,不新建平行機制 要做新功能,先問「現有哪條路徑已經做過類似、且驗證過了?��——**騎上去**,別另起一條平行的新機制。 新路徑 = 新的未驗證表面 = 新的出錯來源 + 又要重新建一整套驗證。複用已驗證路徑,新功能幾乎免費繼承 它的正確性保證。 **★「已驗證路徑」包含外部世界的(先查外部經驗再開工)**:撞牆時你踩到的,很可能是全世界都踩過的 已知特性(例:某主流函式庫官方文件明載一般載入記憶體≈檔案 50 倍——三輪 OOM 硬撞,一查官方文件即解, 正解〔串流模式〕人家寫好了)。開工前/卡關時先查官方文件、成熟函式庫、論文,成本是幾分鐘,省的是幾輪 重撞。**但借鑑不照抄**:①採用前用**自己的 oracle** 考它(外部庫也會錯,不因開源就採信);②列明你在 它上面疊的**差異層**(你的場景多要什麼保證);③它的通用解若有��藏坑(如「持久化」被實作成整包序列化 =問題原地復活),要辨識出來——借地基,牆自己砌。 **★外查的時點=開工前,不是撞牆後**:「遇到問題才查」是救火式外查——學費已付才翻圖紙,冤枉路 已經走完了。正確的時序是:任何**新區塊**(要發明新機制/新資料流/新互動模式)動工前,第一個交付物 =半頁「外查對標摘�����」:①業界標準做法(2-3 源交叉)②要跟的部分③要更好的差異層④明知偏離之處+理由。 摘要過了把關才寫第一行碼。修 bug、既有機制內迭代不需重查。反例實錄:同一專案,資料層開工前外查 =一路站在標準上;介面層跳過外查徒手現想=分頁狀態、任務還魂、重連語意逐顆踩雷,事後一查——每顆 的標準答案早就印在業界文獻裡。同一批人、同一週,差別只在查的時點。 ### 法則 2:外科手術式修改,不重寫整段 改既有程式時,做**最小切口**:只動需要動的,不順手重寫整段。重寫 = 把一段已驗證的東西變回未驗證, 風險與驗證成本全部重來。「能加一個 if 解決,就不重構整個函式。」 ### 法則 3:跨消費者的資料契約先凍結,消費端才有得接 當一份資料/介面會被**別的模組或別的階段**消費時,先把它的**結構(schema)定死**,再往下做。 - 消費端靠這個契約對接;契約晚定 = 消費端無所��從,或先做了再返工。 - 尤其「這批只生產、下批才消費」的東西:結構先凍結 + 誠實標「已產出待消費」,下批直接接,不用回頭 重問一次(拍板不會蒸發)。 ### 法則 4:介面類交付,先出靜態原型定調,拍板後才寫碼 要做「人要看的東西」(UI、報告版面、對話流程)時,先做**不接後端的靜態原型**(mock)給決策者定調 ——長相、文案、流程對不對。**拍板後才寫真的碼**。理由:介面的返工最貴(碼 + 樣式 + 接線全牽動), 把「這樣對嗎」提前到最便宜的原型階段解決。 --- ## 二、測試時間少(驗證是每次都要付的稅,要壓到最低) ### 法則 5:測試分層經濟學 按「跑多快 × 多常跑」分層: - **秒級煙霧**:每次改動都跑,只驗最關鍵的活著沒。 - **分鐘級針對性