Uma Pequena Provocação aos Arquitetos

JavaBaby Membro desde: 18/09/2004 11:10:06 Mensagens: 90 Offline

Retirado do artigo Software Craftsmanship com Uncle Bob Martin
http://andrefaria.com/2009/11/30/software-craftsmanship-com-uncle-bob-martin/

Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no ?mundo que constroem para os outros?, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele ?não tem que dormir na cama que faz?.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experiências o que o time está fazendo para saber o que ele realmente precisa.

E aí galera, vocês concordam com isso?
Os que são arquitetos, põe realmente a mão na massa ou passam o dia fazendo diagramas?

Particularmente, corcordo com Uncle Bob!

Polemico este assunto.

Me faz lembrar um tema do mundo administração relacionado ao tipo de lider:

Tem aquele que nunca participou dos processos da empresa (traduzindo: meteu a mão na massa no amago da coisa) porem está na posição de liderança se valendo dos conceitos teóricos adquiridos nos livros e com os professores da universidade. Por outro lado existe outro tipo de lider que nasce dentro da organização passando pela maioria dos processos deixando seu suor em boa parte da empresa e que agora chegou na posição de lider.

Um ignora questões relacionadas a pratica em função da teoria; isto é bom? Acredito que nem sempre.

O outro ignora questões relaconadas a teoria em função da pratica; isto é bom? Acredito que nem sempre também.

Na minha opinião, para todos em tudo o que vale é o bom senso; saber desempenhar bem o papel no momento devido, não esquecendo que as coisas raramente estão totalmente desconectadas principalmente no tocante a sistemas (sistemas não é coisa só da computação).

Hoje penso que a arquitetura parte como sugestão de um profissional que chamam de arquiteto e como tal precisa ser avaliada pela equipe antes de ser instaurada. E que nada impede do "arquiteto" participar como desenvolvedor.

flws

JavaEvangelist Membro desde: 21/11/2004 16:40:00 Mensagens: 419 Offline

Eu não consigo respeitar um arquiteto que não esteja engajado com o projeto.
Claro, existem níveis e níveis de arquitetura. Em mega-projetos, talvez a equipe arquitetural responsável não sente do teu lado e te ajude com um problema do framework, mas para todos os outros tipos de projetos, eu desprezo totalmente arquitetos-de-prateleira, que só sabem ficar falando asneiras, e dando pitaco no trabalho dos outros, sem se envolver e participar ativamente do desenvolvimento do projeto.

O fato de você ser um arquiteto não significa que você é programador; mas isso também não significa que você não pode programar.

JavaBaby Membro desde: 18/09/2004 11:10:06 Mensagens: 90 Offline

@fantomas É verdade cara. Acho que o melhor é quanto se tem um equilíbrio entre a teoria e prática.

garcia-jj wrote:O fato de você ser um arquiteto não significa que você é programador; mas isso também não significa que você não pode programar.

Exato. E não siginifica que você fica fazendo diagraminhas. Arquitetos são, na grande maioria das vezes, para tomada de decisões em relação a um sistema existente ou em fase de construção, considerando os "ilitys" que ele aprendeu nos anos de experência que tem.

JavaTeenager Membro desde: 28/03/2006 12:04:34 Mensagens: 193 Offline

Na maioria das vezes vejo o papel do arquiteto em decisões importantes mesmo, pq dificilmente trabalho com projetos novos. (So barco afundando rs). As vezes a necessidade de integrar alguns sistemas, ou a detecção de problemas futuros na arquitetura de sistemas legados.
Essas coisas. nesse caso as vezes o legal é ter um programador bom para visualizar a ideia do arquiteto com facilidade, liderar tecnicamente a equipe e meter a mão na massa.

Mas não quer dizer que o fato de tomar decisão seja apenas fazer docs e diagramas, as vezes e na maioria delas uma boa prova de conceito é uma forma de decisão

Esse bom é aquela mesma história de analista so faz diagrama.

