Arquitetos devem escrever código?

ainda não li o post do cara, mas só a minha opinião rapidinho

pelo menos eu tenho que escrever código …
por dois motivos:
1 - para evitar de morrer de tédio
2 - o mais importante — se eu não usar a arquitetura que eu criei, pelo menos eu, tenho tendencia a viajar demais e criar um troço que mais atrapalha do que ajuda

Arquitetos que não programam (e eu conheço alguns) tendem a adotar “soluções” que mais causam problemas do que ajudam no projeto. Fora adotar coisas que não fazem o menor sentido ou sem um propósito definido para o desenvolvimento.

Arquitetos programam sim, a própria arquitetura! No minimo pra juntar as ferramentas.

Sobre provar a própria comida de cachorro: é normal o arquiteto também ser desenvolvedor então é facil de programar e testar o que fez.

No meu caso que trabalho 100% do tempo como arquiteto, não consigo testar a arquitetura de maneira como o desenvolvedor, acho bem dificil.

Para resolver esse problema tento estar sempre junto dos desenvolvedores. Atualmente existem 3 empresas diferentes usando a arquitetura e elas sabem que podem relatar bugs diretamente pra mim e sugerir melhorias. Eu estou sempre perguntando se o modo de programar não está repetitivo (sinal que posso melhorar a arquitetura), analiso os códigos para ver se os desenvolvedores não estão sendo induzidos a fazer coisas erradas e por ai vai.

Eu vejo o arquiteto como uma figura necessária em um projeto com muitos code monkeys, caso contrário ele passa a ser meramente decorativo.

Arquitetos são os que podem mais afundar um projeto, vomitando uma arquitetura e deixando para traz um bando de gente a merce de um treco inominavel.

Por isso um arquiteto que não escreve código, ou pelo menos não está em constante contato com as vítimas daquilo que produz, só produz lixo.

pois é, vitimas é bom! hehe

pois é, vitimas é bom! hehe

Vítimas sim, uma vez eu trampei num projeto falido pro Bostão em que o arquiteto de uma consultoria AAA (começa com S e termina com a) criou um framework incrivelmente estúpido, e todos os desenvolvedores foram punidos a usá-lo.

O melhor é que muitas vezes o arquiteto não tem a menor idéia do que está fazendo, no projeto em questão, tinhamos SLSB retornando enormes xmls para serem renderizados via xpath em jsps usando umas tag libs péssimas.

Qualquer um com um mínimo de competência sabe dizer que essa decisão é MUITO infeliz, ainda assim, o todo poderoso arquiteto defecou a arquitetura do projeto e saiu fora.

Por sorte eu pulei fora daquilo antes da fase de tunning, imagine tunnar uma nhaca dessa???

Eu sinceramente acho que o papel de arquiteto tem que morrer, precisamos hoje mesmo de technical leads, que fazer muito mais que produzir 1 monte de UML e ferrar e produtividade dos projetos, mas tb supervisionar os code monkeys o tempo todo com ferramentas como PMD, checkstyle & cia.

pois é, vitimas é bom! hehe

Vítimas sim, uma vez eu trampei num projeto falido pro Bostão em que o arquiteto de uma consultoria AAA (começa com S e termina com a) criou um framework incrivelmente estúpido, e todos os desenvolvedores foram punidos a usá-lo.

O melhor é que muitas vezes o arquiteto não tem a menor idéia do que está fazendo, no projeto em questão, tinhamos SLSB retornando enormes xmls para serem renderizados via xpath em jsps usando umas tag libs péssimas.

Qualquer um com um mínimo de competência sabe dizer que essa decisão é MUITO infeliz, ainda assim, o todo poderoso arquiteto defecou a arquitetura do projeto e saiu fora.

Por sorte eu pulei fora daquilo antes da fase de tunning, imagine tunnar uma nhaca dessa???
Bem, tua experiencia nesse caso da um embasamento pra tua opinião, mas não é bom generalizar, não acho que o papel de todo arquiteto seja ferrar a produtividade do desenvolvedor, e também não acho que todo desenvolvedor seja code monkey como tu diz.

