Este é um dos livros que recomendo fortemente a leitura e que está na minha seção de indicados. Acredito que todo bom desenvolvedor deve dar uma boa lida, pois os benefícios oferecidos pela técnica são inúmeros.

Embora eu prefira livros impressos e tenha este é uma ótima maneira de economizar e ter o livro disponível sempre que precisar para referências.

Fica ai a dica!

O local será o mesmo das outras vezes, na UNIP Jaguaré. Nesta semana o Giovanni irá falar um pouco a respeito de Domain Driven Design.

A participação é aberta e muito bem vinda. Quem ainda não mandou seus dados pode fazer pelo blog do Giovanni ou pelo grupo do Google onde também está disponível a pauta para próxima reunião.

Na última reunião falei sobre Scrum e o vídeo da apresentação está disponível aqui no blog e no site do grupo.

Para quem já sabe o que é mais não se juntou ainda ou não acompanha, faço um convite a conhecer através do nosso não-muito-joia-ainda site e se juntar também ao nosso grupo do Google onde algumas discussões bem legais já foram iniciadas.

Desde a primeira reunião do grupo combinamos que em todas as nossas reuniões alguém iria fazer uma apresentação para que posteriormente o grupo discutisse o assunto e a primeira apresentação sou eu quem vai fazer. A idéia não é dar uma aula ou falar como “o expert” do assunto, mas tentar passar experiências interessantes para todos.

Esta primeira apresentação vai ser a respeito de Scrum e como estamos utilizamos dentro da nossa equipe.

Na sequência da apresentação eu disponibilizo os slides aqui para quem não pôde ir. É possível que consigamos gravar a reunião. Se der certo, disponibilizo também por aqui.

Junte-se a nós!

Como o Giovanni já blogou sobre o que rolou na reunião não vale repetir tudo aqui, mas sim linkar para o post dele.

A reunião foi excelente, muito divertida e de um ótimo nível. Felizmente conseguimos reunir um grupo que não chegava em acordos sempre e isso é fundamental para crescermos.

Os interessados em entrar no grupo podem me mandar email, comentar aqui ou então postar no próprio blog do Giovanni. “Você decide”.

Enfim, a primeira reunião é sabado agora na UNIP da Marginal Pinheiros. Quem tiver interesse será muito bem vindo.

Os detalhes podem ser encontrados aqui no blog do Giovanni.

Esse é um documento, que apesar de antigo, é bastante interessante e ainda atual na maioria dos aspectos. Eu descobri esse documento cerca de uns 1 ano e meio atrás quando procurava melhores práticas para aplicar no primeiro sistema pelo qual eu seria responsável.

Sempre achei uma pena o fato de eles não manterem esse documento atualizado. Talvez isso acontecesse, pois é sempre complicado falar a respeito de arquiteturas de referência já que cada caso é um caso.

No entanto, pra nossa felicidade, eles lançaram uma nova versão esse mês e está disponível através deste link no Codeplex.

O documento apresenta quais decisões tomar e porque toma-las em uma série de cenários. Desde aplicações desktop até aplicações web com SOA e RIA.

Ainda não tive tempo de ir a fundo no documento, mas parece estar bastante atualizado.

Há algum tempo atrás, eu procurava saber porque raios alguém construiria uma aplicação utilizando WCF/Remoting/Web Services se essa aplicação não teria seus componentes de negócio reutilizados. Nunca entendi isso e achava um absurdo a Microsoft não disponibilizar nenhum “guia” (eu nunca achei, pelo menos) que dissesse quando devo distribuir as camadas de uma aplicação fisicamente e quando não. Infelizmente algumas coisas nós acabamos aprendendo só depois de aplicar e apanhar um pouco.

Nesse documento, pelo menos este ponto a Microsoft esclareceu e isso já é suficiente pra me deixar bastante feliz.

