Giovanni Bassi é Microsoft
Most Valuable Professional (MVP), certificado MCSD .Net e MCPD
Enterprise Application Developer. Trabalha com a plataforma .Net
desde que foi lançada. Sua principal atividade é como consultor
especialista em .Net, trabalhando focado principalmente em
arquitetura e melhores práticas.

Em seu trabalho, auxilia empresas
nas suas decisões relacionadas à arquitetura e na criação de
padrões, e trabalha diretamente na fase de análise de sistemas dos
projetos, construindo uma base sólida para o nascimento e
o crescimento de novas aplicações. Presta ainda consultoria em
processos e agilidade. Giovanni atua também como escritor, editor da
.Net Magazine, professor universitário, palestrante, organizador de
eventos, fundador de grupo de estudos sobre arquitetura de software
.Net Architects, entre muitos, muitos
outros.

Nesta entrevista, dá sua opinião sobre o melhor caminho para seguirmos no
futuro do desenvolvimento com .Net. Não deixe de ler até o fim.

Thomas Semple: Sei que você é
um grande adepto do Scrum. Em qualquer área do mundo, seja TI ou não, a cada hora
surge a palavra da moda, onde os gerentes tentam vender a qualquer
preço para seus diretores e clientes e evangelizam a sua equipe,
gastam fortuna com treinamentos etc. Você realmente acha que o Scrum é
o futuro, em termos de metodologia para desenvolvimento de software?
Será que daqui alguns anos, veremos o Scrum como mais uma tentativa
frustrada para gerenciar nossos processos caóticos de
desenvolvimento?

Giovanni Bassi: Não,
eu não acho que o Scrum é o futuro. Eu acho que o Scrum é uma das
formas de chegar lá. O futuro está nos valores expostos pelo
manifesto ágil.
O Scrum aplica estes valores, mas falha em expor melhores práticas
de engenharia e arquitetura de software. O XP, por outro lado,
resolve parte deste problema, colocando, por exemplo, que devemos
trabalhar com TDD. Ainda assim, não defendo que devemos usar XP ou
Scrum, mas sim que devemos usar os princípios e valores do manifesto
ágil, e que XP e Scrum são boas maneiras de fazer isso, mas não
são as únicas.

Respondendo,
então, à pergunta: será que os valores e princípios ágeis são o
futuro? Sim, são claramente o futuro, e são inevitáveis na
indústria de desenvolvimento de software. Pode ser que mudemos
detalhes das práticas de XP, Scrum, ou qualquer outra aplicação
concreta destes princípios, mas os princípios devem mudar nada ou
quase nada.

Com relação às metodologias que falharam e se não
estamos mais uma vez embarcando em mais uma metodologia que irá
fracassar, entendo que não. Oras, por que não, você deve estar se
perguntando, já que o histórico que temos é péssimo? Porque o
histórico que temos baseia-se todo em premissas que o manifesto ágil
não assume. O manifesto ágil entende que mudanças fazem parte do
desenvolvimento de qualquer software, e as abraça como parte do
processo. Entende que o processo de criação de um software é muito
criativo e em quase nada se parece com o processo de construção de
uma ponte.

Além disso, dada à falha dos processos anteriores,
baseados em modelos em cascata, com pouco feedback, e que assumiam
que sabiam demais, os processos ágeis baseiam-se em conceitos
opostos. Assumem que sabem pouco sobre o produto final, que
estimativas são, conforme o dicionário diz, cálculos aproximados,
e dividem a responsabilidade pelo sucesso de um projeto entre todos os
envolvidos, eliminando pontos de stress, como o gerente de projeto,
que centralizava todos os problemas e riscos de um projeto. Sabendo
disso, os modelos ágeis entendem que trabalham com um risco muito
grande, e por isso fazem gestão de risco o tempo todo, trabalhando e
retrabalhando para eliminar risco. Risco é algo que, em metodologias
não ágeis, é uma disciplina. Já em metodologias ágeis o risco
permeia todas as práticas do processo.

