谦卑的架构师

╰+攻爆jí腚メ 2022-09-19 13:30 169阅读 0赞

本文来源于我在InfoQ中文站原创的文章，原文地址是：[http://www.infoq.com/cn/news/2013/12/humble-architects][http_www.infoq.com_cn_news_2013_12_humble-architects]

[Johannes Brodwall][]是一位程序员、解决方案架构师、用户组与会议组织者、会议演讲者与布道师。Johannes一直在不遗余力地将敏捷原则应用到大型软件项目中，不过他真正感兴趣的是与全世界的程序员分享更多关于编程的有趣经验。目前，Johannes就职于Exilesoft，担任首席科学家一职。近日，Johannes撰写了题为[谦卑的架构师][Link 1]一文，探讨了架构师所应该遵循的几个原则，在程序员群体中引起了很大的反响。

谦卑并不是软件架构师一个非常常见的特质。我曾与一些可怕的架构师共事过，最近也与一位非常棒的架构师合作过。基于此，我根据每个架构师都喜欢的方式将我过去的经验汇聚起来，以规则集的形式写出来，与大家一起分享并讨论。

## 规则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：请保持谦卑的态度 ##

在从事软件开发的这些年中，我看到软件架构师的所作所为带来的更多是损害而非帮助。作为一个专业的角色，我认为如果能将这些架构师从团队中剔除出去将会节省不少开支。如果你所从事的职业给团队带来的弊大于利，那么你有两个选择：一是不断改进自己，二是寄希望于没人会注意到你。

[http_www.infoq.com_cn_news_2013_12_humble-architects]: http://www.infoq.com/cn/news/2013/12/humble-architects
[Johannes Brodwall]: http://architects.dzone.com/users/jb30665
[Link 1]: http://architects.dzone.com/articles/humble-architects