Acho que no meu caso, no lugar de vítimas eu colocaria pessoas que entendem muito mais do que eu das regras de negócio da empresa e isso é realmente importante para a empresa.

E mais, também é importante para a empresa, garantir que o trabalho realizados por terceiros sejam de boa qualidade, e sigam conforme as regras especificadas. Muita gente diz que é impossivel garantir o trabalho de outras pessoas, mas isso é possivel sim. Um bom framework pode garantir que: ou a coisa fica boa, ou não sai. O lado ruim disso é que amarra um pouco o desenvolvedor e inibe a criatividade, isso é fato e conheço essa questão.

Fazem dois anos que eu estou bem envolvido com a parte tecnica do desenvolvimento mas sem ser desenvolvedor e conheço o lado negro das pessoas que definem a arquitetura: começam a achar que são Deuses, que sabem mais que qualquer um, a achar que a opinião dos outros não é válida, e pensar no desenvolvedor como um inimigo que deve ser combatido e amarrado. Em todas apresentações que eu faço e em cada treinamento que eu dou eu deixo bem claro, que o mais importante é o desenvolvedor se sentir bem usando a arquitetura e não ficar pensando que poderia fazer melhor e ficar me xingando. Se acha que pode fazer melhor senta do meu lado e vamos fazer.

Acho que o papel do technical leads importante também, mas é um visão mais especifica de um grupo de desenvolvedores. Acho que o arquiteto precisa de uma visão mais corporativa, e com problemas diferentes. technical leads talvez não tenham a visão de metodologia, integração de sistemas, auditorias e coisas mais.

+1

Experiência própria. Um technical lead consegue muito mais contato com a equipe, e justamente por ser um líder e não um chefe (chefes mandam, líderes lideram…), a equipe tende a discutir e concordar mais facilmente com o que é dito. Parece que só o fato de não existir o nome “arquiteto” o pessoal não encherga o fulano como monstro.

Simplesmente um cara aqui queria que usássemos XmlBeans nos projetos. Pedi pra ele explicar porque e ele falou que num futuro, se fóssemos integrar com outras aplicações seria mais fácil.

Fácil como se ele falou pra usar sem mesmo saber pra direito aquilo serve e como utilizar bem.

Fiz sem e depois avisei ele.

Bom senhores, vou responder como Arquiteto, pois exerço tal papel no banco francês - BNP Paribas e respondo pela arquitetura no conselho mundial do banco - América Latina.

Ter experiência como programador é fundamental e um dos preceitos do processo de certificação Sun Microsystems. Entretanto vivenciar as regras do negócio da companhia é papel do programador, pois muitas vezes o mesmo é especialista num nicho de mercado onde você ficaria meses ou anos para aprender.

Meu papel dentro da mesma é projetar a infra que os programadores vão utilizar, levando em conta muitos fatores:

[list]
Business plan da companhia - sim, pois preciso saber qual é a taxa de crescimento que o projeto estará esperando, a fim de provisionar uma arquitetura que consiga dar vasão à demanda. - Picos, como está´o hardware, vai suportar ? qual estratégia de failover usar ? Como fica o cluster, quantos nós, replicação da sessão, conectores, quantos sistemas estarão integrados, protocolos, segurança, performance e por ai vai …

Expertise dos profissionais da casa, pois não adianta eu colocar o XPTO Y IOC na ponta, se minha equipe não está preparada. Será necessário um coaching e mentoring e ter consciência para projetar a evolução paulatina até o ideal.

Programar realmente as partes mais difícieis, principalmente quando se está adotando algum framework / processo que sua equipe ainda não está famirializada. Isso acaba validando sua arquitetura junto à mesma e se ganha o respeito dos membros, pois vêem sua idéia e o raciocínio e acaba ententendo os porquês.
[/list]

Programar o dia-a-dia da companhia não faz parte realmente do escopo e sim programação de alto nível, voltada à itens não funcionais, infra e etc.

