失落的技術

首先讓我來談一下，我改寫的這個量測類別與PEAR::Benchmark有何不同。

1. 量測是一個單一且未繼承其他類別的單純類別，而Benchmark是繼承PEAR類別且根據功能拆分成三個小類別。
2. 量測在輸出的部份僅輸出HTML，而Benchmark可選擇輸出HTML及Plain。
3. 量測在輸出上交由其他的一般函數來處理，而Benchmark則交由成員函數來處理。
4. 量測在計算上不考慮使用BCmath模組，而Benchmark則有。
5. 量測在測試函數的方式上可選擇不同的參數傳遞方式，而Benchmark則僅有一種方式。
6. 量測在調用函數的分析上考慮了多重出口的情況，而Benchmark不考慮。

大致上就如以上所述，接下來我先談一下量測這個類別與其他的程式有何不同，以及為何要如此設計的考量。

量測的類別通常使用於開發過程中，或是在維護階段尋找程式執行的瓶頸，幾乎不會被用在一般正在線上執行的系統中，所以我才會將三個功能全部放在一起。
這三項功能分別是：

1. 量測兩個程式執行的時間點的時間差。
2. 重複測試一或多個函數的執行效率。
3. 分析一或多個函數在調用時的狀態。

第一個功能很單純，只要紀錄時間點後，再根據時間點間的時差作計算。

第二個功能稍微複雜一點，我在量測中只增加兩個功能：每次執行的參數可以不同、可以一次針對多個函數進行測試。（這裡要稍微說明一下我個人喜歡的一個技巧：就是把資料先準備好，然後作單一的動作。）
量測對應的四種測試方法分別是：單一測試、單一測試：陣列、多重測試、多重測試：陣列。
後面有「：陣列」的方法，差異在於參數傳遞的方式不同，以及可以讓每次執行的參數可以不同。
如果你看源碼的話就會發現這四個方法是互相調用的，之所以設計成四個方法，是為了讓不同習慣的人方便。
不過由於這個類別是我所寫的，因此下次維護的時候我或許會將四個方法減少也不一定。

第三個功能算蠻複雜的，而且我也沒完全看懂Benchmark的作法，主要是對他計算某個指標（$_subSectionsTime）感到不解，不過我個人覺得那個指標或許跟我添加的多重出口有關係也不一定就是。
所謂的多重出口，簡單講就是一個函數可以有一個以上的return。
這個功能可以分析一個函數被調用、或是在函數中調用其他函數，以及每個出口所花的時間，因此這個功能主要是在找出執行瓶頸，提供改善的資訊。

接下來談一下我個人的程式設計哲學：容錯。
如果我們看Benchmark的源碼，在第三個功能的使用上，在某些條件上有一些錯誤訊息的產生，而我改寫的量測類別並不會有。

這個條件是假設使用者會有一些疏忽，設置了函數的進入點，卻忘了設置函數的離開點、或是反過來，也有可能在同一個函數使用不同的註記、或是在不同函數中使用相同的註記。

由於我個人的認知，第三個功能應屬於微調階段使用，因此我偏向不引起錯誤訊息，而讓報表的數字來引起程式設計者注意。這項功能產生的報表，大多是已經很有經驗的工程師或是系統分析人員才會去看的，一般的工程師大部份使用第一或是第二個功能就足以滿足了。
由於我做的檢查比較多，所以即使發生上述狀況也沒關係，只是報表上數字會很奇怪而已，下一個版本我會傾向自動產生註記，以避免意外狀況產生。

今天到此為止，下一個版本大概會在一個禮拜後出現。
明天我會拿幾個實際的程式碼片段來說明。