Esse documento não vai evitar que nós, desenvolvedores, cometamos erros, mas acredito que é muito importante os fornecedores de plataformas e tecnologias grandes como .NET se pronunciarem e fornecerem guias, mesmo que simples e com uma visão bem macro, para que as pessoas não fiquem perdidas e cometam erros demais em seus sistemas.

Ponto pra Microsoft.

Na realidade, eu não gosto muito do título, pois por toda minha vida profissional (que não é tããããão longa assim) eu acreditei que esse cara era o guru da sapiência e que ele nunca ficaria sem respostas a qualquer pergunta que fosse feita. Então, soa como uma responsabilidade muitooooo grande (e é mesmo) pra um desenvolvedor de apenas 21 anos como eu. De fato, deveria ser assim, mas é humanamente impossível ser ao mesmo tempo generalista e especialista em todas as áreas. Isso me frustrou um pouco, mas ao mesmo tempo, por outro lado abriu minha cabeça e me fez reconhecer que existem diversos tipos de arquitetos, cada um na sua. E que existem pessoas, mesmo sem carregar o título, que também fazem arquitetura em um momento ou outro de um projeto. É baseado em conhecimento próprio e utilizando o conhecimento dos membros da equipe que o arquiteto deve trabalhar.

Inicialmente, dentro da área de software (imaginando que infra-estrutura não exista) eu identifico dois principais arquitetos: Arquiteto de Soluções ou Corporativo e Arquiteto de Sistemas. O primeiro deles define quais tecnologias, metodologias e ambientes serão utilizados para os sistemas da empresa e procura manter todos os sistemas seguindo essas linhas agindo de forma incisiva nas fronteiras entre implementação e processos de negócio sem dar muita atenção nos detalhes técnicos de cada sistema.

Já o segundo, que é onde eu me encaixo por trabalhar em consultoria atendendo a diversos clientes, é o cara que dado um projeto deve atuar em todas as etapas da construção do sistema. Desde levantamentos inicias, passando por implementação e até roll-out em produção. Além das habilidades técnicas que são imprescendiveis nesse papel e isso ninguém pode negar, o arquiteto deve ser um cara balanceado pra atuar como um mediador entre todos os stakeholders do projeto. Em um projeto com papéis bem definidos, a tendência é que cada um cuide das apenas das suas responsabilidades. Isso é bom, pois cada especialista atua onde mais conhece, mas se não houver cuidado, pode fazer com que os principios inicialmente definidos não sejam seguidos. É ai onde o arquiteto deve entrar pra fazer com que todas as diretivas sejam seguidas. Isso exige liderança, habilidades em negociação e muitas vezes pulso forte pra suportar caras feias que aparecem quando uma decisão não agrada a todos.

No âmbito técnico, além de definir um modelo a ser seguido para implementação, ele deve atuar junto a equipe de análise nas etapas de modelagem a fim de entender do negócio para que seja possível escolher as tecnologias que melhor se encaixam no domínio de negócio. Uma vez modelado o domínio de negócio e tendo as tecnologias definidas, ele deve atuar junto a equipe de desenvolvimento guiando a implementação e removendo possíveis roadblocks. Sempre que houver um conflito técnico, ele deve atuar em prol do projeto para decidir a questão independente de chateação ou não por parte dos membros da equipe.

E pra finalizar, deve conhecer metodologia e processos de desenvolvimento a fim de tornar o planejamento e execução dos projetos mais baratos e acertivos.

Dava pra ficar enumerando a respeito das skills e habilidades que um arquiteto deve ter, mas em resumo acho que isso é o principal. O importante é ter em mente que não importa o quanto estudemos nunca vamos chegar no que eu imaginava que existia: arquitetos-sabe-tudo.

Ao longo dos dias vou procurar postar entries nessa categoria pra ir complementando os pensamentos e ai, quem sabe um dia, eu formato tudo num grande apinhado de informações! ehehehe…

Soçarba