在QCON大會上，Michael?Nygard，以及?李偉專家都提到了一個概念，容錯能力。

衡量軟件架構最佳的一個很重要的因素就是看軟件的容錯能力。沒有容錯能力的軟件，哪怕你QA都非常優秀，但一發生故障就出現集聯失效，如同雪崩般，整個系統癱瘓，那么這樣的一個系統也是個失敗的架構。

那么如何做到能將錯誤降低到比較能接受的程度呢。其中有提到將各個服務components解耦合，這是個相當籠統的原則。那么作為一個開發者，在開發軟件的過程中，怎么能做到更好的規避這方面的風險呢，設計模式就是用來解決這方面的問題，但系統的錯誤總是不可避免的，于是在與會者與Michael?Nygard提問的過程中，引出另一個概念，那就是反模式。

上網查了下，反模式的概念在國外十年前就提出來了。在1998年出版的《反模式——危機中軟件、架構和項目的重構》（AntiPatterns——Refactoring?Software,?Architectures,?and?Projects?in?Crisis）。一書中的作者這樣定義反模式：

反模式是描述對產生絕對負面結果的問題的一種常用解決方案的字面形式。

由于我們在軟件開發過程中，利用反模式可以幫我們總結一些經常犯的規律性錯誤，研究這些錯誤，能讓我們規避風險。

《Bitter?Java》里面提到對我們很有用的東西，關于反模式的步驟：

識別問題。在java編程中，問題可能是錯誤、性能問題、難于維護的類、不斷增大的內存占用量。

建立模式。隨著不斷深入開發周期，修正一個錯誤的開銷將成指數級上升。當你建立問題的模式時，你就給了自己在開發周期的更早階段識別和修正更多問題的機會，你的獲得也將數以倍計。使這個價值鏈向上移動的關鍵就在于建立模式，然后盡可能廣泛地根據反模式操作。

重構代碼。在這一步中，你將重構導致問題的代碼。這一步是一個簡單的錯誤修正，它適用于你迄今為止識別出所有問題實例。你應該花時間去做一個完整的修正，而不是僅僅打一個補丁了事。

宣傳解決方案。你在這里確保碰到的問題的其他人懂得如何修正問題，并確保可能碰到陷阱的其他人知道要避開它。

修正過程。修正可以采用很多不同的方式。改進測試案例可以快速地識別衰退，修正每日過程或通信渠道可以在問題發生之前預防它們。補充編碼標準幾乎能夠消除某些類型的編碼錯誤，如關于放置花括號或注釋的錯誤。

書中還這樣總結：這些步驟采用的方法是從特定到一般。你找到錯誤，然后建立模式、修正錯誤，最后修正過程。將其中某些步驟與你的日常例行工作相結合可以使你成為更好的程序員。但是，請不要再這里停下來。請利用你的反模式知識來修正過程，繼續使價值鏈向上移動，并讓你整個公司的程序員都變得更棒，你還能可以發布反模式幫助你甚至不認識的程序員。

在這里，我還想補充下我自己的觀點：

1.關于反模式的建立，是以經驗為鋪墊的。在經驗不足的情況下，我們要做的是，能多善于總結我們開發所遇到的問題，形成自己的反模式。

2.前面提到的一個步驟建立模式，很有敏捷開發的味道。

3.反模式還傳遞給我們這樣一個思想，簡單設計，不為明天而設計的思想。

4.溝通也是反模式的一個旋律。敏捷開發的核心也是溝通。

5..反模式不僅僅是單純為了解決問題，而是傳遞一種深入思考BUG，優化預防BUG渠道的思想。

總結

以上是生活随笔為你收集整理的规避软件架构风险之反模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。