讓軟體變軟的兩個原則

Jan. 22 16:02~18:10

之前Teddy曾寫過一篇《什麼是軟體工程 (2)》，文中提到：

1. 軟體不是軟的。事實上，軟體很硬。
2. 軟體工程的目的：
   • 讓你可以把軟體做出來。
   • 讓你的軟體變軟。
   • 讓你在可接受的成本範圍內達成上述兩件事。

今天Teddy想談一下，「如何讓軟體變軟」的兩個原則。

***

為什麼軟體很硬

在介紹這兩個原則之前，先幫鄉民們複習一下，為什麼軟體會變成「硬體」？所謂「軟體很硬」指的是以下現象：「只要一修改或增加新功能，便很容易導致原本正常運作的功能發生錯誤。更慘的是，這些錯誤通常過了一陣子之後才被發現，導致非常冗長的debug週期，最慘的情況甚至導致整個團隊都沒有人知道要如何修復這些問題」。所以，漸漸地團隊成員沒有人 敢 願意動手修改現有可運作的程式。在這種情況下，要達到XP（eXtreme Programming）所說的「擁抱改變」是不可能的，「抵死不變」反倒成為團隊追求的目標。如果鄉民們手邊的專案也有上述「症頭（症狀）」，恭喜您，正式從「軟體開發」升等為「硬體開發」。

方法一：自動化測試

讓軟體變軟的第一個方法，就是導入自動化測試（單元測試、整合測試、功能測試…等等）。為什麼做自動化測試可以讓軟體變軟？答案很簡單：

• 有了自動化測試，每次修改程式之後，重新執行一次測試案例，讓這些測試案例幫忙確認「原本正常的功能，在本次修改之後還是正常的」。 若測試案例執行失敗，便可知道很可能是因為剛剛修改程式所導致的問題。此時要debug找出問題相對來講會容易許多。
• 自動化測試可以支持軟體重構（refactoring），而軟體重構有點像是「SKII 保養品」，可以「消除皺紋，讓皮膚緊緻，找回青春」。也就是說，藉由重構可以讓漸漸僵硬的軟體，恢復昔日柔軟的身軀。

方法二：提升設計能力

在眾多的軟體設計原則中，有一個最基本的概念，就是「提高內聚力，降低耦合度」（請參考《亂談軟體設計（1）：Cohesion and Coupling》）。如果軟體的耦合度太高，軟體中各個元件的相依性就變得很高，因此當軟體被修改之後，很容易發生「牽一髮而動全身」的「漣波效應」。這種現象正是軟體變硬的原因之一，如果可以讓修改所造成的影響局部化，就可以避免漣波效應產生。

但是在實務上要如何做到「提高內聚力，降低耦合度」，或是「區域化修改所造成的影響」？方法很多，例如：

• 從基本的物件導向觀念著手，正確使用Class、Object、Interface、Inheritance、Polymorphism、Composition、Delegation這些基本功夫便可達到不錯的療效。
• 從物件導向設計原則著手，例如Open-Closed Principle、Single-Responsibility Principle、Liskov Substitution Principle、Dependency-Inversion Principle、Narrow Inheritance Interface Principle等等。
• 從模組化設計原則著手，例如Reuse-Release Equivalence Principle、Common-Reuse Principle、Common-Clouse Principle、Acyclic-Dependencies Principe、Stable-Dependencies Principle等等。
• 從GoF的23個設計模式著手，請上最新的「Design Patterns這樣學就會了：入門實作班（平日班）」與「Design Patterns這樣學就會了：進階實作班」XD。
• 從軟體架構著手，請自行參考軟體架構書籍。

***

自動化測試和提升設計能力是息息相關的兩項技能。Teddy經常聽到鄉民們抱怨：「測試好難寫，所以不寫測試了」。「測試好難寫」這件事，背後的真正原因，除了鄉民們尚未學習到撰寫測試的方法之外，另一個常見的原因則是「軟體設計不良」（請參考《需求變來變去的情況下需要寫單元測試嗎？》）。如果鄉民們能夠接受「撰寫程式」這件工作同時包含了「寫production code」與「寫testing code」這兩個活動（何者順序優先都可以），那麼你的軟體一直維持在18歲的機率就蠻高的。就算沒有辦法一直維持在18歲，也絕對是個「美魔女」啊。

***

友藏內心獨白：常吃富含膠質的食物可以讓軟體變軟嗎 ？！