程序员好几年才能成为架构师
企业架构师似乎越来越多地参与“尝试新事物”或推翻技术或实施建议（否定命令），而不必费劲或无需编写任何代码。 我已经在很多地方观察到了这一点，无论是与建筑师一起工作还是与开发人员一起工作。 从这些观察中，我为自己成为优秀的企业架构师提出了三个规则，我认为这些规则值得分享和讨论。
＃1获得开发人员的尊重
我想概括地说，开发人员似乎是那种不想忍受比绝对更多的胡说八道的人。 因此，尝试在大公司中找到能打动开发人员的典型政治策略是行不通的。 其中包括销售技巧，简报演示等。这些技能对于传达方向或愿景很重要，但不会给开发人员留下深刻的印象。 获得他们尊重的最尝试，最真实的方法是与他们一起编码。 确实是的。 好的建筑师代码。 坏人崇高。 后者似乎比前者更多。 为您出色的“架构化”解决方案编码将有助于赢得他们的尊重。 但这在另一个领域也有帮助。 我遵循的第二条规则。
＃2意识到您不能在纸上设计系统。
源代码不是您要设计的产品。 源代码本身就是设计。 因此，当我担任架构师职务时，我会提醒自己，提出图表和流程可视化不是设计。 这是一个头脑风暴，可以帮助我在脑海中建立模型。 但是，如果不将该模型放入代码中，您将不知道它将如何真正发挥作用，或者不应该更改体系结构的解决方案。 相信我 在几乎所有情况下，都应该对其进行更改。 换句话说，开发人员和架构师之间应该存在一个反馈循环。 而且，如果您遵循规则＃1，您将直接在那里观察您的解决方案如何在代码中发挥作用。
＃3不要继续构建
不要迷恋最新，最有光泽的技术，不要将其推向开发人员，而要使其经受严峻的现实生活中的考验。 玩新技术很有趣。 我一直都这样做。 但是我是在日常工作之外做的。 仅仅因为某些技术看起来很酷，就牺牲了团队，软件和业务模型的稳定性，如果您知道这不是解决企业问题的可取方法，那么Google可能会雇用您。 即使您已经看过足够的关于这种新技术将如何成为神奇的子弹的销售演示文稿，也要抵制试图将团队的其他成员灌输的诱惑，直到您将新技术解决了现实生活中的软件问题为止。孵化器。
我去过栅栏的两边，与一群优秀的开发人员和建筑师合作过，这是我的三个规则。 有人要添加什么吗？
