Acabo de assistir uma conversa com Juval Lowy, que é autor do livro “Programming WCF Services” (o livro de WCF do “peixinho”, mas informações aqui), gravada durante o TechEd americano deste ano, onde ele fala de Interface Based Design. Ele explica algo que muitos ainda não entram ainda em contato: desenvolvimento baseado em abstrações, e porque isso é bom. Ele bate forte no desenvolvimento baseado em classes concretas ou até em classes abstratas, e defende que o uso de interfaces para classes de negócio deve ser generalizado. O vídeo é em inglês, sem legendas. Recomendo assistir.

Isso é um conceito com o qual concordo, mas que acho que deve ser utilizado com cuidado, e não em todo lugar. Bem utilizado é poderosíssimo, e realmente, foram poucas as vezes que o vi utilizado, e das vezes que vi, não foram todos os usos bem direcionados. Um bom uso de interfaces facilita nos testes, desacopla o design, e deixa a aplicação como um todo mais flexível.

E você, tem usado Interfaces no seu dia a dia? O que acha disso?

Foi lançada uma carta de sugestão de melhorias ao Entity Framework, colocando diversos pontos em que ele precisa ser melhorado. Para mim, que agora estou focadíssimo em DDD, o Entity Framework tem alguns problemas que precisam mesmo de resolução. A carta foi feita em formato de abaixo assinado.

Se interessar, leiam e assinem. Tem, inclusive, assinatura de vários MVPs também:

ADO .NET Entity Framework Vote of No Confidence

Acabo de por as mãos no novo Visual Studio, que vai suceder o Visual Studio 2008, de codename Rosario. A Microsoft já tem uma página só para ele, onde você pode baixar uma imagem do Virtual PC com Windows Server 2003 (porque não 2008, não é?) para rodá-lo, já com SQL Server, Sharepoint e Team Foundation Server.

É o sonho de qualquer arquiteto de software que trabalhe em ambiente Microsoft (e tem ambiente melhor?). Até hoje eu uso o Visio para modelar meus casos de uso, diagramas de sequência e atividades. O diagrama de classes já existe no Visual Studio e ele é lindo, já se mantem totalmente atualizado com relação ao código, é possível adicionar métodos, propriedades e eventos, e trabalhar associação e herança. Quem lê meus artigos na .Net Magazine sabe, uso direto os diagramas para apresentar as soluções. Mas, passado este momento, sou obrigado a criar os outros diagramas no Visio. Porque? E para interagir com o resto do Team System, como o Team Foundation Server? A não ser que eu faça de cada diagrama um arquivo, não é muito fácil associar esses itens à work items (entre outros problemas).

Pois é, aí entra o novo Visual Studio. O vi anunciado no Tech-ed americano. Foi difícil acreditar no que vi. Vi um diagrama das camadas da aplicação, dentro do Visual Studio. E do Visual Studio 2008, porque eu reconheci a cara dele. Não era possível. Fui verificar na minha versão Team Suite, que tem tudo que pode ter, e não tinha. Oras, onde estava? Então descobri o Rosario.

Coloco abaixo algumas mudanças. Para começar, vejam o Add New Item. Reparem nos novos itens, como diagrama de sequência e atividades:

Abaixo um diagrama de casos de uso. Como é uma versão inicial, a usabilidade ainda está bem ruinzinha, mas já dá para ver onde vai chegar. E ele está suportando inclusive os cenários de uso. Imagina você associando um use case a uma função ou grupo de funções ou classes? Ia ser lindo.

Abaixo há o Architecture Explorer do Visual Studio. É possível navegar por toda a solução, tipos, métodos, etc. Para criar um teste basta selecionar “Test” (vejam janela da direita). Mas cuidado, dá pau ainda (dá-lhe código alpha…). Para compor um diagrama de sequência basta selecionar “Insert into Active Diagram”. Eu fiz isso. E funciona. E é lindo. Eu nem acreditei. Veja o resultado na imagem em seguida.

