下面就是著名的西直門橋的右轉指示圖：
這個橋在從兩個方向上過來的右轉都必須經過三圈或者五圈。任何新司機都懼怕這裡，任何老司機都激動這裡。
就因為此，還有人編寫了一段笑話：
中國聯通壯告西直門立交橋設計者
當然了，這些只是笑談。不過也證明了這個橋的知名度。不過，我今天只是想聊聊它的設計！
下面是網上關於原設計者的一段描述：「記者通過查詢資料得知西直門立交橋的設計者叫聶大華。她當時設計此橋的主要依據是通過定向匝道解決主車道車流問題。根據模型測試分析車流的主流向、主流量。據說當時這種方式被認為是最科學的一種立交的方式，避免了以往老橋各方向車流交叉的矛盾，使得西二環的通行能力從原來的每小時通行９０００輛增加到了１２０００輛。「由於建橋受到土地面積的限制，其他被認為是次要的方向就必須盤橋。」可事實卻是：主車流車速沒快起來，而次要車流則更堵了。」
我相信，在我們開始否認這個設計之前，必須清楚地了解到設計者的思路。不了解而開罵，那是為了洩氣。就算罵也要罵在點上才行。而且，我寫這些，只是從設計角度看看這座橋。
一、目的良好。增加二環的通行量，這個就是在現在交通擁擠的北京，也是非常正確的。捨棄一些「可以捨棄」的道路，保證主要路段的執行效率。從本質上沒有問題。
二、建模設計。使用模型來進行測試，保證達到預期效果。建模這種手段在我們做軟體設計的方法中也非常重要。比如說系統的效率問題，必須先建模進行測試，看看是否可以承受最大壓力。
這些都沒問題，那麼，問題出在**了呢？
一、忽視使用者使用習慣。右轉彎的慣例顯然沒有遵守。就這一點上，是最致命的設計失誤。事實上，其他方面都是可以被使用者原諒的。乙個架構師必須充分考慮使用者的使用習慣，才有可能贏得使用者的滿意。就算通行效率沒有提高太多，使用者也不至於到罵人的程度。
二、架構師的基本功不紮實。很多人喜歡談原則，但是到具體執行設計的時候，基本功往往決定了細節，而細節決定成敗。
三、沒有多個方案比較。很多問題的產生，都是因為只有一種方案的。試問，次要路線的盤橋方式只有一種嘛？
四、橋的設計不必軟體的設計。後期變更的機會不大。因此對效率的**，必須做到足夠充分，顯然這位架構師的模型還是有問題，應該進行多方面校驗。
五、業務專家不夠。架構師自己應該充分體驗一下設計。將自己想象成使用者去進行體驗設計，能發現很多問題。顯然這位架構師不像是個司機。唉，那就應該找乙個道路專家，或者汽車專家進行輔助設計。
話說回來了，這些都是事後諸葛亮。真正設計的時候，很難顧及到所有。越是重要的設計，就越應該多方面驗證。我相信，會避免很多問題。
也談設計模式Facade
門面模式提供乙個高層次的介面，使得子系統更容易使用。子系統與外部系統的通訊必須經過乙個統一的facade進行處理。內部系統的互動在facade中進行整合，這樣，對於外部系統的使用者就不用關注內部系統的複雜性。而有facade的存在也降低了內外系統的耦合。1.內部系統 1.1 內部子系統1 對茶的操作...
架構師速成6 5 也談設計模式
回頭來回顧之前寫的文章，發現初中階段的內容缺了一塊很重要的內容就是設計模式。設計模式是程式設計師的另乙個g點，無論吹牛，還是面試，還是設計都會秀一下設計模式，這也奠定了設計模式不可動搖的地位。我主要講一下設計模式如何學習，哪些虛的我就不講了。找2本書就可以了，大話設計模式和head first設計模...
架構師速成6 5 也談設計模式
回頭來回想之前寫的文章，發現初中階段的內容缺了一塊非常重要的內容就是設計模式。設計模式是程式猿的還有乙個g點。不管吹牛。還是面試，還是設計都會秀一下設計模式。這也奠定了設計模式不可動搖的地位。我主要講一下設計模式怎樣學習，哪些虛的我就不講了。找2本書就能夠了，大話設計模式和head first設計模...