設計軟體架構時要保持彈性,這已是老生常談。架構設計就是一堆取捨(trade-offs),大家也都知道。可是如何保持彈性、取誰捨誰,又是個大哉問。而我想說的是,設計人員在心態上保持彈性、謙虛,也很重要。在面對一個全新設計的軟體產品時,很早就開始優化(optimization),可能是不太謙虛的一個徵兆。
《The Art of Computer Programming》的作者 Donald Knuth 博士說過:「太早優化是萬惡之源(premature optimization is the root of all evil)。」然而何謂「太早」,各人解讀不同,早、晚的界線也不是那麼清楚....直到我們被這些過早優化的設計回過頭來狠咬一口。
比如說,資料透過網路傳輸時,資料量要盡量壓到最小,回應時間要盡可能的短。
如果很確定應用程式將來運行的硬體環境有某些限制條件,在設計時保持這樣一個警覺是好事。可是,在沒有任何實測數據的情況下,就從多種解決方案中決定採用「資料傳輸量最小」的那個方案,很容易顧此失彼。有沒有可能,某個次佳方案雖然傳輸量稍微多一點,但在其他方面卻有更多好處呢?例如開發成本更低、更容易維護、擴充等等。
一旦架構設計的決策方向錯誤,往後不知道要付出多少無謂成本,往偏斜的方向努力不懈。結果可能是:當初考量的那個點是有達到甚至超越預期水準,然而卻因為這個部分而導致軟體的整體設計過於複雜或成本太高(繞遠路、做白工),產品遲遲無法上線。
除非我們能夠事先模擬一個很接近真實世界的測試環境(軟硬體設備、網路頻寬等),否則在軟體真正上線之前,一切有關效能優化的假設、取捨的依據,其實比較像是猜測,不是嗎?
我覺得,如果是猜測(而非實測過),設計時還是謙虛一點、開放一點會比較好。
P.S. 這裡並不是指大量兜字串時要不要用 StringBuilder 這類明顯而細微的優化。
P.S. 不知不覺,我已經習慣把「最佳化」優化成「優化」了 XD
《The Art of Computer Programming》的作者 Donald Knuth 博士說過:「太早優化是萬惡之源(premature optimization is the root of all evil)。」然而何謂「太早」,各人解讀不同,早、晚的界線也不是那麼清楚....直到我們被這些過早優化的設計回過頭來狠咬一口。
「We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.」 --- Donald Knuth
比如說,資料透過網路傳輸時,資料量要盡量壓到最小,回應時間要盡可能的短。
如果很確定應用程式將來運行的硬體環境有某些限制條件,在設計時保持這樣一個警覺是好事。可是,在沒有任何實測數據的情況下,就從多種解決方案中決定採用「資料傳輸量最小」的那個方案,很容易顧此失彼。有沒有可能,某個次佳方案雖然傳輸量稍微多一點,但在其他方面卻有更多好處呢?例如開發成本更低、更容易維護、擴充等等。
一旦架構設計的決策方向錯誤,往後不知道要付出多少無謂成本,往偏斜的方向努力不懈。結果可能是:當初考量的那個點是有達到甚至超越預期水準,然而卻因為這個部分而導致軟體的整體設計過於複雜或成本太高(繞遠路、做白工),產品遲遲無法上線。
除非我們能夠事先模擬一個很接近真實世界的測試環境(軟硬體設備、網路頻寬等),否則在軟體真正上線之前,一切有關效能優化的假設、取捨的依據,其實比較像是猜測,不是嗎?
我覺得,如果是猜測(而非實測過),設計時還是謙虛一點、開放一點會比較好。
P.S. 這裡並不是指大量兜字串時要不要用 StringBuilder 這類明顯而細微的優化。
P.S. 不知不覺,我已經習慣把「最佳化」優化成「優化」了 XD
沒有留言: