Arquitetos não existem… só desenvolvedores!

Ou o contrário… eu explico.

Anos atrás,  quando comecei a me envolver mais com arquitetura de sistemas, quando procurei por “coisas que me ajudassem a desenvolver melhor o meu trabalho (tudo começou por que eu achava que deveria existir uma maneira melhor de fazer acesso a dados do que com Dataset’s, mas isso é outra história), eu me deparei com Padrões de design, DDD, e por aí vai; Nessa época o Giovanni Bassi também estava procurando pessoas para discutir arquitetura, e assim que me deparei com o .Net Architects. Passei por uma grande empresa de software no Brasil e lá existia cargo de arquiteto, de arquiteto corporativo, este último trabalhando com a diretoria. Mas conhecendo mais sobre arquitetura, com as discussões no #DNA comecei a pensar que, na verdade, o arquiteto era um papel exercido por um desenvolvedor dentro do processo de desenvolvimento de software, e não um cargo ocupado por alguém pensando somente em arquitetura conceitualmente, mas  sim “codando” junto com o time de desenvolvimento, pelo menos em uma parte significativa do tempo e em PoC’s, ou em partes específicas. Afinal, se o arquiteto não vive a codificação, como ele garante que a arquitetura que ele pensou inicialmente está aderente ou ainda,  que está mais ajudando do que atrapalhando? Sim, por que se a arquitetura é a estrutura na qual será construído um software ela tem que ajudar a codificar, se está atrapalhando, é melhor fazer sem. Ou seja, ninguém deveria ser contratado para ser arquiteto e sim, deveria exercer o papel de arquiteto durante um projeto, ou em uma equipe de um produto específico. Da mesma maneira que podemos estar no papel de tester, ou focado em desenvolvimento de interface (papel de dev de UX), etc…

Para que o arquiteto consiga desenvolver uma arquitetura, o que ele precisa? Conhecimento, experiência; ou não, se o cara é inteligente e cresce com PBL, qual o problema? Existem os skills que não são técnicos, comunicação, habilidade social (afinal ele precisa conviver com o time e não achar que esta acima de tudo isso). E ninguém tem dúvida que ele deve conhecer Design Patterns, frameworks, build, Testes e por aí vai. Mas espera, isso não seria tudo o que um desenvolvedor deveria conhecer? Design Patterns, codificação, framework’s, melhores soluções, tendências, Testes, Build, sem isso um dev não vai desenvolver.

– “Ah! Um dev desenvolve software, ele constrói software, já um arquiteto cria arquitetura, a base, ou um projeto… Não é a mesma coisa.” Será? Um dev realmente constrói software? Vamos fazer um paralelo? Vamos pegar outro segmento de mercado, uma indústria, uma construtora civil… Para se produzir um carro, para se construir uma ponte, é necessário um projeto, existem pessoas com diferentes habilidades lá, nem todas conseguem imaginar um carro ou os detalhes de uma ponte e nem todas conseguem instalar vidros nas portas ou pilares. Então os que não conseguem imaginar os detalhes de construção são dirigidos por um plano, ou um projeto, que é elaborado por pessoas que conseguem visualizar todos esses detalhes. Então arquitetos, engenheiros mecânicos produzem um projeto que serve de guia para operários construirem a ponte ou o carro. Os arquitetos e engenheiros tem uma visão abrangente, mesmo se só desenvolverem um pedaço desse projeto, esse pedaço é abrangente, pois é composto por diversos detalhes. O operário tem uma visão de processo de construção, seguindo o plano. Às vezes dentro desse processo ele consegue sugerir melhorias, novas idéias, mas dentro desse processo.

Voltando ao desenvolvimento de software… O desenvolvedor constrói software? Ele empilha os bits em código de máquina? Ele “builda” o código de máquina? Não! Um desenvolvedor de software constrói um projeto do que ele quer que seja o software, daí ele aperta F5 e envia uma mensagem para o Compilador dizendo “construa um código de máquina baseado nesse projeto aqui, nesse código”. Se o desenvolvedor é quem projeta ele é um arquiteto/engenheiro de software, pois ele exerce as características que definimos como a de um arquiteto. Ele não é simplesmente um operário que segue um projeto, que segue um plano, um processo. Ele pensa, elabora, planeja e PRECISA conhecer tudo aquilo escrito lá em cima: Design Patterns, ORM, Banco de dados, SOA, linguagens de programação, código, frameworks, protocolos, API’s, UX, etc… etc… Um desenvolvedor que apenas sabe usar IF…ELSE, FOR…EACH, SWITCH, simplemente não estudou o suficiente, é iniciante, ou esta enganando alguém. E ainda não leu “Clean Code”.

Se todos os dev’s se comportarem com o que esperamos hoje de um arquiteto eles serão realmente responsáveis pelo código que estão gerando, já que a arquitetura será dele também, já que ele vai ter que estudar, e muito, para aprender tudo isso. Ele também vai aumentar a visão que tem do projeto, poderá ver coisas que não estava entendendo e que contribuíram para um desenvolvimento mais pobre que ele tenha feito. É óbvio que um desenvolvedor que acabou de iniciar na profissão não terá conhecimento e experiência suficiente para codar sozinho definindo frameworks, arquitetura, mas com o auxílio de um outro dev mais experiente ele irá adquirir essa bagagem.

Então desenvolvedor,  pense como um arquiteto, seja um arquiteto! O projeto/código é seu!

