R21 設計在於管理(3)──快速追溯關聯

在設計上能夠界定使用關聯的範圍時，接下來要做的是定義每個關聯的影響深度，從這裡可以得知改變的影響。影響會分為上下兩層，對下的使用改變主要是看流程中增減了哪些動作，對上則是看有哪些動作呼叫了自己。其中往上的追溯最為重要，因為自己改變就有可能令上層使用自己的方式有所不同。

程式開發工具裡都會有追溯的功能，不管是使用上的追溯或是繼承上的追溯都有，只要按一下熱鍵就能將指定Class、Method或Data有關聯的地方全部都列示出來。許多人看準了這個功能的好用，因而完全不在設計上作追溯的管理僅在需要的時候才利用這個功能，同時號稱這樣找出來的是完全正確的結果，不像追溯表那樣可能有無法同步的風險。

這樣的想法在單一的關聯上是正確的，但是根據許多人的經驗：使用上找使用關聯時往上找三層就受不了，繼承關聯在五層後會開始混淆，如此等比級數的發散光是找一個就可能吃不消，更何況系統裡的總數不知道有多少。每次系統上出了較嚴重的問題時，客戶就會要求在找出問題的同時，必須報告改變部分所作的改變會影響哪些功能。我也曾經為了一個重大的改變花了整個下午去定位並分析並向上追溯，搞到頭昏腦脹之後也沒法肯定那些是否為完全正確的結果。

越大型的專案，對於使用上的關聯管理起來越為複雜。沒有對的方法與工具，管理起來都是吃力不討好；沒有正確的觀念作為前導，同時也會忽略使用關聯的重要性。等到臨時需要改變，追溯出來的結果沒有涵蓋到執行時發生錯誤的地方，自然會被視為沒有品質可言。

與每層都追溯使用方法的方式比起來，我所想用的分層追溯應是相對簡單的作法。以每個介面作為切割點，根據現有的實作記錄往下使用的介面方法（超理想作法是由程式碼轉出使用關聯），等到需要的時候可立即追溯到上一層的介面使用；如果我的想法證明可以落實的話，應該可以立即追溯到最上層的所有使用功能。