#1获得开发人员的尊重
我想概括一下,说开发人员似乎是那种不想忍受比他们绝对必须更多的废话的人。 因此,尝试在大公司中找到能打动开发人员的典型政治手法是行不通的。 其中包括销售技巧,PowerPoint演示等。这些技能对于传达方向或愿景很重要,但不会给开发人员留下深刻的印象。 获得他们尊重的最尝试,最真实的方法是与他们一起编码。 确实是的。 好的建筑师代码。 坏人崇高。 后者似乎比前者更多。 为您出色的“架构化”解决方案编码将有助于赢得他们的尊重。 但这在另一个领域也有帮助。 我遵循的第二条规则。
#2意识到您不能在纸上设计系统。
源代码不是您要设计的产品。 源代码本身就是设计。 因此,当我担任架构师一职时,我会提醒自己,提出图表和流程可视化不是设计。 这是一个头脑风暴,有助于在我脑海中建立模型。 但是,如果不将该模型放入代码中,您将不知道它的真实行为或应如何更改已设计的解决方案。 相信我 在几乎所有情况下,都应该对其进行更改。 换句话说,开发人员和架构师之间应该存在一个反馈循环。 而且,如果您遵循规则#1,您将直接在那里观察您的解决方案如何在代码中发挥作用。
#3不要继续构建
不要迷恋最新,最有光泽的技术,不要将其推向开发人员,而要使其经受严峻的现实生活中的考验。 玩新技术很有趣。 我一直都在做。 但是我是在日常工作之外做的。 仅仅因为某些技术看起来很酷就牺牲了团队,软件和业务模型的稳定性,如果您知道这不是解决企业问题的一种可敬的方式,那么Google可能会雇用您。 即使您已经看过足够的关于这种新技术将如何成为神奇的子弹的销售演示,也要抵制尝试灌输团队其余成员的诱惑,直到您将新技术解决了现实生活中的软件问题为止。孵化器。
我一直在篱笆的两边,与一群优秀的开发人员和建筑师合作,这是我的三个原则。 有人要添加什么吗?
参考:在Christian Posta Software博客上成为JCG合作伙伴 Christian Posta 的更好的企业架构师 。
翻译自: https://www.javacodegeeks.com/2012/04/being-better-enterprise-architect.html