Todo desenvolvedor é um arquiteto


Por Adriano de Pinho Tavares em 16/10/2014 12:23 | Comentários: 8

Co-autor: Bruno Leite Alves

Todo desenvolvedor que está trabahando em um projeto de software está envolvido com arquitetura de software. O desenvolvedor líder está encarregado de projetar a arquitetura geral do programa. Os desenvolvedores seniores estão encarregados da arquitetura dos mecanismos de uma área específica do programa. E os desenvolvedores juniores estão encarregados da arquitetura das partes do programa que estão escrevendo, mesmo que sejam tão simples quanto a gravação e leitura de um arquivo. Há até certa influência na arquitetura envolvida na escrita de uma única linha de código.  

Mesmo quando você está codificando tudo sozinho, há uma arquitetura sendo desenvolvida. Às vezes, você toma uma decisão técnica segundos antes de os seus dedos pressionarem o teclado, e esse é o seu processo arquitetural. Muitos desenvolvedores pensam como vão escrever seus programas quando estão tomando banho ou ouvindo música no carro.

Todos aqueles que escrevem software são arquitetos. Cada pessoa em uma equipe de software é responsável por se certificar de que seu código está bem projetado. Ninguém que esteja escrevendo código para um projeto de software pode ignorar a arquitetura do software.

Mas isso não significa que o projeto arquitetural seja uma democracia. Você deve projetar em conjunto de uma forma colaborativa para a arquitetura emergir ao longo do projeto, mas as decisões devem ser tomadas por alguém mais experiente. Isso vem da necessidade de ter uma visão global sobre o projeto para justificar as decisões arquiteturais e responder por elas junto aos envolvidos. Os desenvolvedores devem ter a autoridade de tomar decisões em suas áreas de atuação, mas se eles tomarem decisões inadequadas, essas devem ser avaliadas por desenvolvedores mais experientes, os quais devem ter poder de veto. Eles devem mostrar os motivos do veto e porque a nova decisão é melhor que a anterior. Geralmente é neste tipo de cenário que surge o papel do arquiteto, alguém mais experiente tomando decisões que impactam todo o software, e não apenas um ponto específico. Todos devem estar cientes que a responsabilidade pela arquitetura deve permanecer com as pessoas que estão realmente escrevendo o código.

Um arquiteto deve sempre estar disposto a ouvir sugestões e feedback, porque os desenvolvedores geralmente são pessoas capacitadas e as vezes possuem mais experiência em uma determinada área que o próprio arquiteto. Mas após considerar todos os detalhes, as decisões devem ser tomas considerando também a integridade conceitual da arquitetura do software.


Professor Instituto Pangea

Adriano de Pinho Tavares

O professor Adriano ministra disciplinas voltadas para arquitetura e engenharia de software em cursos de pós graduação no IGTI, UNA e PUCMINAS. A sua formação passa pela graduação em Ciência da Computação pela PUC-MG em 1996 e especialização em Informática com ênfase em Engenharia de Software pela UFMG em 2001. Após esse período ele veio se especializando e obtendo certificações em suas áreas de interesse como Certified Scrum Master, Disciplined Agile Black Belt / Certified Instructor e Sun Certified Enterprise Architect J2EE. Adriano (...)

Outros artigos de Adriano de Pinho Tavares

Comentários

  • Weberton Faria em 16/10/2014 às 16:59
    Muito bom artigo Adriano.
  • Paulo Marcio Brandi Rezende em 16/10/2014 às 18:23
    Será que isso que as decisões que os desenvolvedores tomam são arquiteturais mesmo ou seria aquilo que alguns chamam de "design"?
  • Diego Morais em 16/10/2014 às 19:26
    Muito interessante. A leitura do seu artigo me fez entender que uma arquitetura de software é mais do que uma decisão sobre quais frameworks serão usados, vejo que o conhecimento de patterns e refatoração podem contribuir para uma melhor arquitetura, estou correto?
  • Paulo Marcio Brandi Rezende em 22/10/2014 às 11:16
    Fazendo uso de um lugar comum, em certo sentido o que chamo de "arquitetura" está mais ligado ao atendimento de requisitos não-funcionais, e o que chamo de "design" está mais ligado ao atendimento de requisitos funcionais.

Para comentar este artigo basta fazer login ou cadastrar-se gratuitamente!