Esse diagrama de sequência foi feito sozinho pelo Visual Studio, analisando o código digitado. Ele verificou as interações do código e compôs o diagrama.

Mais fácil atualizar a documentação impossível. Imagina que ao final do projeto você clica em um botão e fala “gera”, e do outro lado sai um PDF ou XPS prontinho. Acabou aquele problema de documentação desatualizada no final do projeto.

Enfim, vou escrever um pouco mais assim que conhecê-lo melhor e vou contando por aqui nos próximos posts.

Em uma conversa recente o Fábio Camara me indicou um artigo do Fowler para ler. Se você não sabe quem é o Fowler, visite o site dele, busque seu legado (livros, artigos, etc) e vai perceber que o cara é uma bruta referência no mundo do desenvolvimento de software. Enfim, o artigo é intitulado “Who needs an architect?”, ou, “Quem precisa de um arquiteto?”, e sendo recomendado pelo Fábio e escrito pelo Fowler, não dá para deixar de ler, certo?

De cara, quando o Fábio falou o nome do artigo eu respondi a ele (antes de ler o artigo): qualquer software que contenha um mínimo de complexidade precisa ser acompanhado por um arquiteto de soluções. No que ele retrucou que eu ainda não tinha lido o artigo. Oras, como eu poderia conceber que não precisamos de arquitetos? É isso que eu mais faço, é minha paixão, é o que eu faço melhor em desenvolvimento de software: eu construo arquiteturas que entregam soluções que funcionam, focando em todos aqueles conceitos que já conhecemos: facilidade de manutenção, escalabilidade, segurança, confiabilidade, etc, etc.

Pois é, agora eu li o artigo. Percebo que o grande problema que o artigo tenta atacar é a ambiguidade da palavra arquiteto. O Fowloer propõe então uma palavra alternativa: “guide”. O artigo do Fowler contrapõe o arquiteto que constrói um sistema com bases fortes que não devem mudar e o que contrói um sistema com bases fortes e que sabe que elas vão mudar. Contrapõe o arquiteto “todo-poderoso” e o arquiteto colaborativo. E contrapões mais um monte de outras coisas. Acho que a leitura vale a pena, já que acrescenta à discussão da ambiguidade da arquitetura.

Por acaso, a última edição do Architecture Journal (do qual eu já havia falado antes) fala do papel do arquiteto. (Pegue a sua edição aqui - ainda não saiu em português, mas costuma sair logo. Ele é gratuito e você pode até receber uma cópia impressa em casa sem custo algum, nem postagem.) O site Skyscrapr, da Microsoft, também já tocou no assunto da ambiguidade da palavra, e separou os arquitetos em três: soluções, corporativos e infraestrutura.

Eu acho que precisamos sim de arquitetos, e precisamos de uma lingua mais rica também. Desde sempre definir coisas diferentes pelo mesmo nome causa confusão. Não acho “guide” um bom nome para o papel de um profissional colaborativo responsável por arquitetura. O assunto não se esgota fácil, então termino por aqui, deixando a discussão no ar. Há de montes de montes para enriquecer a discussão. O que você acha?

Acaba de chegar em casa a 14ª edição do Architecture Jornal, jornal de arquitetura da Microsoft. O jornal, que na verdade é uma revista, é excelente, com vários artigos e entrevistas interessantes. A edição deste mês fala de arquitetura mobile. Nos meses anteriores já se falou de Software + Services, Workflow, Software Factories e vários outros assuntos instigantes.

A assinatura pode ser eletrônica, onde eles te mandam o PDF (porque não XPS???), em mídia impressa, ou ambos, e o melhor: é de graça. Eu leio muito online, ou seja, acho bom de vez em quando pegar numa revista impressa.

Para facilitar a Microsoft liberou a pouco tempo um reader, é só baixar e ele atualiza a edição atual sozinho e dá também acesso às edições anteriores. Não bastasse isso, é um bom exemplo de WPF.

Resumindo: se você ainda não leu, dê uma olhada, vale a pena.