Falando um pouquinho
sobre arquitetura de software, vou propor dois cenários para
desenvolvimento futuro. E sua opinião,
qual é a melhor arquitetura e tecnologia para o desenvolvimento destes
softwares?

Cenário 01: Intranet corporativa, rodando
somente na rede interna, com no máximo 50 usuários.

Cenário 02: Tenho um portal de vendas online
que consome serviços de diversas outras empresas, para vendas dos
produtos. Preciso de muita velocidade, segurança, e possuo milhares
de acesso.

Como
bom arquiteto, digo que é impossível propor uma arquitetura ideal
para um cenário definido em duas linhas. Uma coisa que aprendi
nesses anos atuando com arquitetura é que não há receita de bolo,
cada projeto é diferente do outro. Mas posso dar algumas linhas para
avaliação.

No
primeiro caso, temos um número reduzido de usuários. Vou assumir que
estamos tratando de uma aplicação corporativa não muito complexa.
O mais comum nesse cenário é trabalhar uma aplicação web sem
processamento distribuído, que se conecta diretamente no banco de
dados. Para controlar o contato com as regras de negócio, geralmente
complexas, utilizo neste tipo de cenário Domain Driven Design. Note
que eu disse “mais comum”, mas não é o ideal. Em um ambiente
onde o cliente é Windows, o ideal é trabalhar com aplicações
desktop, feitas com WPF. Para trabalhar as atualizações das
aplicações, podemos usar ClickOnce. Muitas empresas desconsideram a
opção das aplicações desktop, porque hoje “tudo tem que ser
web”, mesmo que ninguém saiba o porquê desta decisão, nem TI,
nem o CIO, nem o usuário.

É comum que um dos motivos seja porque
eventualmente a aplicação pode precisar rodar via extranet. Em vez
de fazer uma análise real deste tipo de requisitos, as empresas
adotam um padrão para todas as aplicações, e paga mais caro por
isso, já que desenvolver aplicações web é mais caro e menos
produtivo do que desenvolver aplicações desktop. O Silverlight
agora aparece forte no mercado corporativo para ficar na metade deste
caminho, e pode ser a solução final deste problema, ainda que
também não seja tão produtivo quando desenvolver uma aplicação
em WPF.

No
segundo cenário, não há como fugir da computação distribuída. Eu
avaliaria os requisitos de consistência e, podendo estar
eventualmente consistente (veja o teorema CAP),
eu trabalharia o conceito de filas. Utilizaria DDD, também, para
manter as regras de negócio, e possivelmente adotaria command and
query separation, com uma base de dados específica
para leitura, a fim de aumentar a disponibilidade, e também o
conceito de filas de atualização entre a base transacional e a de
leitura.

Para habilitar toda a comunicação a tecnologia ideal é o
WCF, ainda mais agora que teremos em breve um servidor de aplicação
(codenome Dublin) sendo lançado, se juntando ao já muito bom WAS
para hospedagem dos serviços. Para o front-end, utilizaria ASP.Net
MVC, que nos permite maior controle sobre a arquitetura e sobre o
HTML, além da possibilidade de testar regras de interface gráfica
facilmente. No banco de dados, SQL Server 2008, sem stored
procedures.

Nos
dois cenários aplicaria testes unitários, integrados e funcionais,
sempre automatizados, para garantir flexibilidade de evolução e
garantia de qualidade.

Inspirado nos frameworks de desenvolvimento web que utilizam
linguagens dinâmicas, como o Ruby,
até o próprio Python com o Django e o TurboGears, a Microsoft
recentemente introduziu na plataforma .Net o conceito do MVC. Sabemos também que durante anos a
MS tentou trazer para o desenvolvimento web muito dos
conceitos do desenvolvimento Desktop. Você acredita
que a MS percebeu que estava seguindo um caminho “errado”
e mudou de rumo? Qual você acha que é futuro do desenvolvimento
Web? Para quais tecnologias o profissional de hoje precisa se
capacitar para o futuro?

