Escolhendo frameworks e ferramentas

Primeiramente gostaria de agradecer ao Eduardo Miranda pela resposta em Escolhendo frameworks e ferramentas, e também para recomendar seu blog como leitura obrigatória a todos desenvolvedores ou entusiastas dotnet.

O texto abaixo era parte do tutorial sobre Model View Presenter que eu estou escrevendo, mas achei que iria contextualizar melhor a discussão (será que um meme dotnet daria certo?):

Que atire a primeira pedra quem nunca se perguntou: “Qual será a melhor opção? Desenvolver um framework do zero ou utilizar um pronto?”. Como o contexto em que a pergunta foi feita é o que determina se a resposta está correta ou não, na empresa onde trabalho temos nos empenhado muito para descobrir isso…

Nossa inteção é de não reinventar a roda e fugir um pouco da nossa tendência natural de fazer tudo do zero, querendo ou não temos dez dedos e dois olhos. Começamos dando uma olhada no MonoRail, um pouco foi sugestão minha, talvez tenha sido em função da minha recente admiração pelo Ruby On Rails e sua filosofia. Como nossas expectativas não foram correspondidas, partimos para o próximo: o Spring.NET Application Framework. Ouvia falar bastante sobre os seus recursos de Dependency Injection, mas quando percebi que seria mais fácil contratar um profissional Java com experiência em Spring e treiná-lo para trabalhar com C# do que capacitar um desenvolvedor .NET para utilizar o framework larguei de mão…

Faltaria antes avaliar o Web Client Software Factory, mas a esta altua do campeonato eu já estava chateado e com saudade de programar com C#, fazia mais de 2 meses que não escrevia uma linha de código .NET… Decidi mudar de estratégia e descobrir as diferenças em MVC, MVC II e MVP. Este artigo me ajudou bastante e me inspirou em meus testes. (O próximo post será sobre o assunto)

Abaixo, alguns pontos (bem alto nível) que julgo importante:

1. Produtividade: não está necessariamente relacionada com velocidade. Antes do dotnet trabalhei com Delphi, uma ferramente que induz o “DOM” Desenvolvimento Orientado a Mouse. Porém esta prática resulta em grandes problemas a médio prazo, profissionais com experiência nesta ferramenta sabem do que estou falando… Um framework deve induzir à utilização de boas práticas, mas não pode de forma alguma prejudicar o desempenho do profissional que o utiliza. Por melhor arquitetado que seja o framework, sempre necessitará de ferramentas que auxiliem na sua utilização. Somos desenvolvedores, não artesãos!
2. Capacidade de Evolução: observando os dois últimos anos podemos perceber o quanto os mecanismo de persistência, apresentação e lógica de negócios mudaram. E não foram apenas as nomeclaturas, surgiram, continuam surgindo e sempre surgirão novas técnicas, fluxos, ferramentas e conceitos. Quando uma nova técnica surge e agrega valor a meu trabalho, gosto de utilizar isso a meu favor. Entretanto, um framework com alto nível de acoplamento dificilmente permitirá que seu mecanismo de persistência seja substituído, pelo menos não sem um grande retrabalho.
3. Pé no chão: se a idéia é impedir uma invasão alienígena vamos precisar de canhões lasers, sintetizadores moleculares, uma central de comando, observadores 24 horas por dia e uma base lunar. Mas se minha cliente é uma nobre camponesa que sai pela manhã para colher amoras e pretende apenas manter o lobo mau distante porque oferecer tudo isso? Não seria melhor um spray de pimenta? Mais fácil, mais simples e barato! Assim também deve acontecer com os frameworks, jamais devem perder de vista a realidade que atendem..

Bom, era isto… Abraço! Comentei com sugestões e opiniões.