第16章 小心鸿沟

我们这个行业对软件架构的角色真是又爱又恨，因为架构师“闭门造车”的独裁，不参加构建可用软件的任何实际工作，很多组织干脆取消了它。这种坏名声损害了IT行业，阻挠了项目的成功，需要改变。

开发者关注底层细节

如果你正在一个软件开发项目中工作，看看团队其他人吧。团队的结构是怎样的？每个人的角色和责任都定义好了吗？谁负责大局？性能、可伸缩性、可用性、安全性等由谁负责？

我们都梦想在这样的团队中工作：所有人都经验丰富，从代码到架构，对软件考虑得面面俱到。然而现实并非如此。我合作过的大多数团队，成员经验参差不齐，有些甚至刚接触IT这一行，另一些则“接触过几次”。作为软件开发者，代码是我们主要的关注点，但如果你的团队只关注底层细节，会发生什么？想象有一个用上了所有最新编程语言特性的代码库，代码很好地解耦，测试也完全自动化。这个代码库的结构和格式都堪称完美，但如果系统在部署到生产环境时有可伸缩性的问题，一切就毫无用处。

闭门造车的独裁架构师

软件架构角色不同于开发者角色。有些人把它看作开发者的上级，有些人则看作同级。不管你怎么看，架构师都要负责“大局”。很多团队了解软件架构的重要性，会找来一个有着受人尊敬的“架构师”头衔的人，却只是把他们硬塞在凌驾于团队的位置上。发生任何事，都会在架构师和原本要一起工作的团队之间造成巨大的鸿沟，让架构师立刻被孤立起来。

拉近距离

可惜，很多软件团队里，在开发团队和架构师之间都有这个不必要的鸿沟，特别是当架构师被看作是只会下命令的独裁者。这导致了几个问题：

❑ 不管架构师的决策是否正确，开发团队都不尊重他；

❑ 开发团队变得缺乏积极性；

❑ 重要决策因为职责不明而无人负责；

❑ 因为没有人负责大局，项目最终苦不堪言。

幸好，有一些简单的方法能从两方面解决这个问题，毕竟，软件开发是一个团队行为。

如果你是软件架构师

❑ 包容与合作：让开发团队参与软件架构的过程，帮助他们了解大局，认同你所做的决策。确保每个人都明白决策背后的原理和目的，会对此有所帮助。

❑ 动手：如果可能的话，参与一些项目的日常开发工作来提高你对架构交付的理解。根据你的角色和团队规模，这可能会不太现实，那就通过其他方式来了解底层的进展，比如协助设计和代码评审。了解软件的底层如何工作会让你更透彻地了解开发团队对架构（比如：他们是否对其视而不见）的感受，也会为你提供有价值的信息，可以用来更好地塑造/影响架构。如果开发者感到痛苦，你也要感同身受。

如果你是软件开发者

❑ 了解大局：花些时间去了解大局将帮助你了解做出架构决策的语境，增强你对系统整体的理解。

❑ 挑战架构决策：有了对大局的了解，你现在就有机会挑战眼前的架构决策。架构应该是一个合作的过程，而不是由那些不参与项目日常工作的人说了算。如果你发现有些事情你不理解或不喜欢，挑战它。

❑ 申请参与：很多项目都有一个负责架构的架构师，这个人通常会承担所有的“架构工作”。如果你是一个开发者，想要参与其中，提出来。你说不定帮了架构师一个忙！

软件架构的合作方式

我这里已经谈到的内容很容易适用于中小型项目团队，但对于大型团队，事情就变得复杂了。言外之意，大型团队意味着更大的项目，更大的项目意味着更大的“大局”。无论项目规模如何，确保大局不被忽视是成功的关键，而这个重任往往落在架构师的肩上。减少开发者和架构师之间不必要的鸿沟，可以让大多数软件团队从中获益，双方都可以努力减少这个鸿沟。开发者可以增加他们的架构意识，而架构师可以加强与团队其他人的合作。要确保你注意到了鸿沟，其他人也会跟随。