敏捷編程 (Agile programming) 介紹文件@developerWorks 及個人感想
對一個個體導向 (Object-Oriented) 的老手而言，敏捷編程和輕量級開發的原則與原理，應該是似曾相識，非常熟悉的。敏捷編程所揭示的原則與原理，和個體導向是分不開的。事實上，那正是個體導向技術所追求的目標。
Lightweight design patterns let you loosen coupling between objects and integrate services without forcing code into business logic or the domain model.
In fact, the most impressive scaling usually happens because simple, elegant, stateless designs let the infrastructure do its job.
some development methods may discourage refactoring or changes in a process because those activities do not directly contribute to generating customer code. Lightweight development demands the freedom to fix code that gets too complex or bug-ridden.
Use short cycles and active customer participation.
Secrets of lightweight development success, Part 1: Core principles and philosophies
對於 refactoring ，一些人會拿出十年前的舊話「沒壞的地方就不要修」。但我總會指正他們，這句話是針對十年前，非 OO 開發方式撰寫的程式碼，因為當時的程式碼，總是夾雜不清，彼此耦合。很少有 programmer 敢保證，當他改了這裡，其他地方不會受到影嚮。由於當時程式碼的修改總是面臨著牽一髮而動全身的困擾，才會有「沒壞的地方就不要修」的因應態度。例如 Assembly 程式或 BASIC 程式，就算要我 refactoring ，也難以下手。但 OO 技術強調的是「開放封閉原則 (OCP)」：內容高度封裝、隱秘，介面抽象化、公開化。根據此一原則，外界根本就不應發覺類別內容的改變。因此，我們遂得以在不影嚮任何外在行為的狀況下，進行 refactoring ，簡化程式碼結構，精煉出可再用的程式碼。
敏捷編程追求簡潔而結構化的程式碼，其所帶來的好處不僅是視覺效果，其真正價值是隱而不顯的軟體品質提昇。一個複雜、四處剪貼、沒有結構的程式碼，往往潛伏了許多 bug ，在非 OO 式開發環境中，這些程式碼四處可見。其中隱伏的 bug 更是難以清除。但在 refactoring 的過程中，常常會發現許多未預料的 bug 。就個人經驗而言，在此過程中，至少就消除了 50% 以上的潛伏 bug 。而簡潔而結構化的程式碼，更降低日後修改錯誤的時間成本。別忘了，敏捷編程強調的實作內容之一，就是 Test-Driven Develope (測試驅動開發) 。這意味著敏捷編程預設立場為：程式碼一定有 bug 存在，因此要隨寫隨測，發現錯誤後立即修正。同時，單元測試可改善軟體開發效率與品質的前提在於，當一個項目發生錯誤時，應當只有這個項目需要修改和再測試，而先前已經通過測試的項目是不需修改，且仍然可通過測試的。一般公司在導入 TDD 時最常見的問題，就是要求 programmer 的程式碼去趕上單元測試的 schedule ，於是 programmer 趕工似地胡亂拼貼出程式碼後進行單元測試。出現錯誤要回頭修改時，才發現自己面對的是一座蠻荒叢林。改了這個地方，卻在先前測試通過之處產生了新的錯誤。於是不斷地在「再修改-出現新錯誤-再修改-又出現新錯誤」的惡性循環中虛耗。錯不在單元測試，而錯在導入者沒有體認到要成功引入單元測試的要件，在於符合 OCP 、簡潔而結構化的程式碼，亦即「好的程式碼」。
「較短的釋出週期」同樣也是個體導向技術實作中的重要內容。當時就提出了「寫一點、測一點」的觀念。而依然要強調的是，「好的程式碼」是成功的基礎，為了要趕上「較短的週期」而要求 programmer 趕工而不顧程式碼的結構性，仍是大忌。話說回來，在敏捷編程出現之前，許多軟體專案就失敗在為了追趕 schedule 而捨棄「好的程式碼」，其結果是巨大的反差：除之不盡的 bug 和一延再延的交貨期限。導入敏捷編程方法，並不是字面上的快速鍵入程式碼 (typing code)。事實相反，敏捷編程的精神，是讓程式碼自我描述，讓程式碼自己會說話。為此， refactoring 無時不刻都要做，才能時時保持「好的程式碼」。
當年我第一本接觸的 Object-Oriented 技術書籍，是資訊與電腦雜誌社出版的「個體導向技術導引」(施保旭著，1994年三版)，匆匆十二年過去了，這本書的內容仍然帶給我很大的幫助。