Todo o profissional deve entender o todo, não somente a sua parte. Apartir do momento que um analista não codifica, ou um arquiteto, ele não conheçe o problema, nem sabe quais decisões tomar corretamente, ele toma baseado no achismo, no que ele acredita certo.

Pra mim quem não suja as mãos não mereçe meu reconhecimento.

JavaTeenager Membro desde: 28/03/2006 12:04:34 Mensagens: 193 Offline

não concordo com você Felagund, as vezes um arquiteto realmente bom e experiente não precisar codificar para saber o problema.
O cara tem que ser vivido o suficiente para entender problemas sem ter que debulhar códigos e códigos.
Mesmo porque entender o todo de um sistema de menor porte é ate possível, mais pensando em sistemas legados, e de grande porte acho que fica um pouco inviavél de ter esse conhecimento.

Complementando meu comentário, quando digo que o arquiteto pode sim programar não falo de codificar regras de negócio, mas sim algum componente que faça parte da arquitetura do projeto.

GUJ Expert Membro desde: 20/02/2008 12:32:59 Mensagens: 3275 Offline

É a velha história do DEPENDE.
Cada caso é um caso e acho que a maioria aqui pode dar exemplos e contra-exemplos.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

andrefariagomes wrote:Retirado do artigo Software Craftsmanship com Uncle Bob Martin
http://andrefaria.com/2009/11/30/software-craftsmanship-com-uncle-bob-martin/

Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no ?mundo que constroem para os outros?, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele ?não tem que dormir na cama que faz?.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experiências o que o time está fazendo para saber o que ele realmente precisa.

E aí galera, vocês concordam com isso?
Os que são arquitetos, põe realmente a mão na massa ou passam o dia fazendo diagramas?

Tecnicamente arquitetura de um sistema não se programa, se escolhe. O que se programa é o design.
Como eu ainda não vi os videos vou me abster de mais comentários porque não sei se ele diz "architecture" ou "design".
Se for design ele tem razão. Se for arquitetura ele não sabe do que fala.

Um exemplo interessante que conta como ponto positivo aos arquitetos "que ficam dando pitaco no código dos outros", é quando você possui uma equipe muito grande (não quero dizer que isso seja uma coisa boa), e precisa manter certa "homogenidade" na base de código.

Minha visão é que o arquiteto de software deve prover ferramentas pra facilitar a vida dos desenvolvedores, e matar 3 aliens e um predador por semana

leosouzabh wrote:... na maioria delas uma boa prova de conceito é uma forma de decisão

Fantástico - queria que todos gerentes de projetos da face da terra (que aplicam waterfall) percebessem isso - nossa vida seria muito mais fácil

sergiotaborda wrote:
Tecnicamente arquitetura de um sistema não se programa, se escolhe. O que se programa é o design.
Como eu ainda não vi os videos vou me abster de mais comentários porque não sei se ele diz "architecture" ou "design".
Se for design ele tem razão. Se for arquitetura ele não sabe do que fala.

Sérgio, como assim? O que é arquitetura para você? Escolher o que? Liguagens? Frameworks? Se você acha que o Robert Martin não sabe do que fala seria legal vc escrever um artigo, citando fontes e provando isso...

A todos....Desde o método Objectory, pré RUP, nosso amigo Jacobson já falava que arquitetura é EXECUTÁVEL (e isso nos anos 70 e 80). Nenhum autor, diz que arquitetura são diagramas. O RUP que geralmente é o culpado pelas aberrações do mercado desde sempre disse que o fruto da elaboração é uma arquitetura provada com software funcionando (geralmente implementando alguns cenários complexos dos casos de uso mais importantes). E acredite, há projetos que você PRECISA provar a arquitetura antes de começar a entregar kilos de funcionalidades. Foco em arquitetura: uma das bases do RUP, resolva a arquitetura primeiro e você não terá problemas no futuro. Isso é válido para sistemas mais complexos, se você só usa arquitetura Toddinho (de caixinha), você nunca fez um software com riscos arquiteturais significativos...

Se um arquiteto não sabe codar ele não serve para nada. #ivory_tower...

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