Arquitetos devem escrever código?

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 ...

urubatan wrote: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.

marcelomartins wrote:

urubatan wrote: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.

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

pcalcado wrote: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.

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 wrote: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

pcalcado wrote: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.

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.

Notícias, artigos e o maior fórum brasileiro sobre Java