[quote=rodrigoy][quote=sergiotaborda]
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.[/quote]
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…
[/quote]
O que o Robert Martin fala na referencia citada é que um arquiteto deve ser uma pessoa que também codifica. a palavra chave aqui é “também”. Em nenhum ponto ele fala que arquitetura é codificada. O que ele diz é que o arquiteto deve pertencer À equipa, codificar com ela, e estar a par dos problemas.
Nos EUA o arquiteto é uma especie de lider. Lider Tecnico e Arquiteto são sinonimos. Eu não acho que isso tenha que ser assim. Eu acho que arquiteto é um role, não uma pessoa.
Numa equipe multifuncional alguem tem que fazer o papel do arquiteto. Isso não significa que ele não faça outros papeis, inclusive o de lider e o de programador.
Arquitetura , por definição, é diferente de design. A arquitetura atente a requisitos não funcionais de comunicação e deploy das aplicações que formam o sistema. O papel de um arquiteto é saber conjugar aplicações, não fazer aplicações. Escolher protocolos , escolher plataformas. No cubo arquitetural ele é responsável pela escolha das plataformas que sustentarão a aplicação e de manter algumas qualidades do sistema como a disponibilidade. O papel do arquiteto não é escrever codigo, ele pode escrever , mas não é a sua principal preocupação. A sua principal preocupação é entender as tecnologias, e como elas atuam para um determinado fim. Por exemplo, escolher entre EJB e ESB , entre Java o .NET etc… pode chegar no nivel de escolher a linguagem conforme a equipe (java ou ruby ) e por isso ele pode se confundir com o lider tecnico. O arquiteto escolhe quantos e quais os componentes da aplicação. De quantos e quais jars a aplicação será formada e dependencias de outas bibliotecas.
Em resumo, o arquiteto cuida de todo o ambiente externo ao codigo mas que o influencia ou é influenciado por ele.
O designer cuida dos andares ( camadas) ele cuida de como montar cada componente da arquitetura baseado nas tecnologias, plataformas e protocolos escolhidos pelo arquiteto. Ele escolhe entre frameworks que fazem o mesmo na arquitetura, por exemplo, o arquiteto define o uso de java e um servlet container. o designer escolhe entre o tomcat e o jetty (ou outros). Ele escolhe e aplica padrões de design , ele define práticas de programação, ele define estilo de programação ( checkstyle) . Em resumo, ele cuida do codigo que constroi cada componente da arquitetura.
A arquitetura é executável ? sim. Podemos fazer provas de conceito de arquitetura? sim. Mas isso não significa que o arquiteto escreve codigo ou que a arquitetura é algo codificável.
A decisão de um designer é facilmente refactorada a de um arquiteto não. Mudar de webservice para JMS representa mudar o como o sistema se comporta no ambiente, e suas dependências com esse ambiente e o como as outras aplicações enxergam esse sistema, ou seja, é mudar superficie de contato do sistema. Isso torna-o em outro sistema, mesmo que ele faça o mesmo.
Em nenhum momento o Robert fala que arquitetura é programável ou codificável. Ou que teria que ser. Ele fala que: arquitetura é sobre tomar decisões e que o arquiteto deve pertencer à equipa e que ele deve codificar a aplicação como qq outro membro da equipa. Tudo isto é verdade. E em nenhum momento ele afirma que arquitetura é algo que se codifica.
Como nota devo acrescentar que o que se fazia ou se achava ou não nos anos 70 e 80 não é relevante. Muitas das assunções feitas nesse tempo se mostram completamente irreais agora e o proprio Robert cita as ferramentas CASE como um exemplo de algo que não deu certo.
Eu tb sou defensor de uma aproximação arquitetura primeiro e já vi muitos sistemas falharem por terem uma arquitetura mais desenvolvida e desorganizada. Nem sei o que seria uma arquitetura de caixinha. You are overreacting.
Resumindo o assunto, depois que ouvi o que o Robert tinha a dizer eu achei extremamente válido e aprendi o nome de algo que já conhecia da prática,mas não conhecia o nome, nem sabia que era algo “institucionalizado” : software craftmanship. Acho que isto sim é a mensagem mais importante do dialogo e que tanto agilistas como tradicionalistas deveriam entender. A parte sobre robotizar o desenvolvimento teve um saida inteligente - dizendo que os IDE e as ferramentas são esses robots - mas quando apertado pelo entrevistador ele voltou um pouco atrás na ideia de um modelo executável que ele tinha começado por ser contra (CASE, MDA). Não acho que o dialogo se resume a uma provocação aos arquitetos mas sim um apelo a todos os desenvolvedores sérios a acordarem para a qualidade e orgulho na qualidade do software que produzem.
