謙卑的架構師

　　Johannes Brodwall是一位程式設計師、解決方案架構師、使用者組與會議組織者、會議演講者與佈道師。Johannes一直在不遺餘力地將敏捷原則應用到大型軟體專案中，不過他真正感興趣的是與全世界的程式設計師分享更多關於程式設計的有趣經驗。目前，Johannes就職於Exilesoft，擔任首席科學家一職。近日，Johannes撰寫了題為謙卑的架構師一文，探討了架構師所應該遵循的幾個原則，在程式設計師群體中引起了很大的反響。

　　謙卑並不是軟體架構師一個非常常見的特質。我曾與一些可怕的架構師共事過，最近也與一位非常棒的架構師合作過。基於此，我根據每個架構師都喜歡的方式將我過去的經驗匯聚起來，以規則集的形式寫出來，與大家一起分享並討論。

　規則0：不要愚蠢地做出假設

　　看起來有些架構師會覺得一旦讓開發者自行處理某些事情，那麼他們就會像猴子那樣雜亂無序。根據我的經驗，這種情況其實是很少會出現的。只有一種情況會讓開發者做傻事，那就是他們在心裡默默牴觸架構師。如果遵循著這條原則，那麼其他的都將是細節問題。

　規則1：你可能是錯誤的

　　在審查某人的設計想法時，我更傾向於以坦誠布公的方式詢問問題。也許我覺得開發者忽略掉了某個關鍵的事實，比如說併發等。對於這種情況有幾種不同的方式：

• 架構師：你不能那樣做，因為它破壞了編碼規範。
• 架構師：你不能那樣做，因為當同時有幾個使用者時是不安全的。
• 架構師：你想過它是如何處理幾個使用者的情況的麼？
• 架構師：你提出的解決方案是如何處理幾個使用者的情況的？

　　親愛的架構師們：請對這些方式評級，按照從最差到最好的方式排序（提示：這是個很簡單的事，不過很多架構師卻還是做不好）。

　規則2：對技術保持謹慎的態度

　　每種技術都是有代價的，而很多技術所帶來的好處是非常有限的。下面是我使用過的一些代價要遠遠高於所帶來的好處的一個技術列表（如果不知道也沒關係，關鍵在於數量）：JavaServer Pages、Java Server Faces、JAX-WS、Hibernate、Spring、EJB、Oracle SOA Server、IBM WebSphere、Wicket、Google Web Toolkit、Adobe Flex、JBoss jBPM、JMS（所有實現）與 JBoss。下面是我非常喜歡使用的一個技術列表：JUnit、Jetty、Joda-time與Java標準版。

　　看看下面的對話吧：

• 架構師：你應該使用技術X。
• 我：我看過技術X，不過不清楚怎樣通過它來解決業務問題。
• 架構師：你的意思是？
• 我：這是我們需要做的事情。。。這是技術X所能解決的問題。。。我不知道他們之間是如何匹配的。
• 架構師：那你的建議是什麼呢？
• 我：我覺得可以通過普通的Java來解決這個問題。事實上，昨天晚上我已經做了一個很不錯的概念驗證。
• 架構師：太酷了，我們就這麼幹吧。

　規則3：一致性並不如你所想象的那麼重要

　　我總聽到有人這麼說：

架構師：沒錯，我知道這種方式看起來很笨拙，不過你必須這麼做。你也看到了，如果不這麼做，那麼系統就會變得不一致，也難以維護。

　　好吧，我確實很少接觸維護方面的工作，不過我知道在處理任何系統時，最困難的部分在於理解系統的業務邏輯。系統X（有自己的一套業務邏輯）與系統Y（有另一套業務邏輯）是否是一致的並不那麼重要。如果說系統X非常複雜的原因在於它為了保持與系統Y的一致性而增加了很多層次，那我真的要抓狂了。不同的上下文有不同的權衡。還記得規則0嗎，開發者在給定的上下文進行開發，那麼他就會為該上下文建立一個很好的解決方案。另外，我還從來沒有見過規模不大的系統非常複雜，等系統逐步變大時就變得更好維護了。如果程式設計師感到不爽的原因只是因為有些程式碼的花括號使用的是一種風格，而另外一些程式碼則採用了其他風格，那麼我也真的要崩潰了。

　規則4：至底向上的一致性要優於自上而下的一致性

　　我有一種方式可以實現系統中更多的一致性：

• 建立一個參考應用，並使用易於遵循的架構。如果這件事幹得好，那麼開發者們就會始終記得不要偏離這個架構。除非他們不想，否則這麼做就沒問題。
• 培育一種互助的文化。能夠看到彼此程式碼的開發者要比那些只看到自己程式碼的具有更好的一致性。結對程式設計、程式碼審查以及技術分享講座都有助於這種文化的培育。

　規則5：跨系統的重用是次要的優化

　　重用會導致耦合。如果系統X與系統Y重用了某些功能，系統X需要修改某個功能，這就會影響到系統Y。至少，系統X的開發團隊必須要對重用的功能建立一個私有的分支，這意味著該功能實際上並不會再被重用了。更糟糕的是，被重用的功能的某個改變會導致系統Y出現Bug。在進行跨系統重用時，你所重用的應該是要麼穩定的（比如說，Java SE平臺，或是某個非常穩定的功能），要麼是策略性的。根據策略重用，我指的是整合了資訊而不僅僅是複製功能的服務。換句話說，重用要麼是使用，要麼是整合。重複是你的朋友。

　規則6：分清規則與教條

　　任何編碼標準都需要有原則，原因有3：

• 不安全：程式碼的Bug只會在某些情況下才能顯現出來
• 費解的：我不理解接下來的事情
• 異端：某些人不喜歡某些程式碼風格

　　如果有一條規則說到“所有屬性都必須要有JavaDoc註釋”，那麼你認為這是個安全問題、讓人費解的問題還是異端呢？看看下面這個程式碼示例：

/**
 *  Contains the name value of the object
 */
private String name;

　　如果規則這樣說到“左花括號不能另起一行”，那麼這條規則呢“花括號的風格應該保持一致”？這是個什麼問題呢？我們應該將更多的精力放在編寫恰當的程式碼上，而不是被這些該死的一致性搞得心煩意亂。

　規則7：請保持謙卑的態度

　　在從事軟體開發的這些年中，我看到軟體架構師的所作所為帶來的更多是損害而非幫助。作為一個專業的角色，我認為如果能將這些架構師從團隊中剔除出去將會節省不少開支。如果你所從事的職業給團隊帶來的弊大於利，那麼你有兩個選擇：一是不斷改進自己，二是寄希望於沒人會注意到你。