Entretanto, até mesmo para eu validar novos conceitos, acabo pegando projetos dentro da companhia para programar juntamente.

Com isso acabo ganhando muitas coisas: Valido minha arquitetura e muitas vezes acabo lapidando, queimando algumas coisas, acrescentando outras que não tive visão, pois projetar no UML é uma coisa completamente diferente de colocar a mão na massa.

Ganho, pois a galera acaba vendo o treco funcionando por quem bolou e fica empolgada em utilizar.

E por fim me sinto parte do “Time”, pois posso provisionar à equipe um mentoring com cases reais de implementação e da empresa, cenário que eles conhecem !!

Recentemente fiz um refactoring numa aplicação. Foi muito empolgante mostrar o quadro : "antes " e “depois”.

Surgem muitas dúvidas que você responde e acaba mostrando ao desenvolvedor que você não é um arquiteto alienígena, e sim um cara que tem um pouco mais de vivência, transfere know-how e muitos acabam pegando gosto pela coisa e comprando livros que você recomenda e se tornando arquitetos junto contigo, discutindo patterns, arquiteturas e até mesmo assumindo projetos em parceria

Quando não existem code monkeys o arquiteto geralmente assume postura de facilitador de decisões arquiteturais e programador da framework de infra-estrutura utilizado, se algum.

Quando estão numa consultoria commodity geralmente eles criam templates (“mecanismos arquiteturais”) sobre como salvar objetos, fazer buscas, etc. além dos requisitos não funcionais. Também são a quem se pergunta absolutamente tudo que não envolva o que está coberto nos tais mecanismos, incluindo coisas que um programador deveria saber.

Ou seja: para consultorias commodity arquitetos são babás.

Falando em tudo isso, vi um link no blog do rafael muito bom:

The Principle Of Too Much Magic

Onde é que eu assino!

Sou vitima de um framework não usado pelo arquiteto que projetou/desenvolveu.

valeuz…

Outro testemunho: O arquiteto de um projeto fez um framework e simplesmente sumiu num dia e não veio mais. Seu legado, claro, ficou!

Existe uma contante quando se fala em mão de obra: na média, a maioria é mediocre. Logo colocar tanto poder de cagar na mão de uma pessoa só é muito risco.

Não é lá não.

Pra ter uma idéia o fmk, chamado de Framework de Mensagens era mais ou menos assim:

No JSP:

x = "meu.Bean:create;meu.Bean:save;meu.Bean:store"; frm.campo.value = x; frm.submit();

Ai o framework carregava os dados do Form no Bean, salvava e mantinha na sessão. Era rápido desenvolver telas CRUD, mas jogava o fluxo do processamento pro JSP.

Ou pior ainda:

minha.Classe:create;minha.Classe:execute

Pra processar uma classe implementada por nós.

Isso era pra ser uma DSL?

DSL?

Domain Specific Language, creio eu.

Realmente não sei.

Era uma linguagenzinha criada com funcionalidades que teoricamente facilitariam o desenvolvimento utilizando a arquitetura?

Sim.

Mas acabou virando um monstro e em alguns casos haviam mensagens enormes.

danieldestro:

Sim.

Mas acabou virando um monstro e em alguns casos haviam mensagens enormes.

Não havia nenhum corajoso pra manter esse framework? =)

Ele teve de ser continuado. Um cara lá assumiu.
Depois de uns anos fui pro exterior e quando voltei, outro projeto similar foi feito com o mesmo FMK. Esse cara do novo projeto até estendeu ele pra trabalhar diretamente com Entire-X (Natural/Adabas).

Até ano passado eu arrepiava quando ouvia dizer que tinha manutenção no sistema pra fazer.

http://plentz.org/2006/04/23/domain-specific-languages/

Eu tb sou vitima disto, utilizaram um framework porcaria que vai juntando todas as informacoes na url, alem de as “actions” nao resceberem nem o response… athe ai esta tudo bem, mas qdo junta ainda um MER porcaria, com um banco horrivel( Sybase, uma versa bem antiga dele ) e um sistemas de persistencia baseado em na execucao de procedures, fazer integracao é literalmente um INFERNO.

