目錄

設計軟體是困難的，所以你對如何構建一個模組或系統的最初想法不太可能產生最好的設計。如果您為每個主要的設計決策考慮多個選項，您將得到一個更好的結果：設計兩次。

假設您正在為GUI文字編輯器設計管理檔案文字的類。第一步是定義類將呈現給編輯器其餘部分的介面；與其選擇第一個出現在腦海中的想法，不如考慮幾種可能性。一種選擇是面向行的介面，它具有插入、修改和刪除整行文字的操作。另一個選項是基於單個字元插入和刪除的介面。第三種選擇是面向字串的介面，它可以跨行操作任意範圍的字元。你不需要確定每種選擇的每個特性;在這一點上，勾勒出幾個最重要的方法就足夠了。

嘗試選擇那些彼此截然不同的方法，這樣你會學到更多。 即使您確定只有一種合理的方法，無論您認為第二種設計有多糟糕，都要考慮採用第二種設計。思考該設計的弱點並將其與其他設計的特點進行對比將是有益的。

在你草擬出可供選擇的設計方案後，列出每種方案的優缺點。對於介面最重要的考慮是對於高階軟體的易用性。在上面的例子中，面向行的介面和麵向字元的介面都需要在使用text類的軟體中進行額外的工作。在部分行和多行操作(如剪下和貼上選擇)期間，面向行的介面將需要更高級別的軟體來分割和連線行。面向字元的介面將需要迴圈來實現修改多個字元的操作。這也值得考慮其他因素：

• 一種替代方案的介面是否比另一種簡單?在文字示例中，所有的文字介面都比較簡單。
• 一個介面比另一個介面更通用嗎?
• 一個介面是否能夠比另一個介面更有效地實現?在文字示例中，面向字元的方法可能比其他方法慢得多，因為它需要對每個字元分別呼叫文字模組。

一旦你比較了不同的設計，你就能更好地確定最佳的設計。最好的選擇可能是一個備選方案，或者您可能會發現可以將多個備選方案的功能組合到一個比任何原始選擇更好的新設計中。

有時，沒有一種選擇特別有吸引力，當這種情況發生時，看看是否可以提出其他方案。使用您在最初的替代方案中確定的問題來驅動新的設計。如果您正在設計文字類，並且只考慮面向行的和麵向字元的方法，那麼您可能會注意到每種替代方法都很笨拙，因為它需要更高級別的軟體來執行額外的文字操作。這是一個危險訊號:如果有一個文字類，它應該處理所有的文字操作。為了消除額外的文字操作，文字介面需要更緊密地匹配發生在高階軟體中的操作。這些操作並不總是對應於單個字元或單個行。這一行推理應該會為文字提供面向範圍的API，從而消除了早期設計的問題。

兩次設計原則可以應用於系統的許多層次。對於模組，您可以首先使用這種方法來選擇介面，如上所述。然後您可以在設計實現時再次應用它：對於text類，您可以考慮諸如行連結串列、固定大小的字元塊或“間隙緩衝區”之類的實現。“實現的目標和介面的目標是不同的：對於實現來說，最重要的是簡單性和效能。在系統的更高層次上探索多種設計也很有用，比如何時為使用者介面選擇特性，或者何時將系統分解為主要模組。在每種情況下，如果您可以比較幾個備選方案，就更容易確定最佳方法。

設計兩次並不需要花費很多額外的時間。對於較小的模組(如類)，您可能不需要超過一兩個小時的時間來考慮替代方案。與您將花費幾天或幾周的時間來實現這個類相比，這只是一小部分時間。最初的設計實驗很可能會產生一個更好的設計，這將比花兩次時間來設計要好得多。對於較大的模組，您將在最初的設計探索中花費更多的時間，但是實現也會花費更長的時間，而且更好的設計的好處也會更大。

我注意到“兩次設計”的原則有時很難被真正聰明的人所接受。當他們長大後，聰明的人發現他們對任何問題的第一個快速想法就足以獲得一個好成績；沒有必要考慮第二種或第三種可能性。這很容易養成不好的工作習慣。然而，隨著這些人年齡的增長，他們會被提升到越來越困難的環境中。最終，每個人都會到達一個臨界點，你的第一個想法不再足夠好；如果你想獲得真正好的結果，你必須考慮第二種可能，或者第三種，不管你有多聰明。大型軟體系統的設計就屬於這一類：沒有人有足夠的能力在第一次嘗試時就把它做好。

不幸的是，我經常看到聰明的人堅持執行他們腦海中出現的第一個想法，這導致他們沒有發揮出他們真正的潛力(這也讓他們在工作中感到沮喪)。也許他們潛意識裡認為“聰明人第一次就能成功”，所以如果他們嘗試多種設計，那就意味著他們根本不聰明。事實並非如此。這並不是說你不聰明，問題是真的很難。此外，這是一件好事：解決一個需要仔細思考的難題要比解決一個根本不需要思考的簡單問題有趣得多。

兩次設計的方法不僅提高了你的設計，也提高了你的設計能力。設計和比較多種方法的過程將教會您使設計更好或更差的因素。 隨著時間的推移，這將使你更容易排除糟糕的設計，並專注於真正偉大的設