5 posts
Literate programming 承諾單一事實來源，但手動的 weave 和 tangle 步驟會破壞 CI/CD 流水線。以下是如何自動化提取和文件生成，使 Markdown 檔案保持規範。
如果你的建置流水線必須等你開啟終端機輸入 才能執行，那你就沒有文學化程式。你有的只是一本綁著編譯器的日記。 文學化程式設計的全部意義在於散文和程式碼共享單一事實來源。Markdown 檔案就是產物。其他一切——可執行原始碼、渲染後的文件、測試檔案——都是衍生的。衍生產物屬於 CI，不屬於你的工作記憶。 問題不是 CI…
大多數團隊把架構規則寫在 wiki 裡。這裡教你怎麼把它們變成可執行的測試，當依賴圖偏離設計時就讓 CI 失敗。
你的測試套件會驗證 在給定正確輸入時回傳 42。但它不會驗證 是否被允許 import 。編譯器對兩者都接受。你的單元測試對兩者也接受。但其中之一是架構違規，六個月後會讓你花上一整週重構。 這就是盲點。我們為邏輯寫測試，卻假設結構會自動維持。它不會。…
Clean architecture 的圖在白板上畫起來很漂亮。這裡教你怎麼讓 build pipeline 自動執行 dependency direction，確保 domain code 絕對碰不到 infrastructure。
團隊裡有人剛剛在 裡引用了 。PR 可以編譯過。測試全綠。Code review 有三百行，沒人發現。 三個月後，你想把 domain logic 抽成 shared package。你抽不出來。它依賴 Postgres 的型別、connection pooling 邏輯，還有一個只在 monolith 裡存在的…
大多數團隊不會在每次 commit 都跑完整的 mutation testing。這裡告訴你工程團隊如何實際把 mutation testing 整合進 CI，又不會搞爛 build pipeline。
如果你的 mutation testing suite 要跑四小時，恭喜你。你證實了大家早就猜到的事：你的測試有漏洞。 你不會在每次 push 都跑這個。沒有團隊這樣做。問題不是你能不能負擔每次 commit 四小時，而是你能不能承受程式碼測試通過了，卻根本沒有驗證任何東西。 Code coverage…
人工審查不一致。AI 審查更糟。AI 生成 codebase 唯一可擴展的防禦是確定性 enforcement：讓建置失敗的規則，而非被忽略的建議。
對 AI 生成程式碼的標準建議是「仔細審查它」。 這建議正確但在規模化時毫無用處。 開發者在警覺、熟悉領域且沒有時間壓力時，審查 AI 輸出能發現問題。在其他所有情況下——也就是大多數情況——問題會溜過去。 用 AI 審查者抓 AI 生成的問題更不可靠。你在要求一個機率系統驗證另一個機率系統的輸出。失敗模式是相關的。…