一级建筑师 系统分析师_“建筑师”应该扮演角色，而不是职位

一级建筑师 系统分析师

当高级开发人员变得…更高级时会发生什么？ 他们经常被晋升为“建筑师”。 有时候，如果建筑师看到了“更大的图景”，那么他们不一定是开发人员。 最后，通常会有一个人担任“建筑师”的职位。 决定要开发的系统的体系结构的人。 在较大的公司中，有“建筑师委员会”，每个团队的指定建筑师在那里聚集并决定明智的事情……

但是我认为拥有“建筑师”的职位是一个坏主意。 建筑师是建筑中的一个职位–在这里有意义，因为您不能在项目中期更改和调整建筑。 但是软件体系结构是灵活的，不应严格定义。 而且开发和体系结构是如此交织，让一个“说要做什么”和另一个“去做”的人没有多大意义。 它会产生各种各样的问题，主要是因为架构师通常没有完全想象实现会如何发挥作用。 如果架构师已经很长时间没有编写代码，那么他们往往会忽略“实现细节”，而只进行抽象。 但是， 抽象总是无时无刻不在泄漏 ，如果没有特定的实现就只考虑抽象，这几乎不是一个可行的解决方案。

这是我的第一个主张–如果您不完全知道如何在下面编写整个代码，那么您就不能成为一名优秀的架构师。 不，通常不是“简单编码”。 而且，如果您已经当了多年的架构师，并且因此多年没有编写代码，那么您几乎肯定不是一个好的架构师。

是的，好的，特别是您可能是一个好的建筑师。 也许在您的特定公司中，让某个人坐在象牙色的抽象塔中并规定牡丹如何集成并实现它是有道理的。 但是即使在那种情况下，也有更好的方法。

架构师应该扮演一个角色。 每个高级团队成员都可以而且应该担任建筑师的角色。 每个团队不必一个人。 实际上，最好有更多。 在类似于功能设计会议的会议中讨论体系结构，明确的想法是将由您来实施整个过程。 任何过大的设计（建筑师经常对此感到愧gui）都必须摆在自己面前-“我是想写所有这些样板书，还是有一种简单而优雅的方法”。

职位是“软件工程师”。 角色可以是“ scrum master”，“ architect”，“ continuous Integration Officer”等。如果公司需要“ architect's Council”来决定系统之间的“大图”集成，则开发人员可以提名某人参加这些会议。 –可能是最有知识的。

我知道架构师现在在想什么-开发人员不理解或不应打扰的高层担忧。 错误。 如果您的开发人员不了解更高层次的体系结构问题，那么您迟早会遇到问题。 是的，他们应该为更大的画面所困扰，因为为了使您正在编写的代码适合更大的画面，您应该非常熟悉它。

还有一个方面，那就是团队成员的态度和互动动态。 如果某人被“提升”为“架构师”，而又不是特别优秀或受人尊敬的开发人员，则可能会损害团队士气。 另一方面，被提拔为“建筑师”的人可能会变得过于自信，以至于仅仅因为他们这样认为就提出了设计决策，尽管他们提出了很多反对意见。

因此，理想情况下（这是我的第二个主张）–摆脱建筑师的职位。 确保您的高级团队成员参与体系结构讨论和决策制定-这样他们将更有动力，他们将对他们的开发工作应该实现的目标有更清晰的了解。 最重要的是，架构决策不会脱离日常开发“真实世界”，也不会不必要地变得复杂。

翻译自: https://www.javacodegeeks.com/2017/06/architect-role-not-position.html

一级建筑师 系统分析师