這一陣子以來，公司瀰漫在一片除錯的淵藪當中，很多人都顯得心力交瘁，我自己也被攪得焦頭濫額。這不禁讓人想起一句品管上的名言：品質是內建的，不是外加的（Quality is build-in, not add-on.）──這時讀來，倍感切心。
於是這次就延續上次的“程式設計的箴言”，不過換了一本關於“除錯”的書：
- 啟動所有編譯器中的預警功能。
- 利用lint找出那些編譯器所找不到的錯誤。
- 如果您有單元測試工具，請好好利用。
- 請同時保有“偵錯版”及“上市版”。
- 請利用assert維護巨集來確認函式引數的正確性。
- 避免讓程式產生未定義的行為，不然就在這些地方加上維護敘述，以免有人誤用了這些未定義的結果。
- 適時地加上註解，以免浪費別人的時間來看懂您的維護敘述。
- 不要直接利用假設的狀況，否則請加上維護敘述來檢查這些條件。
- 利用維護敘述找出不該在正常情況下發生的現象。
- 不要為求包容意外的狀況而忽略了潛在的錯誤。
- 利用不同的演算法來協助您確認程式的結果。
- 避免產生隨機行為，並且讓錯誤無所遁形。
- 清除不能使用的記憶體空間，以免誤用了它的資料而不自知。
- 程式中如果有些行為太少發生了，就強迫它多發生幾次。
- 多保留一些系統資訊，有助於進行更嚴謹的除錯。
- 徹底建立子系統的檢查程序，並且盡可能地去使用它。
- 小心地設計測試條件，從各種可行的方法中慎選最好的。
- 致力寫出無形的，而且完整的測試。
- 不要以發行時的標準來苛求偵錯版本，偵錯能力是必須犧牲速度及程式大小換來的。
- 不要等到錯誤發生，才被迫去逐步追蹤程式。
- 逐步追蹤您的程式。
- 逐步追蹤程式的時候，請多注意資料的流向及內容。
- 以原始程式指令為單位無法知道所有執行的細節，面對重要的程式碼最好以組合語言指令為單位來逐步測試。
- 讓程式的介面為程式師把關，使他們不至於忽略錯誤的情況，更不要因為傳回值的設計不良而造成錯誤。
- 不時地檢查、並且去除函式介面裡的缺失。
- 不要以一個函式來包含多項功能；盡可能讓每一個函式只完成一項獨立的功能，這樣有助於我們做更完整的引數檢查。
- 清楚地定義函式的引數，不要弄得模稜兩可。
- 確定函式的輸入值都是正確的，以避免函式傳回“輸入錯誤”的訊息。
- 讓一般的程式師都能由函式的定義看出函式的呼叫方法，並且避免使用布林值來當引數。
- 用註解來強調函式中潛在的危機。
- 利用定義明確的資料型別。
- 隨時注意變數會不會產生溢位或不足位的現象。
- 寫程式的時候要盡量依照原始的設計，任何無心的偏差都可能造成始料未及的錯誤。
- 盡量使每一個步驟都只用一段程式來完成。
- 盡量不用if敘述來處理例外的狀況。
- 避免層層疊疊的使用?:運算子。
- 盡量使同一類的特殊狀況只用一段程式處理──將相同的條件敘述合成一條。
- 避免採用程式語言的危險慣例。
- 若非必要，不要任意將不同類的運算混在一個式子裡。萬一必須將不同的運算放在一起使用，就用括號來標明運算的順序。
- 避免呼叫會傳回錯誤碼的函式。
- 不屬於自己的記憶體，就不要使用。
- 不要去使用已經被我們釋放的記憶體空間。
- 不要把用來傳輸出結果的記憶體拿來當成作業時的暫存空間。
- 不要以 static（或整體性）的空間來傳資料。
- 不要讓我們的函式變成“寄生蟲”。
- 不要濫用程式語言的特性。
- 將 Ｃ 的原始程式寫短，編譯出來的執行碼不見得就會有效率。
- 寫程式要盡量讓一般人看懂。
- 錯誤不會自己“跑掉”。
- 發現錯誤立即修正，莫待將來付出更慘痛的代價。
- 不能只是解除錯誤的表象，要除掉病因才能真正解決問題。
- 除非為了讓軟體更成功，非修改不可。否則不要隨便“整理”程式。
- 不要增添沒有必要的功能。
- 任何一項功能都要付出代價。
- 不要容許沒有必要的彈性。
- 不要盲目地從一堆“嘗試”中去找答案；將時間用來找尋“最正確”的方法。
- 每完成一小部份，就先回頭測試一遍。不管進度是不是落後，一定要徹底地將程式測試過。
- 不能只靠測試小組來除錯。
- 不要錯怪測試人員存心找麻煩。
- 建立自己適用的優先順序，並確實地依照這個標準來做取捨。
- 不要讓同一個錯誤有再次出現的機會。
好了，總共六十一條，終於整理出來了，希望對各位有所幫助。想要知道更詳盡內容的話，強力建議諸位直接去翻閱本書。
0 comments:
Post a Comment