IT架构5分：现代软件架构师

在开始写这篇文章之前，让我在开始时进行一些调整：

是的，当然，在任何不平凡的软件开发项目中都扮演着“软件架构师”的角色。 即使在敏捷项目，动态市场和诸如“新兴”之类的模糊术语中也是如此。 这样做的简单原因是团队中的出现和民主只会在约束条件下起作用。 但是，明确地分配角色并不总是很聪明。 在理想的世界中，该团队中的一名开发人员将演变为架构师。

当我开始在一家* big *的美国软件和IT咨询公司担任IT专业人员时，我花了大约五年的时间进行编程。 在那之后，我在一家德国汽车制造商的一个大型项目中获得了第一份建筑工作。 我的主要职责是设计解决方案，为开发人员，项目经理和客户提供建议，并组织开发过程。 我写了许多文档，但是我不再编码了。 结果是我失去了核心业务的专业知识：编程。 所以过了一会儿，我的评估和直觉变得更糟，导致更糟糕的决定。 作为通用（含糊）交谈的副作用，越来越难以获得开发人员，项目经理或客户的接受。 当我意识到所有这些之后，我决定再次进行更多开发。 今天，我从事建筑工作已经十年了。 我至少有20-30％的时间在自己选择的IDE中开发代码。

主动性配置文件

虽然编程是一项必要的活动 ，但是有许多活动足以使您成功成为一名架构师。 进行架构的工作主要涉及协作，客观地评估备选方案（中立和公正）以及决策。 与他人沟通，与几乎总是有自己观点的其他人打交道，这很重要。 此外，关于组建团队并围绕这些团队设计理想的开发过程以解决具体问题还有很多。 最后，最重要的是要以一种覆盖所有功能和非功能需求的方式来设计（构建）解决方案。 您可以在没有超级实际技术知识的情况下或多或少地进行所有操作。 但是我相信，如果架构师具有日常编码业务所积累的技术专长，那么他/她可以做得更好。 从长远来看，如果没有足够的编码实践，就不能成为技术架构师。

图1：软件架构师的活动

解决权衡

当我当建筑师的时候，我经常发现自己处于艰难的折衷中 。 也就是说，我想改善一个质量属性，但是要实现这一点，我需要降级另一个质量属性。 这是一个简单但很常见的示例：通常希望拥有一个具有最佳性能的高度可变的系统。 但是，这两个属性（性能和可变性）通常呈负相关，当您想增加可变性时，通常会降低效率。 进行体系结构设计通常意味着在竞争的系统质量之间找到黄金分割–这意味着选择代表最佳折衷方案的正确选择。 这是要在系统质量和该系统的环境因素（例如牛排架，要求）之间找到平衡。 运营经理将专注于新系统的效率，而开发经理则认为拥有可变维护的系统而产生很少的维护成本非常重要。 客户希望拥有一个具有最高业务流程自动化程度的新系统。 这些情况会浪费大量的时间和精力。

分享知识和交流

另一项重要的重要活动是：与技术专家和其他牛排店主团队分享知识 。 软件开发的核心问题是将领域专家的模糊知识转换为仅能理解两位数字（0和1）的傻瓜计算机的无情逻辑机器代码。 因此，架构师之间进行了很多交流。 他们使用模型来做到这一点。 模型充当人脑与计算机之间的映射机制。 在知识到二进制的转换过程中可能出现的一系列问题非常多样。 每个团队成员都不可能了解所有人。 这就是为什么在团队中共享知识如此重要的另一个原因。

没有人是完美的！

不用说， 没有人是完美的 。 每个团队都不一样，每个具体情况也不同。 因此，在一种情况下，一个人可能是团队的正确架构师，而在其他团队中，这个人可能不合适。 架构师也可以具有不同的优势。 我知道架构师可以很好地沟通和社交，但是在设计解决方案或组织开发过程方面做得不好。 尽管他们并不掌握每种技能，但他们都是优秀的建筑师。 共同点是他们都是务实的开发人员。

参考： IT架构上的5分：来自我们JCG合作伙伴 Niklas的现代软件架构师。

翻译自: https://www.javacodegeeks.com/2012/08/5-on-it-architecture-modern-software.html