T22 工廠的成功要看產品的可檢測程度

細心的人即將購買物品之前，一定都會去訪查所有類似產品的各種規格再從中選擇最適合的一個，採買時願意花功夫訪查細節，開發系統選用元件時應沒可能隨便就拿來用用。從另一個角度來看，製作物品者都可以提供各式各樣的規格資料與使用說明書來讓人明白其內涵，元件沒理由只具備Interface而像個黑盒子。

以我所知，Naming Standard、Coding Rule是目前最常用來檢驗程式碼是否符合規定的項目。前者會根據專案規定在review或unit test時查看，後者則會選擇一種適用的工具定義程式碼檢查項目後全部加以檢驗。但是架構的佈置與動作的流程（註）都只能看到理論的闡述，沒有明確的作法與可驗證的工具，問過同事也查過資料，一直都沒有聽說過有這樣的工具可用。

每一類型的工程，其任何產出物都應具有可檢驗的諸元可作測量或測試，而且可檢測的物件與規格越細微相對代表其品質越可靠。在該檢驗的部分只有模糊的理論時，自然就會被不同的人用不同的想法來解讀為不同的作法。人員之間有差異、專案之間也有差異，漸漸地整間公司內的產出根本都不相同，此種情形之下要如何採用標準化的制度或工具來套用雜亂的項目？

簡單地說，一個產品提供的檢測項目越涵蓋其特性就越能保證會有一定的品質，以目前開發重心都傾向快速完成功能的思維來看，對於系統內部的使用、測試、交接、修改、維護等等的需求總是難以做到不令人詬病的狀況。明列出所有程式區塊的特性與檢查點，會有助於建立完整測試個案與快速讓他人瞭解內容，這也就是建立標準元件結構的目的。

軍隊裡對於所有的姿勢（站、坐、蹲、跪、伏……等）與動作（左右轉、行進……等）都對肢體的擺放有明確的定義，在不同的情境下（姿勢與動作再加上背槍、提物、抬物……等）也會另外定義對肢體的要求。詳細的定義與嚴格的要求在人數眾多時，在每個人身上呈現的就是整齊的紀律，將同樣的意義推展到軟體元件的產出，所需要的就是明確一致的詳細設計準則。

註：雖然有很多開發工具都能在程式執行時追溯出該次執行的完整sequence diagram，但那是很詳細的程式呼叫順序，對於不需要看到太多實作的ＳＡ與部分ＳＤ人員來說根本沒法得到他們需要的設計概念。