Pergunta, vocês estão falando de vários casos que o arquiteto saiu e deixou o monstro sem dono. Será que a culpa não é da empresa que vocês trabalham que permite isso? Será que culpar o pobre coitado (coitado por ter feito um monstro, e por estar sendo xingado) está certo?

Eu vejo que no minimo a empresa tem que ter uma politica de suporte ao desenvolvimento para garantir o suporte e a evolução das ferramentas de desenvolvimento.

yeap, concordo
Quando um arquiteto desenvolve uma arquitetura que vai ser a base para futuros sistemas e produtos de uma empresa, é obrigação da empresa selecionar uma outra pessoa que tem que também conhecer toda a estrutura desta arquitetura …
e do Arquiteto passar todo o conhecimento necessário para esta pessoa …

Por isto também é importante não sómente uma documentação de como usar, mas também uma de como as coisas funcionam, para que seja possivel evoluir a arquitetura desenvolvida

Sim, eu sei, esta parte da documentação é um pé no saco de fazer, mas é tão ou mais importante que o resto …

Bah, fazer documentação é a pior parte, e pior que tem que saber fazer.

Bah, fazer documentação é a pior parte, e pior que tem que saber fazer.

Acredito que a documentação é a melhor maneira de possibilitar a continuidade do serviço.

Muitas vezes, nós arquitetos não temos uma visão clara de todos os aspectos que o software ou framework vai estar inserido. O processo é cíclico e se não tiver bem documentado, a empresa corre o risco de perder seu profissional para o mercado e ficará realmente com um monstrengo que ninguém sabe pra que serve.

Agora, se tudo for planejado, documetado, existir um processo de coaching e mentoring junto à equipe, esses poderão estender funcionalidades e até mesmo sugerir algumas revisões em muitos pontos, pois diversos programadores ( ao menos na nossa equipe), possuem muita expertise e também são conhecedores de patterns, frameworks etc e tal.

Aqui na empresa, para os recursos Java, estou fazendo pessoalmente o coaching e metoring, e também participo do processo de seleção.

Quando contratamos um profissional, tenho a segurança que ele vai conseguir desenvolver em cima das arquiteturas propostas e até mesmo evoluir a mesma juntamente.

PS: Sei que não é o lugar para se falar nisso, mas possuo 3 vagas, mais detalhes PVT MSG …

Eu já trabalhei de diversas maneiras com documentação e nesta experiência eu tirei uma cosia: se você faz documentação como algo separado da implementação, em um tempo específico, tende a gastar tempo em algo inútil.

Seja super-especificando algo a ser cosntruído ou documentando algo já implementado, a documentação tende a ser defasada ou sem qualidade.

Documentação de um componente de software para mim é em linhas gerais o que ele faz. Eu penso na documentação primeiro como algo que uma pessoa reutilizando o componente (seja um componente, serviço, aplicação, classe, headphone…) precis apara trabalhar com ele. Os detalhes de implementação não devem ficar lá pelo princípio básico que te faz encapsular algo: eles mudam.

Acabo de entregar uma especificação funcional como aprte da resposta à uma RFP. O componente principal deste sistema é um gerenciador de workflow integrado ás regras de negócio (nada que justificasse uma engine de workflow, algo simples).

A especificação consiste no comportamento externo do componente e uma explicação sobre a engine de workflow.

Quando trabalhando num processo onde especificações devem ser feitas e aprovadas por um grupo antes (muito comum em produtos de rede telefônica e outras coisas que se itnegram a hardware), geralmente eu escrevo um documento deste tipo, no máximo com alguns diagramas de alto nível, apra msotrar compreensão sobre as regras do negócio. Logo após eu começo a implementar este comportamento e semrpe que atinjo um marco qualquer (100% de testes unitários passando, por exemplo), eu volto ao documento.

Se você não colocar informação encapsulada desnecessária no documento e manter ele vivo os problemas diminuem bastante.

Bem, eu não disse que não se deve fazer documentação, nem que eu não faço, só disse que é um saco