Não
acho que a Microsoft percebeu que estava indo para o caminho errado.
A Microsoft é uma empresa e, como toda empresa, atende aos anseios
de um mercado. Em 2002, quando lançou o .Net, o mercado que usava o
stack Microsoft era dominado na interface gráfica por duas
tecnologias principalmente: o VB6, usado para aplicações
desktop, e o ASP3, para desenvolvimento web. O C++ e o VB6
eram usados para desenvolver componentes. O Java ganhava mercado
rapidamente, ao lado do PHP. A Microsoft quis atender um mercado que
conhecia VB6 e ASP3, e lançou o ASP.Net, com o Webforms, como única
alternativa para desenvolvimento sobre este framework. O Webforms
tinha um grande benefício: era fácil de entender ao programador
ASP3, que ganhava inúmeros benefícios, e soava muito natural ao
desenvolvedor VB6, que não sabia desenvolver para a web, já que o
Webforms abstrai muito do desenvolvimento web, como o Javascript, o
CSS, e até o HTML. É por isso que essa tecnologia foi um sucesso de
imediato: era extremamente poderosa, e tinha uma curva pouco íngreme
de aprendizado.

De
lá para cá muita coisa mudou. Parte do mercado pedia por mais controle,
ao mesmo tempo em que plataformas concorrentes passaram a oferecer
frameworks que direcionavam mais o desenvolvedor no caminho das boas
práticas. No próprio meio .Net começaram a surgir frameworks MVC,
como o excelente Monorail, parte do projeto Castle, liderado aqui
mesmo no Brasil. A Microsoft ouviu o mercado novamente e ofereceu uma
nova opção ao desenvolvimento web com o ASP.Net MVC. E ele é isso:
uma opção. O Webforms continua sendo evoluído, terá uma versão
nova no framework 4.0, totalmente independente do ASP.Net MVC, e
continuará evoluindo nas versões seguintes também. É também uma
ótima opção, mas em cenários diferentes.

Já
com relação ao futuro, na minha opinião o futuro da web está nas
aplicações RIA (Rich Internet Applications), fundamentadas em
tecnologias como o Silverlight e o Flex/Air. O HTML atingiu um
limite, e o usuário hoje possui expectativas que vão muito além do
que o HTML consegue entregar, mesmo com tecnologias como CSS e
bibliotecas de javascript, como o jQuery. O HTML 5, previsto para
ficar pronto em mais de uma década (lançamento oficial previsto
para 2022), chegará tarde demais no jogo, e ainda que alguns
navegadores o adotem, as maioria das empresas só construirão
conteúdo para essa tecnologia quando a maior parte dos navegadores a
implementarem de maneira consistente.

O que aprender para o
desenvolvimento web do futuro? A base está no Silverlight e nas
tecnologias que o acompanham, como o XAML, o Javascript, e outras
menos claras, mas que também estão lá, como o IronRuby e o
IronPython. Mas esse é um futuro não tão próximo, que virá com
adoção em massa para daqui a alguns anos. Para um futuro mais
imediato, o ASP.Net, com o Webforms e o ASP.Net MVC resolvem, junto
de tecnologias como o Javascript, o HTML e o CSS, obrigatórias para
qualquer pessoa que se classifique como desenvolvedor web.

Pegando carona na
pergunta anterior, a estratégia da Plataforma .Net é suportar
diversas linguagens, desde VB, C#, J#, até a recentemente
incorporada F#. Embora ainda não como linguagens de primeira classe,
a plataforma .Net suporta linguagens dinâmicas como o IronPython,
IronRuby, entre outras, que utilizam como base o DLR, permitindo rodar linguagens dinâmicas em cima do
CLR, que provê serviços comuns a todas as
linguagens suportadas pelo framework. Podemos listar mais de 50
linguagens que podem rodar na plataforma .Net, ainda que não
oficialmente suportado pela Microsoft. Pessoalmente acredito que o
profissional que deseja ter sucesso na área precisa conhecer mais de
uma linguagem. Além do VB.Net ou C# quais outras linguagens você
acredita que fará parte do dia a dia do desenvolvedor e por quê?

