事實上，整個開發周期還沒有結束，現在進入的是傳統意義上稱為“維護”的一個階段。“維護”是一個比較暧昧的稱呼，可用它表示從“保持它按設想的軌道運行”、“加入客戶從前忘了聲明的功能”或者更傳統的“除掉暴露出來的一切臭蟲”等等意思。所以大家對“維護”這個詞產生了許多誤解，有的人認為：凡是需要“維護”的東西，必定不是好的，或者是有缺陷的！因為這個詞說明你實際構建的是一個非常“原始”的程序，以後需要頻繁地作出改動、添加新的代碼或者防止它的落後、退化等。因此，我們需要用一個更合理的詞語來稱呼以後需要繼續的工作。
這個詞便是“校訂”。換言之，“你第一次做的東西並不完善，所以需為自己留下一個深入學習、認知的空間，再回過頭去作一些改變”。對於要解決的問題，隨著對它的學習和了解愈加深入，可能需要作出大量改動。進行這些工作的一個動力是隨著不斷的改革優化，終於能夠從自己的努力中得到回報，無論這需要經歷一個較短還是較長的時期。
什麼時候才叫“達到理想的狀態”呢？這並不僅僅意味著程序必須按要求的那樣工作，並能適應各種指定的“使用條件”，它也意味著代碼的內部結構應當盡善盡美。至少，我們應能感覺出整個結構都能良好地協調運作。沒有笨拙的語法，沒有臃腫的對象，也沒有一些華而不實的東西。除此以外，必須保證程序結構有很強的生命力。由於多方面的原因，以後對程序的改動是必不可少。但必須確定改動能夠方便和清楚地進行。這裡沒有花巧可言。不僅需要理解自己構建的是什麼，也要理解程序如何不斷地進化。幸運的是，面向對象的程序設計語言特別適合進行這類連續作出的修改——由對象建立起來的邊界可有效保證結構的整體性，並能防范對無關對象進行的無謂干擾、破壞。也可以對自己的程序作一些看似激烈的大變動，同時不會破壞程序的整體性，不會波及到其他代碼。事實上，對“校訂”的支持是OOP非常重要的一個特點。
通過校訂，可創建出至少接近自己設想的東西。然後從整體上觀察自己的作品，把它與自己的要求比較，看看還短缺什麼。然後就可以從容地回過頭去，對程序中不恰當的部分進行重新設計和重新實現（注釋⑩）。在最終得到一套恰當的方案之前，可能需要解決一些不能回避的問題，或者至少解決問題的一個方面。而且一般要多“校訂”幾次才行（“設計范式”在這裡可起到很大的幫助作用。有關它的討論，請參考本書第16章）。
構建一套系統時，“校訂”幾乎是不可避免的。我們需要不斷地對比自己的需求，了解系統是否自己實際所需要的。有時只有實際看到系統，才能意識到自己需要解決一個不同的問題。若認為這種形式的校訂必然會發生，那麼最好盡快拿出自己的第一個版本，檢查它是否自己希望的，使自己的思想不斷趨向成熟。
反復的“校訂”同“遞增開發”有關密不可分的關系。遞增開發意味著先從系統的核心入手，將其作為一個框架實現，以後要在這個框架的基礎上逐漸建立起系統剩余的部分。隨後，將准備提供的各種功能（特性）一個接一個地加入其中。這裡最考驗技巧的是架設起一個能方便擴充所有目標特性的一個框架（對這個問題，大家可參考第16章的論述）。這樣做的好處在於一旦令核心框架運作起來，要加入的每一項特性就象它自身內的一個小項目，而非大項目的一部分。此外，開發或維護階段合成的新特性可以更方便地加入。OOP之所以提供了對遞增開發的支持，是由於假如程序設計得好，每一次遞增都可以成為完善的對象或者對象組。
⑩：這有點類似“快速造型”。此時應著眼於建立一個簡單、明了的版本，使自己能對系統有個清楚的把握。再把這個原型扔掉，並正式地構建一個。快速造型最麻煩的一種情況就是人們不將原型扔掉，而是直接在它的基礎上建造。如果再加上程序化設計中“結構”的缺乏，就會導致一個混亂的系統，致使維護成本增加。
