Escolhi o último dia para ser o voluntário da trilha “Arquitetura para o arquiteto”, portanto assisti todas as palestras do auditório principal.
O dia começou com Dan North da ThoughtWorks, que era o host da trilha, apresentando a si mesmo para a primeira palestra entitulada “Pimp my architecture”.
Dan Norh em sua palestra "Pimp my architecture"
Ele comentou um pouco sobre as qualidades de um bom arquiteto em uma equipe como sua habilidade de ser um coach por possuir influência sobre os demais.
Sugeriu “ouvir sempre” antes de falar pois caso você esteja certo continuará certo no momento que a pessoa terminar e se estiver errado terá sido salvo de uma situação contrangedora.
Também disse que sua função principal é tentar tornar os outros membros da equipe excelentes profissionais para que ele se torne cada vez mais desnecessári (e brincou que neste momento pode palestrar em congressos).
Outra sugestão interessante é ter um “shaman” na equipe, que é alguém que pode sempre lembrar os demais de como a arquitetura costumava ser e o quanto melhoramos.
Quanto à parte técnica mencionou o projeto Apache Ivy, que segundo sua opinião, gerencia melhor que o maven as depenências do projeto.
Às 10:45 foi a vez de Stefan Tilkov apresentar “Pensamentos na comparação entre genérico vs. específico” onde apresentou as diferentes fases da evolução de um arquiteto. Citou uma frase interessante: “alguns programadores, quando lidam com um problema tendem a tentar uma solução genérica… agora ficaram com dois problemas”.
Existem diversas considerações quando se trata de criar uma solução genérica ou específica. Quando se cria algo específico as pessoas que chegarem depois terão algo a mais para aprender para se tornarem parte da equipe. Outros fatores são o custo inicial, a performance do desenvolvimento, a performance em produção e o conhecimento necessários para a criação da solução específica.
Em todos os casos onde é necessária a decisão entre o genérico e o específico a resposta do “arquiteto sábio” é: depende.
Stefan Tilkov
Após o almoço foi a vez de Eric Evans apresentar “Strategic Design”. Foi uma excelente palestra sobre o capítulo 4 de seu livro que explica por onde começar em um projeto ou na melhoria de um projeto existente.
Brincou dizendo que a velocidade da equipe está relacionada com a velocidade do segundo pior programador pois todos sabem quem é o pior e acabam não passando nada pra ele.
Depois explicou o que é “destilar o domínio” em 3 partes. A primeira engloba os domínio genéricos que fazem parte da maioria dos sistemas como contabilidade e financeiro. Há também o subdomínios de suporte, que são importantes mas não são o principal. E o mais importante é o “core domain” que é realmente o que define a estratégia da empresa. É aquilo que faz valer a pena no desenvolvimento de um software.
Em seguida explicou o que é um contexto dentro de um aplicativo e disse achar incorreto criar apenas um modelo para todo o projeto. Dentro de cada contexto existe um modelo específico e dentro deste contexto não deve haver duplicidade. Porém é inevitável que não haja alguma duplicidade em sistemas enterprise pois a complexidade é muito maior.
Outro ponto importante é a criação de camadas de anti-corrupção que são barreiras entre um sistema legado e novas funcionalidades que não possuem condições de serem aplicadas sobre um design mal feito (porém foi o melhor que se pôde fazer na época).
Finalmente as “boas metas” são estabilizar o sistema legado corrigindo apenas aqueles 2 ou 3 pontos que estejam consumindo a maior parte do processamento e criar uma plataforma para que as novas idéias sejam aplicadas.
Eric Evans apresentando Strategic Design
Às 14:15 foi a vez de Kevlin Henney mostrar “Cinco considerações para arquitetos de software” onde falou um pouco sobre como obter uma visão mais afastada do código e tentar entender sua clareza, além de mostrar diversos casos reais e sua opinião de como melhorá-los, como por exemplo o pacote java.util.* que abrange tudo o que não faz parte de outros pacotes.
Gostei muito da primeira frase de Ludwig Wittgenstein que diz: “a diferença entre um bom e um mau arquiteto é que o mau arquiteto sucumbe a cada tentação e o bom resiste a ela”.
Ludwig Wittgenstein
O último palestrante do dia foi Gojko Adzic com a mensagem “mensageria não é só para bancos de investimento”. Ele quis dizer que a troca de mensagens parece algo muito complicado, de difícil implementação e com poucos casos práticos.
Citou dois casos práticos e muito comuns onde um serviço de mensagens é essencial e de fácil aplicação como o envio de um e-mail de confirmação após um registro em determinado site ou uma confirmação de compra. Com um processo assíncrono de mensageria você pode tentar enviar o e-mail mais tarde e torna seu código mais simples de ser testado. Além disso não restringe o processo de confirmação à um serviço externo como SMTP por exemplo. A primeira tem sucesso mesmo que a segunda não tenha. Outra grande vantagem é que é possível definir múltiplos observadores.
Ele ainda recomendou alguns serviços como ActiveMQ feito em Java, NServiceBus e AMQP que é uma tentativa de padronização dos serviços de mensagens.
Gojko Adzic
Seu recente livro chamado “Bridging the communication gap” foi muito bem avaliado por Dan North e é uma boa indicação de leitura.
Gojko Adzic e Dan North após palestra
No final do dia houve uma espécie de jogo ou brincadeira onde participaram Jim Webber, Martin Fowler, Michael Nygard, Ian Robinson, Steve Vinoski, Ryan Slobojan e Dan North.
A platéia fazia uma pergunta e os membros do painel tinham apenas um minuto para respondê-la. Foram perguntas feitas para descontrair o pessoal no final do evento como “qual foi o pior código que você já escreveu?”.
Game Show: It's a Bullseye!
Jim Webber apresentando o game show
Acho que deu pra perceber o quanto valeu a pena ter participado. Tentei resumir ao máximo as idéias principais de cada palestra. Lembrando que é possível fazer o download dos slides da maioria delas.
Quem quiser mais informações sobre algum dos temas aqui expostos ou tiver comentários favor entrar em contato.
Abraço!
