原文地址：http://architects.dzone.com/articles/humble-architects
謙卑對于軟件架構師來說不是一個很常見的特征。在參與過一些讓人敬畏的架構后，并且最近還參與過一個令人愉快的項目，我以每個架構師都比較喜歡的方式總結了一些經驗：作為一套規則。
規則0：不要裝糊涂（Don't assume stupidity）
就像一些架構師假定開發人離開他們自己的設備，表現的將像個猴子。在我的經驗里，這是很少會發生的。我只看到過一種開發人員做事時犯糊涂的情況，就是默默的抗議和反對架構師。如果你認可這個規則，接下就是一些細節。
規則1：你可能是錯的（You may be wrong）
當審閱一些人的設計理念時，我更喜歡開誠布公的嘗試問一些問題。我認為開發人員可能忽略了一個關鍵點，如并發。這兒有一些應對這些場景的方法：
1. 架構師：“你不能那樣做，因為他可能破壞代碼設計準則。”
2. 架構師：“你不能那樣做，因為在多用戶情況下，他是不安全的。”
3. 架構師：“你是否想過多用戶時，他如何工作呢？”
4. 架構師：“你的方案如何應付多用戶場景呢？”
親愛的架構師：請從最不可能到最有可能得到一個盡可能好的系統的角度來評估這些方法。（提示：盡管有許多架構面對這個問題經常失敗，但這真的是一個項很容易的工作。）
規則2：謹慎選用技術（Be careful with technology）
每種技術都會帶來成本。大部分技術只能帶來很小的益處。
這兒有一個我所經歷過的成本大于益處的技術列表，因此將永不再使用（如果你不知道他們，也不用擔心。關鍵是數量。）：JavaServer Pages, Java Server Faces, JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMS（all implementations）, JBoss。
這兒有一個我比較愿意使用的技術列表：JUnit, Jetty, Joda-time, Java Standard Edition。
這兒有一個你可能想要嘗試或模仿的謙虛的交流方式：
架構師：你應該使用X技術。
我：我注意過X技術，我不認為他能幫助我解決業務問題。
架構師：你想表達的意思是什么呢？
我：哦，我需要做：...，這些是X技術假設的：...；我不認為他們匹配得上。
架構師：那么你建議使用什么來替代他呢？
我：嗯...，我認為我們可以使用普通的Java來解決它。事實上，我昨晚做了一個非常好的demo來證明其可行性（I made a pretty good proof-of-concept yesterday evening.）。
受人尊敬的架構師：很酷，讓我們用它吧。
規則3：一致性不像你認為的那樣重要（Consistency isn't as important as you think）
如果我有一便士，每次我都將會聽到...
架構師：“是的，我覺得這種方式可能比較笨，但你必須這樣做。你是知道的，如果不這樣做，系統會產生不一致并且是不可維護的”
相當然吧，我不常常做維護工作，但是我處理任何系統時，最困難的部分通常是理解系統的業務邏輯。X系統（有一套業務邏輯）還是Y系統（另一套業務邏輯）是不是一致性的問題在讓我失眠的任務列表中優先級都是被排的比較低的。
事實上，X系統是非常復雜的，因為他有十二層且每層都要和Y系統一致。現在這讓我特別生氣。不同的上下文環境有不同的權衡。
哦，是的：還記得規則0嗎？假如在一個給定的環境中，開發人員嘗試為這個環境創造一個好的解決方案。
哦，是的，另一件事：我從未見到過一個小的可維護的東西復雜到難以理解。復雜只是因為我們讓他發展壯大造成的。
哦，好的，還有另外一件事：如果因為開發人員中一些使用這樣的花括號方式，另外一部分使用另一種花括號方式編程，而導致開發人員大吵著遠離編碼。我將失去所有對人性的信仰。
規則4：自底向上的一致性不如從上到下的一致（Bottom-up consistency beats top-down consistency）
這兒有一種我有能力創建系統內部一致性的方法：
1. 使用更容易被沿用，而不是使用具有突破性的架構來創建一個參考應用。如果你這樣做的話，在遇到一些偏離架構的想法時，除非他們真的需要，在這種情況下他是非常好的，否則開發人員將會搖頭。
2. 培訓一種交叉交流的文化（Foster a culture of cross-pollination）：彼此互相看代碼的開發人員一致性要比僅僅看他自己代碼的開發人員更好。結對編程（Pair programming），代碼review（Code reviews）和培訓交叉技術分享會（Tech sharing sessions all foster cross-pollination）。
規則5：跨系統的策略重用不是最優選擇（Tactical reuse in across systems is suboptimization）
重用將會產生耦合。如果系統X和系統Y重用了一些功能，系統X需要對功能進行修改，這將會影響到系統Y。但至少，工作在系統X的團隊必須決定對重用的功能做一份私有副本。那意味著他不再被真正的重用。在極端情況下，由于對重用功能的修改，將造成系統Y產生bug。
當你跨系統重用時，那應該是穩定的（例如，Java SE平臺或別的東西，如此穩定，你不需要自己動手做它）或策略性的內容。關于策略重用，是指整合信息但不是僅僅復制功能的服務。
換句話說：重用應該是要不被使用，要不被集成。副本是你的朋友。
規則6：分辨規則和教條（Separate between rules and dogma）
有三種原因使用這個任何編碼規范中都有的規則：
1. 不安全（Unsafe）：代碼在某種場景（真實存在，非理論上）中會出現bug
2. 令人費解（Incomprehensible）：“我”不理解這是怎么回事
3. 旁門左道 （Heresy）：使用了大家都不喜歡的方式來寫代碼
抽查測試：是否你有這樣一個規則，“所有屬性必須有注釋”。關于安全問題，關于易理解問題或是旁門左道？使用這個例子做為標準：
/**
 * Contains the name value of the object
 */
private String name;
關于“在左花括號前面沒有換行”規則？關于“花括號樣式應該統一”的規則？是否符合不安全代碼，不易理解或旁門左道？
我們應該更關注在特定場景下寫適當的代碼，少關注一致性。
最后：謙卑（Be humble）
在我從事軟件開發的那些年里，我見過到軟件架構師的傷害要多于幫助。做為一個職業角色，如果我們解雇他們（我們自己），我們將節省很多錢。那怕我們仍付給他們薪水。
如果你工作在一個他們造成的傷害要多于他們所能阻止，你有兩個選項：你可以嘗試改善或在沒有人的時候祈禱。