11 Replies to “Arquitetos não existem… só desenvolvedores!”

  1. Fala Brandão,

    Concordo em parte contigo. Concordo que todo arquiteto tem que ser também desenvolvedor, tem que continuar metendo a mão na massa.

    Também concordo que todo desenvolvedor deve agir como arquiteto do próprio código, deve pensar como arquiteto, dentro do universo do seu código, projeto e time.

    Mas existem empresas com muitos desenvolvedores, muitos projetos e muitos times trabalhando ao mesmo tempo. Nesse cenário eu vejo a importância de haver um ou mais arquitetos que, tal qual um maestro numa orquestra, garanta que essa turma toda esteja apontando pro mesmo caminho, alguém com uma visão macro de todos esses projetos.

    Agora, pra mim é fundamental que esse(s) arquiteto(s) continuem escrevendo código, e código de produção, não apenas protótipos e experimentos. Um arquiteto desconectado do resto do time é realmente muito nocivo, vira inventador de moda.

    1. Rodrigo,

      Nesse caso existe a figura do arquiteto corporativo. Será dele a responsabilidade de apontar tendências que trarão mais ROI para o negócio. Por exemplo, esse arquiteto vai analisar se terá um ROI maior mudando para uma arquitetura de cloud computing.
      No mais não importa a quantidade da equipe e sim se eles se comunicam!

  2. Estava pensando em escrever a mesma coisa que o Rodrigo Vieira.

    Na informática das fadas todos os desenvolvedores são responsáveis e pensam no sistema globalmente.

    É fácil fazer o que autor quer em sistemas de padaria, mas sistemas grandes e complexos em empresas com muitas equipes e projetos o mais tem é desenvolvedor preocupado em fazer a sua parte funcionar. Neste sentido cabe ao arquiteto pensar no sistema como um todo e que reusos podem ser feitos.

    Para mim é mais que claro que para ser um arquiteto tem que ser um ótimo desenvolvedor e que nem todo bom desenvolvedor pode ser um arquiteto.

  3. @Adjamir Galvão

    Como não consegui editar, apenas acrescentando…

    Cansei de trabalhar em projetos com membros da equipe que são ótimos desenvolvedores, mas não se preocupavam com o sistema como um todo. Muitos querem apenas pegar sua tarefa, entende-la e entregar o código limpo e bem feito. Integração e reuso com outras partes do sistema ficam relegadas.

  4. @egomesbrandao

    Não é necessariamente uma questão de ser mau profissional. Simplesmente tem gente que não leva jeito para ter a compreensão do todo de um sistema ou até mesmo é um profissional do tipo coringa, onde ele acaba rodando em várias equipes e acaba não compreendendo o sistema como um todo.

    Além disso, uma equipe para ser boa não precisa que todos sejam tampa de crush, mas saber agregar os perfis certos as tarefas.

    Ser comprometido não significa necessariamente ter que entender todo o sistema. A pessoa pode ser comprometida em entregar suas tarefas com qualidade, mas ao mesmo tempo não consegue/não tem capacidade/não quer ter a compreensão do todo.

    Na informática das fadas, onde todo mundo trabalha num projeto desde o início, cujo domínio é fácil absorção, e o sistema não é enorme isso é até fácil, mas no mundo real o problema é muito maior.

    Em uma empresa com sistemas pequenos ou onde todos são derivados de uma mesma arquitetura base é fácil conviver sem arquiteto. Essa tarefa fica relegada apenas quando há uma mudança radical de plataforma ou tecnologia.

    Agora achar que a função de arquiteto não é importante ou até mesmo trivial (o texto e a chamada são bem claros nisso) é radicalizar demais.

    1. Em momento algum eu quis dizer que a função da arquitetura ou arquiteto não é importate, e sim justamente o contrário! Arquitetura é tão importante para um sistema que todos os desenvolvedores devem ser preocupar em aprender, entender, aplicar, questionar, melhorar; sendo assim o ideal é que todos que desenvolvem sejam arquitetos.
      Não devemos ter apenas codificadores, que pegam um manual de padrões da empresa e arrastam componentes, montam CRUD’s. Todos devem se preocupar com muito mais que isso, se podemos ter uma equipe sempre em constante evolução, por que não buscar esse ideal?

  5. Texto de 2011, já estamos em 2014 e continua muito bom. Concordo que todo desenvolvedor/programador precisa pensar como arquiteto, mas o papel/função de arquiteto parece hoje mais importante ainda do que era em 2011, vem se descolando cada vez mais do que um desenvolvedor faz.

    Não sei quem disse isso mas o que aprendi foi “O desenvolvedor pensa o que acontece quando um usuário clica num botão; o arquiteto pensa o que acontece quando mil usuários clicam no botão”. Então ligo o desenvolvedor aos requisitos funcionais e o arquiteto aos não funcionais.

    Todo lugar precisa disso, talvez não, um bom dev pode dar conta, pode englobar os requisitos funcionais de um sistema pequeno ou com a ajuda de ferramentas existentes hoje.

    Mas para equipes grandes (ou várias equipes pequenas 😉 ) o papel de arquitetos parece ficar mais evidente, quando o assunto entra cache, memory db, balanceamento, etc. ou em palavras das ISO: disponibilidade, segurança, usabilidade, interoperabilidade, etc. E mesmo integração da(s) equipe(s) o arquiteto pode dar a palavra final ao invés de discussões intermináveis entre devs de mesmo nível.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.