有一个挺好玩的术语,用来指那些在标题中宣传“几个兴趣点”的博文或文章。举个例子,以“帮你摆脱债务的九个小窍门”为标题就符合要求。这种情况被称为“列举文”,它是把“列举”(list)与“文章”(article)这两个词合二为一(不过,对我而言,我总觉得有点像有人舔到了冰柱上)。

我通常不会用这种模板,但我觉得如果试着用用,看一下效果或许很有趣。我今天要说探讨的主题是架构师-开发者紧张局势的各种原因,这似乎特别符合列举的形式。

如果在一个地方开发者的角色非常明确时,那么架构师角色的定义通常会很模糊,而且在不同的组织中定义会有很大的变化。在一些工厂里,架构师就是长期的开发者,而在其他地方架构师则专门制作各种用户模式图表。

角色定义的模糊与多变,再加上架构师在名义上就高于开发者,这就导致了架构师与开发者之间容易产生摩擦。 虽然这种情况并不是总发生,但却是这个行业里普遍存在的。因此,我想分析一下架构师和开发者发生矛盾的五个原因。

架构师和开发者争吵的5个理由 1

架构师和开发者争吵的5个理由 - 敏捷大拇指 - 架构师和开发者争吵的5个理由 1

Spies




1、架构师角色分配不当

尽管行业内的公司对于软件架构师究竟做什么工作有相当大的差异,但万变不离其宗的观念是,架构师是技术上有成就的人。几乎一成不变的是,公司总是期望架构师起初可以做开发者,并且能力很强。

当这种情况行不通时,矛盾就要产生了。我曾见过有些公司把水平一般但懂很多专业知识的开发者提拔为架构师,这是人们可能指望从开发者队伍中选拔项目经理时看到的方式。他们的想法是“我们不想让他编码,但我们需要他在这个领域的专业知识。”而这可能与分析师和项目管理者的角色有关,对架构师来说,这是灾难性的分配。

公司也会用同样的理由雇佣新员工,进行人事变动。启用不懂技术的人,称他们为架构师,会极大地激怒开发者,引起他们的不满情绪。

组织的快速解决方案:给该角色的员工一个其他的工作头衔。




2、牛仔程序员

做架构师很辛苦。通常需要关注很多事情:业务要让人满意,时刻注意新的潮流,保证应用程序的可维护性,同开发者审查设计和代码,诸如此类。要想让这些事同时顺利进行,进行有效和有价值的沟通是必不可少的。

架构师和开发者争吵的5个理由 2

架构师和开发者争吵的5个理由 - 敏捷大拇指 - 架构师和开发者争吵的5个理由 2

yosemite

牛仔程序员痛恨这种经营模式。开发者要用团队协议和架构师批准使用的SQL Server 数据库作为应用数据,而不是建立自己的使用文件或内存数据库的不同特性集,因为这样做会所谓“更好”。架构师通常会视野更宽广,考虑的会更多,包括团队的特长,许可成本,未来的互操性,外部应用程序等。开发者给架构师带来这类意外,肯定让她抓狂。

组织的快速解决方案:说服或重新安排牛仔程序员。




3、象牙塔之上的架构师

在软件发展的过程中,象牙塔之上的架构师是一个典型的形象。这是指很久以前被提拔的架构师,已经完全脱离现代编码实践。他们可能五年甚至更久都没写过一行程序了,却梦想着把模式和宏伟的计划尽善尽美,或常常提出新的模式和宏伟的计划。

他们向发展团队提出这些想法,最常见的反馈就是被无视。这并不是开发者恶意为之,而是注重实际的决定,因为那些想法都是过时的,没有任何意义。通常情况下,象牙塔之上的架构师不会懂得这种变化,但久而久之,很明显,开发团队只是口头上回应他的设计。这意味着会产生严肃的争论。

组织的快速解决方案:让架构师写一些代码, 即便仅仅是偶尔的原型。




4、抱怨者

对架构师来说,另一个让人头疼的是开发者原型,也就是我所说的“抱怨者”。这是指真心喜欢程序设计语言、框架、技术栈、工具或模式的开发者。

你或许可以把抱怨者理解为那些莫名其妙在Java商店中获得一份工作,却从第一天开始就抱怨Java多么糟糕的人,他们认为如果把团队转向Ruby这些问题就都会解决了。这些抱怨者不思考业务案例或者可行的迁移策略,头脑中满是无尽的抱怨,抱怨每个人都正在做错误的、愚蠢的事。

大多数架构师都生活在一个平衡和需要权衡的世界里。尽管他们对今天刚刚发布的Javascript框架很感兴趣,但他们却不能提出建议并且监督公司转向这个框架。所以他们一听到公司是如何落后,不切换到这个框架时就会很愤怒。

组织的快速解决方案:让这些抱怨者聚在一起,制定一个可行的迁移实施方案,参与一个业务案例,否则就永远闭嘴,别再抱怨。




5、关系不明确

就像我之前在文中提到的,人们对于架构师的定义很模糊,而且因公司而异。但这一点不仅仅局限于角色的职责,还包括角色的权威。简而言之,在很多公司里,开发者常常想“我是否应该听从架构师呢-她是我的老板?还是只是在这比我更资深一些呢?”

这种不明确的关系会造成内部的紧张局势以及自身的紧张。没有人喜欢老板让自己去做自己认为很愚蠢的事情,事实上更糟的是,那个让你去做蠢事的人可能是你的老板,但你又不能真的确定他到底是不是。在另一方面,如果你不确定别人是否必须听从于你,你说话的语气可能更尖锐,更像在说教。这些都不利于架构师-开发者关系的发展。

组织的快速解决方案:让所有成员非常明确权力等级、角色分工以及责任分配。




和谐共处

任何不止一个人工作的地方,都很有可能产生分歧,任何两个以上的人工作的地方,都会产生政治。分歧和紧张的局势是不可避免的,但可以化分歧为生产力。

架构师-开发者的关系会引起潜在的分歧。但其实他们也可以互相指导,有效合作,共同进步。如果能够认识到对架构师和开发者的模糊定义以及一些行为会影响到他们之间的关系,并努力使定义更明确,减少不当行为,他们的关系就更有可能良性发展。如果开发者和架构师将会一起工作,那么如果他们能够合作共事,就是皆大欢喜了。




作者:李雪
这篇文章原本是我为NDepend博客所写的。你可以点这去网站查看原文。 进入网站后,可以下载原文。