原文地址：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）
在我从事软件开发的那些年里，我见过到软件架构师的伤害要多于帮助。做为一个职业角色，如果我们解雇他们（我们自己），我们将节省很多钱。那怕我们仍付给他们薪水。
如果你工作在一个他们造成的伤害要多于他们所能阻止，你有两个选项：你可以尝试改善或在没有人的时候祈祷。