過度設計的例子，如何避免過度設計

設計的初衷是提高代碼質量。

在做代碼設計的時候，一定要理清楚，為什么要這樣設計，為什么要應用這種設計模式，這樣做是否能真正地提高代碼質量，能提高代碼質量的哪些方面。如果自己很難講清楚，或者給出的理由都比較牽強，沒有壓倒性的優勢，那基本上就可以斷定這是一種過度設計，是為了設計而設計。

設計的過程是先有問題后有方案。

我們先要去分析代碼存在的痛點，比如可讀性不好、可擴展性不好等等，然后再針對性地利用設計模式去改善，而不是看到某個場景之后，覺得跟之前在某本書中看到的某個設計模式的應用場景很相似，就套用上去，也不考慮到底合不合適，最后如果有人問起了，就再找幾個不痛不癢、很不具體的偽需求來搪塞，比如提高了代碼的擴展性、滿足了開閉原則等等。

過度設計的例子、設計的應用場景是復雜代碼

對于復雜代碼，比如項目代碼量多、開發周期長、參與開發的人員多，前期要多花點時間在設計上，越是復雜代碼，花在設計上的時間就要越多。不僅如此，每次提交的代碼，都要保證代碼質量，都要經過足夠的思考和精心的設計，這樣才能避免爛代碼效應（每次提交的代碼質量都不是太好，最終積累起來整個項目的質量就變得很差）。相反如果只是一個簡單的項目，代碼量不多，開發人員也不多，那簡單的問題用簡單的解決方案就好，不要引入過于復雜的設計模式，將簡單問題復雜化。

持續重構能有效避免過度設計。

應用設計模式會提高代碼的可擴展性，但同時也會帶來代碼可讀性的降低，復雜度的升高。一旦我們引入某個復雜的設計，之后即便在很長一段時間都沒有擴展的需求，我們也不可能將這個復雜的設計刪除，整個團隊都要一直背負著這個復雜的設計前行。為了避免錯誤的需求預判導致的過度設計，建議采用持續重構的開發方法。持續重構不僅僅是保證代碼質量的重要手段，也是避免過度設計的有效方法。在真正有痛點的時候，再去考慮用設計模式來解決，而不是一開始就為不一定實現的未來需求而應用設計模式。