軟體設計/編程的基本技術(附圖)

目錄

1.設計父類時考慮不周到，等到設計或者編寫子類的時候，才發現父類需要修改、增加功能等等，都很平常

2.盡量避免多次寫同樣的代碼

3. 持續改進

4.評價軟體設計的高低的幾個基本原則

內容

1.軟體設計/編程中，有一門基本技術叫“物件導向編程”。物件導向編程的基本思路是對象封裝和繼承。繼承的基本思路是，所有子類共同的部分，提取、抽象後，放到父類中。

這是一個說起來容易，做起來難的事情。父類總是先設計，先實現。一個父類一般都有多個子類。沒有人能夠Crowdsourced Security Testing先覺。設計父類時考慮不周到，等到設計或者編寫子類的時候，才發現父類需要修改、增加功能等等，都很平常。例如
public class RequestInfo{
    public DataItem getDI(String name){
    }
}

public class DataItem{
    public String getValue() {
    }
}

當我們經常寫
String cycCode = info.getDI("cycCode") == null ? null : info.getDI("cycCode").getValue();

的時候，我們自然會想，如果在 class RequestInfo 中增加一個函數 getDIValue() 就可以寫更短的代碼了：
String cycCode = info.getDIValue("cycCode");
這樣做的好處，代碼更簡潔，更易懂，也更容易維護。
同樣的道理，當我們經常需要從 info 中取 int value 的時候，我們自然會知道，應該往 class RequestInfo 中增加 getIntValue().

2.在軟體開發的過程中，最基本的原則是，避免多次寫同樣的代碼。舉例來說：

這是很常見的基類設計時考慮不周導致的問題，每個子類有同樣的代碼，。解決方案也很簡單，將共同的部分放在 base class 中就可以了：

 

3.軟體行業和其他行業一樣，要想做出品質好的產品，關鍵在於“持續改進”。持續改進的意思是，如果發現了不好的設計，就應該修改。然而，很多時候事情並不這樣簡單。
例如，一個公司有兩百個同樣的生產線，現在有人發現了一個改進辦法，可以提高效率。我們都知道，不可能把所有的生產線同時進行改造，那樣對於現有的生產造成很大的影響，並且從人力物力方面，也有很大問題。更好的辦法是，對於新的生產線，採用新的改進辦法。原有的生產線，既然還能工作，就不用立即修改，可以在以後逐步改進。
這個例子換成軟體行業的話：
一個公司有兩百個類似功能的軟體模組/類(比如 xxxBPI)，現在有人發現了一個改進辦法，可以在子類中寫更少的代碼，提高效率，代碼更易於維護。我們都知道，不可能把所有 xxxBPI同時進行改造，那樣對於現有的開發造成很大的影響，並且從人力物力方面，也有很大問題。更好的辦法是，對於新的xxxBPI，採用新的改進辦法。原有的代碼，既然還能工作，就不用立即修改，可以在以後逐步改進。

因此，大型的軟體中，新老方法並用的情況很多。比如， MS SQL Server, 很多原有的代碼是從 Sybase 購買，MS 的技術專家發現了一些提高效能的辦法，在經過多年，多個版本更新後，才逐步完成了改進老的代碼。在開源的項目上面，也有很多項目版本說明中申明，計劃採用某某技術改寫原有的代碼，目前完成哪些模組，計劃增加哪些模組。改進和增加新功能永遠是同時進行的。

上面的例子，採用持續改進的方法後，變成下面的樣子：

4.評價軟體設計的高低的幾個基本原則

評價軟體設計的高低的幾個基本原則依次為：易懂，易用，穩定性，功能。
易懂：VB 的使用者之所以比 VC 多，在於它易懂。用 Word 寫設計文檔的人比用 Rose 的人多，也在於懂 Word 的人更多。易懂意味著可以用更短的時間學會。
易用：如果 class A 和 class B 完成同樣的功能，但使用 class A 需要寫的代碼更少，我們就說 class A 設計得比 class B 更好。因為使用 class A 寫代碼，代碼更短，開發效率更高。代碼短對於以後的維護也更容易。
穩定性，功能：軟體的賣點在於穩定性，功能。之所以這兩項排在前面亮項後面，同樣有事實為證：Unix/Linux 的穩定性、功能超過於 Windows，但是它的使用者反而少，原因就在於它輸在 “易懂，易用”這兩項上面。