Eu descobri isso a força. Hoje eu faço a documentação junto com a implementação. Fica muito melhor, e é mais facil de documentar as idéias fresquinhas.

marcelomartins:

Bem, eu não disse que não se deve fazer documentação, nem que eu não faço, só disse que é um saco

Eu descobri isso a força. Hoje eu faço a documentação junto com a implementação. Fica muito melhor, e é mais facil de documentar as idéias fresquinhas.

Isso é mesmo, mas pra isso existem os “pseudo-programadores” como um que apareceu aqui na empresa pra fazer entrevista. O carinha colocou Struts no cv, pergutei algumas coisas sobre o framework e ele me responde:

“É que uso o Struts no JSP.” … bom acho que seria uma boa colocar um cara desse pra escrever documentação …

Brincadeira à parte, é muito chato mas o profissional precisa conhecer, pois muitos vão se balisar pelo mesmo e palavras escritas e impressas exercem muito poder sobre as pessoas.

Dialogo:

Cliente: Precisamos de documentacao!
cv: Quanto?
Cliente: Tudo, ueh!
cv: Ok, mas o que vc quer primeiro?
Cliente: Ah, modulos tal e tal.
cv: Beleza, quem vai ler essa documentacao?
Cliente: A equipe de aceitacao e auditoria interna, que depois vai repassar pro comite pra revisar e dai passar pra gerencia que…
cv: E esse povo consegue fazer tudo isso de 15 em 15 minutos?
Cliente: HUuuuuuuuuUUUUUUH?!
cv: Entao, se a documentacao eh importante, a gente vai gerar ela a partir do codigo, e todos os diagramas que vc precisar e tal vao sair do codigo que ta sendo entregue. E como o sistema de integracao continua cospe um build a cada 15 minutos ou menos, eu imaginei que vc ia querer a documentacao o mais fresquinha possivel. Tou certo, ne?
Cliente: Claro, eu quero tudo atualizadinho!
cv: Entao, vai ter tudo atualizadinho de 15 em 15 minutos, mas acho que a gente vai ter que conversar melhor sobre o comite de revisao da gerencia do comite que repassa o modelo pros analistas da 4a camada do nao-sei-o-que…

hehehehe, seria legal isso … a partir do código se gerar toda a documentação que o cliente deseja, diagramas dos diversos tipos e outros afim, mas isso é hoje em dia possível ? Não conheço ferramenta que faça isso …

Quanto ao arquiteto escrever código, isso é fato, mas o código que é escrito pelo arquiteto, ou pela equipe de arquitetura envolve uma abstração maior, e deve ser pensada com cuidado, como foi escrito aqui pelo kenobi e outros, deve-se voltar mais para a infra-estrutura e objetivos da empresa. E sempre ouvir opniões de programadores com um conhecimento adequado para contribuir com melhorias.

Acho que todo o arquiteto hoje em dia gosta de escrever código, até porque a linha de evolução de um se inicia quando ele é programador e se interessa em crescer nessa área, se afastando um pouco da linha de um analista de negócios ou um gerente por exemplo.

Há um tempo atrás rolou uma discussão aqui mesmo no guj sobre as funções que um arquiteto deve desempenhar, e escrever códigos é uma delas.

E documentação deve ser essencial, deve-se colocar alguns requisitos mínimos pra quem está lendo vai conseguir entender. Porque senão vai demandar um tempo enorme e documentar além do que o essencial é um dos fatores principais em atrasos de projeto.

um bom arquiteto sempre está programando em seus projetos OpenSource. é raríssimo vc ver um arquiteto q programa em projetos pessoais, etc.

Pergunta!

Isso foi na poliedro? Pois aconteceu a mesma coisa comigo la, o arquiteto fez a framework, uma arquitetura totalmente fechada e simplesmente fugiu e o aconteceu? Um sistema q levaria 2 anos, ja ta em 5 e ainda não terminaram, eu graças a deus ou melhor  a certificação sai da poliedro e vim pra ctis. =)

^^