软件架构师应避免的7种行为 - Daniel Watts

21-02-03 banq

多年来,我有机会与经验丰富的软件/技术/解决方案架构师一起在架构角色中工作。通过观察其他人和我自己的反复试验,我学到了一些关于在这些角色中不该做什么的知识。,如果您处于软件架构角色,可以避免以下7种行为:

 

1.不要忽视工程团队

如果您没有在工程团队中编写或审阅过代码或深入进行技术讨论,则可能是您与问题目标或与工程团队不够亲密。如果您没有感到他们的痛苦,那么您可能缺乏同理心和理解力,无法提供有效的指导。但是一旦您发现自己已经处于这个位置,应该会考虑从一对一开始与工程师配对,这是提高同理心和理解力的最快方法。然后在必要时考虑参加需求的启动、技术设计讨论和代码审查。

 

2.不要忽略领域

成为领域专家是角色的一部分。这些知识可以用作在业务和工程之间进行有效的翻译。也就是说,您也要避免成为沟通的瓶颈,因此为工程团队教授、翻译和记录域上下文和业务价值非常重要。这就是价值流映射事件风暴域驱动设计等技术真正可以提供帮助的地方。

 

3.不要规定或要求架构

在大多数情况下,我们的行业实际已经不是这样一个简单概念:即系统架构是独立设计的并交给工程师交付的。实际上软件架构或体系结构是和开发交织在一起的活动,其中一个的反馈会影响另一个。尽可能缩短反馈循环可能会导致更好的结果。因此,如果您想设计和创建更具弹性的系统,而您的组织倾向于强制要求或规定体系结构;考虑如何最好地授权工程师做出合理的架构决策。与工程师合作,就架构原则达成共识,并接受从未完成的架构,随着时间的流逝,架构应该不断发展和变化是一个不错的起点(请参见有关此方面的更多内容,请参见构建进化架构》一书。

 

4.不要仅仅寻求架构一致性

在构建和维护许多系统以帮助防止复杂性的组织中,一致性当然占有一席之地。我认为,最好将其视为可能会有例外的准则。简单地寻求或更糟的是,加强一致性是确保团队步伐放缓,压制创新并减少学习机会的肯定方法。

 

5.不要忘记当前的架构状态

根据公认的原则并与工程师协作对目标体系结构进行建模可能会很有用(请参见上面的#1和#3)。但是,它必须建立在对当前体系结构的所有细微差别和理解上。

 

6.不要过于依赖所需的架构

如果您要为工程团队提供技术指导的话。将出现新的信息和不可预见的情况,因此任何目标状态都将100%更改。当这些情况浮出水面时,您将需要保持开放的态度以适应您的观点和方向。固定的视图只会阻碍进度。如#3所述,架构应经历不断的,增量的变化。 

 

7.不要让审核过程停滞不前

作为大型组织的架构师,您很可能负责或积极参与体系结构和安全性审查过程,无论是作为审查者还是寻求审查。这些流程通常是变更批准复审,为生产发布开了绿灯。它们可能漫长而引人注目,其价值不明确,涉及背景为零的审稿人,并导致不必要或不必要的结果;使他们成为抵抗变化的理想人选。

作为一个更高级的人物,架构师应该为这种直觉而努力。他们应设法了解审查过程的目的和价值,并将其传达给他人。他们应该领导或指导工程团队完成这些过程,尤其是第一次。

 

1
猜你喜欢