Arquiteto de Software, muitas vezes amado ou odiado dentro das equipes de desenvolvimento de software, tem um papel fundamental na construção de um sistema.

Muitas vezes, pode ser confundido ou até mesmo o mercado tem este costume de aglutinar responsabilidades ao mesmo.

Mas estava a refletir sobre isto baseado no livro Arquitetura Limpa do Robert C. Martin, mais conhecido no mundo do desenvolvimento como Uncle Bob.

Então, trarei alguns pontos que acho importante na função de Arquiteto de Software e que pode ajudar de alguma forma no rumo de sua carreira.

O papel de um Arquiteto de Software nos times de desenvolvimento

Muito tenho visto nos últimos anos sobre o que é o papel de um Arquiteto de Software dentro de um time e basicamente olhando o texto do Bob Martin, vejo que o mercado distorceu em algumas situações este papel.

Antes de iniciar ao tema, acredito que a grande maioria dos desenvolvedores pleiteia algum dia a ascensão à função de Arquitetura de Software.

Eu mesmo, desde o inicio da carreira sempre me espelhei em meus colegas da equipe que desempenhavam este papel e admirava o trabalho deles e o nível de conhecimento de software que estes indivíduos tinham.

O mais impressionante eram as soluções, e muitas delas em épocas desafiadoras que não tínhamos muito acesso a frameworks tão completos dos quais dispomos atualmente.

Mas conforme o tempo passou, assim como as linguagens evoluiram e a tecnologia, acredito que a função também evoluiu e muito.

No entanto, algumas coisas se perderam e por isso que revisitei este tópico. No próprio livro Arquitetura Limpa, ele define o papel ou as atribuições da maneira mais simples possível:

• o arquiteto de software é um desenvolvedor: embora um desenvolvedor muito mais experiente, é importante que ele também ajude o time com tarefas de desenvolvimento (não codificar, ok) que irão demandar resolução de problemas mais complexos e que irá afetar a dependência dos componentes ou módulos; embora tenha conhecido nos últimos anos alguns que não têm coragem de sentar junto com o time e assumir o problema, esta é a característica principal de uma arquiteto.
• orientam o resto do time para um design que aumente a produtividade da equipe: este item é praticamente semelhante ao primeiro, mas quero reforçar que, embora até mesmo desenvolvedores mais sênior no time consigam definir um design, é o arquiteto que irá contribuir e organizar, integrando inclusive outros times ou componentes.
• não irá colocar a mão em código, mas é o patrono ou senhorio dele: embora muitos acreditem que o arquiteto deva se envolver em assuntos mais alto nível, ele deve tomar as rédeas do design e código, principalmente quando o mesmo começa a tomar proporções maiores.

Embora muitos acreditem que Arquitetura de Software seja um assunto mais alto nível e não tanto codificação, o que fica claro no livro Arquitetura Limpa é que o arquiteto de software é o cara hands-on.

---

Pode parecer um tema simples, mas pode reparar em sua equipe ou empresa o que ocorre com o Arquiteto de Software pode estar um pouco distorido.

Não me espanta se em um futuro próximo começarem a atribuir cada vez mais coisas sem sentido para esta função, como gerenciar o time, etc.

E você o que acha sobre isto? Comente aqui.