Há
um limite sobre a quantidade de informação que devemos suportar.
Para sermos fluentes em uma linguagem, leva tempo. Ainda assim,
podemos aprender e fazer pequenos experimentos com linguagens que não
são a nossa primeira. Nesse momento, até pelo hype que têm
levantado, as principais novas linguagens são Ruby (IronRuby no
.Net) e F#.

Ruby é uma linguagem incrível, extremamente expressiva
e útil em diversos contextos. Programar com Ruby é uma experiência
totalmente diferente de programar com C#, e não é uma linguagem
difícil de entender, ainda que, como qualquer linguagem, demore para se
conhecer profundamente, até por sua imensa flexibilidade. O F# é
uma linguagem que possui uma complexidade maior, é uma linguagem que
o desenvolvedor de C# se assusta ao entrar em contato com os exemplos
mais complexos, ele realmente não entende o que está lendo. Ao
mesmo tempo, o paradigma funcional, dominante no F#, traz um grande
aprendizado ao desenvolvedor de C# ou VB; ele aprende a fazer as
coisas de forma diferente.

Essas
são as linguagens novas. Há ainda uma linguagem mais famosa e, no
entanto, pouco conhecida: Javascript. O Javascript só agora está
sendo compreendido em todo o seu poder, devido às bibliotecas como o
jQuery. É uma linguagem extremamente flexível e prazerosa de se
programar, e traz conceitos como métodos anônimos há muito mais
tempo que o C#. Javascript é uma linguagem, infelizmente,
sub-aproveitada.

Por
fim, há linguagens muito interessantes no framework .Net, como o
Boo, independente, e o Axum, da própria Microsoft, que valem a pena
conhecer. E fora do .Net, uma linguagem simples que influenciou
diversas linguagens com que trabalhamos hoje, e que infelizmente é
pouco conhecida, é o Lisp, e que vale a pena conhecer pelo simples
fato de que ela nos permite ter uma perspectiva de onde alguns
conceitos, como as lambdas, saíram.

A Microsoft está
lançando o Visual Studio 2010 e você, como MVP, certamente já teve
acesso. Quais são as grandes novidades e o que ainda teremos que
esperar para uma próxima versão?

Essa
é uma pergunta que poderia se desdobrar em outra entrevista. Vou
tentar colocar algumas delas, que me chamaram mais atenção.

Gosto
muito das novidades da versão de arquitetura do Visual Studio Team
System, que vai permitir trabalhar UML dentro do Visual Studio, além
de diversos diagramas arquiteturais, como o de camadas, inclusive com
validação da arquitetura da solução.

O
Historical Debugger, uma nova funcionalidade que permite “voltar no
tempo” e ver valores de variáveis quando estamos depurando, e por
onde a aplicação depurado passou também é muito interessante.

As
novas versões do C# e do VB estão mais próximas e mais poderosas.
Ganharam características dinâmicas e estão interagindo melhor com
linguagens como o Ruby e o COM, além de mais fáceis de usar.
Por si só já valem a pena fazer a migração do Visual Studio 2008
para o 2010.

Os
editores visuais de WPF estão mais poderosos, é possível fazer
mais com eles do que era possível na versão anterior. O
ASP.Net MVC passa a fazer parte do Visual Studio na versão 2010, já
trabalhando com o framework 4.0.

Do
lado do servidor, o VSTS 2008 já suportava integração contínua, e
gostei muito da adição dos gated check-ins, que permitem reprovar
um check-in se ele estiver com erro de compilação ou nos testes.

A
Microsoft também está incluindo no VSTS uma nova ferramenta de
testes funcionais que é fantástica, facilitando o papel do
testador, e também o do desenvolvedor quando for arrumar os bugs
encontrados. Vale a pena dar uma olhada.

Agradeço ao Giovanni
por este excelente bate papo, que certamente abriu nossas mentes para
o futuro do desenvolvimento de software. Se você deseja entrar em
contato com o Giovanni, acesse http://giovannibassi.com/.
Recomendo também que siga seu blog http://unplugged.giggio.net/, um dos melhores blogs de .Net !

Forte abraço e até a próxima!