軟體專案的品質評分標準
基於人類判斷的線性評分模型
對於軟體專案的品質評估，我一直被兩種不同的方法吸引。一種來自 《Code Scene》，這本書依賴 git commit log 來發現程式碼的技術債和風險。另一種是 《Idea Flow》，它則通過分析工程師在開發軟體時，如何分配時間來衡量生產力。這些方法各有其優點，但實際應用到專案中時，我發現它們難以提供具體、可行的指導建議。
原因在於，軟體專案的複雜性遠超過單一量測標的所能涵蓋的範圍。
單靠一兩個可以客觀量測的標的，無法涵蓋架構設計、程式碼品質、測試覆蓋率和運維流程的各種層面。而且這些量化指標的客觀性，往往意味著它們犧牲大量的上下文資訊——然而，上下文往往才是專業人士真正關注的焦點。
因此，我開始思考：如果不依賴客觀量測，而是轉向主觀評估，依賴人的判斷來進行量測，會如何呢？
專案品質的 13 項人類判斷指標
我設計了一套包含 13 項指標的評估標準，分為三大類：資料庫設計、程式碼品質和輔助支援。這些指標的核心思想是通過開發者的主觀評估，來回答這樣一個問題：專案的設計是否能有效預防 unplanned work？（即非計畫性工作，通常反映設計漏洞或開發效率問題。）
1. 資料庫設計（Database）
資料庫設計的好壞，直接影響專案的穩定性和可維護性。此外，資料往往比程式碼活得更久。(Data outlive code.)
Database Type：使用的資料庫類型是否適配業務需求？（例如，SQL 和 NoSQL 各有適合的情境。）
Schema：結構是否清晰且符合正規化原則？
Constraints：是否合理利用資料庫限制條件，來確保資料的完整性？
2. 程式碼品質（Code）
程式碼的好壞是專案品質的核心，這部分設計了六個評估維度，隱含的量測目標是量測系統的「可延展性」與「可理解性」：
Correct Architecture：是否沒事亂用了微服務？
DRY Principle：程式碼有沒有過多的重複？
Clean API：介面設計是否簡潔易懂？是否降低了使用者的認知負擔？
Clean Implementation：模組的深度是否足夠？
SPI（Service Provider Interface）：模組如果是包覆服務的抽象層，是否有『服務接口』來支援日後抽換服務的靈活性？
Data Orientation 和 FP Style：函數式程式設計的應用程度如何？
3. 輔助支援（Auxiliary）
輔助支援是很多團隊忽略的部分，但它往往決定了專案的可持續性。
Guide：是否照著指導就可以有效地把專案跑起來？
Reference：程式碼裡是否多數的模組、多數的函數都有對應的文件？
Test：是否有一定程度的單元測試和整合測試？
Admin Process：參考設計良好的管理進程？
線性評分模型
這 13 項指標分屬三大類，每一類的權重相等（33.3%）。在每個類別內，指標的權重均分。例如，程式碼品質有 6 個指標，所以每項指標的權重約為 5.6%。最終的分數通過以下公式計算：
Quality Score = 0.33 * DB Score + 0.33 * Code Score + 0.33 * Auxiliary Score未來的工作
為什麼我選擇基於人類判斷？因為人類的經驗和直覺可以捕捉到客觀標的無法表現的上下文資訊。git commit log 與流逝的時間都是客觀的，可惜它們往往缺乏專案的背景細節，然而以人類的判斷做為量測工具的話，恰好可以補捉到這些關鍵的上下文。
現在的模型只是一個雛型，是否選擇的指標合理，還有待日後實驗的驗證。如果這個模型合理，那日後可以透過由多位專家給出評估，並且把多人評估的分數計算 z-score 以增加這個線性模型的穩定性與可靠度。