Durante alguns anos estive envolvido com o desenvolvimento de software, em especial infraestrutura e back-end. Mesmo já tendo a oportunidade de trabalhar no desenvolvimento de aplicações front-end com e sem frameworks (sim, eu já usei HTML, CSS e JS puros e não faz mais que 2 anos), todo o processo que envolve, desde definir os recursos de cloud computing que serão usados, até encontrar uma stack que cumpre os requisitos e por fim tornar real com uma boa implementação sempre me trouxe um nível de empolgação maior. Criar a funcionalidade por debaixo dos panos sempre foi mais interessante.
Nesse tempo, eu considerei que o papel de um arquiteto de software não seria necessário. Seria apenas um nível de hierarquia. De fato, isso pode ser uma realidade em alguns projetos, mas foi trabalhando em um bom time que entendi o principal desafio de um software complexo: manter a consistência e permitir evolução.
Antes de mais nada, explico melhor o motivo de dizer isso. Trabalhei em uma equipe que possuía pessoas com experiência, além de proativas e responsáveis. Com parceria e profissionalismo bem além da média, diversos problemas de comunicação eram facilmente solucionados, quando eventualmente existiam. O que de fato trazia problemas? APIs de outras frentes que não estavam bem documentadas. Soluções que eram complicadas de entender (e aqui não falo sobre complexidade, pois são coisas diferentes). Falta de uma linguagem única. Tudo isso forçava o time a usar de sua bagagem para suprir essa deficiência, mas era como um peso a ser carregado.
Um outro ponto é que as decisões não estavam organizadas. Não foi criada documentação para diversos itens - nada além dos registros nos chats. Cabe dizer que, se você pensa que isso tem algo a ver com agilidade, lembre-se: ter um software funcionando não exclui documentar minimamente o que for primordial.
Nesse meio tempo, comecei a procurar entender o motivo de existir um arquiteto de software. O primeiro gatilho surgiu ao tentar responder um provocação de um colega de trabalho: como iniciar um projeto? Como definir uma estrutura que escala? Como converter entendimento de negócio em algo que traga orientação para as pessoas que ficarão responsáveis por implementar e quais as técnicas que podem ser utilizadas para isso?
Bem, essas são algumas das atribuições que um arquiteto de software pode ter. Seja isso uma posição ou papel dentro do time, ter alguém que tome decisões e olhe para aspectos de médio e longo prazo pode ser essencial para o sucesso do projeto.
Esse é um caminho que decidi trilhar: melhorar o meu entendimento sobre arquitetura de software. Dessa forma, será através dessa série de artigos, com fim ainda indefinido, que irei registrar meu progresso. Serão textos curtos, mas que formam uma sequência útil para outras pessoas que estejam partindo desse mesmo lugar.
--
Tem alguma sugestão ou comentário? Parte fundamental de aprender é a troca de experiências, então deixa um comentário e vamos tornar, esse, um espaço para crescer!
Top comments (0)