Low Cost Maintenance Development - LCMD

Sempre quis criar meu próprio acrônimo, mas, infelizmente nunca tive a necessidade ou oportunidade. Creio que encontrei uma oportunidade: o LCMD. Vejamos...

Outro dia, estávamos discutindo Waldemir, Rogério, Condé, Markus e eu sobre como ajudar aos arquitetos a escolherem entre MVC e outras tecnologias de interface oferecidas pela Microsoft. Nesta ocasião propus a eles diferenciarmos as tecnologias sobre alguns aspectos como: a capacidade de apresentação, o tipo de navegação suportado pelas ferramentas, e, por fim, o ferramental disponível para este desenvolvimento.

• Capacidade de apresentação: É simples... WPF é mais capaz que Silverlight por poder ter acesso a toda API gráfica. Silverlight é mais que ASP.Net com Ajax( ou não), porque traz maior capacidade gráfica e de interação e assim por diante.
• Ferramental : Tenta discernir questões como: é fácil fazer um binding? O editor é simples e poderoso como um Expression Blend? É fácil depurar? A instalação é necessária ou simples? etc.
• Tipo de Navegação: aqui era a minha dica para a introdução do MVC. Imaginava algo como uso de hyperlinks, binding, code behind ou o SoC (separation of concerns) como o MVC propõe.

Perfeita a divisão? Claro que não. É sempre nossa escolha definir as fronteiras, e minha intenção aqui era mostrar que temos um espectro de tecnologias que percorrem 1) da apresentação rica à apresentação padrão (HTML web ou Cliente Windows) e 2) da engenharia simples ou RAD (Rapid Application Development) à engenharia complexa.

Oops... Eis o problema e a oportunidade: engenharia complexa é um péssimo nome. Quando usamos MVC ou MVP ou outro padrão qualquer, buscamos várias capacidades, mas talvez a mais fundamental seja a Facilidade de Manutenção (manutenabilidade) . Não procuramos a complexidade – é a existência de objetivos maiores, funcionais ou arquitetônicos, que nos leva à ela.

Daí o meu mais novo acrônimo: para diferenciar de Rapid Application Development precisamos do

                                                LCMD – Low Cost Maintenance Development

Definição: uma arquitetura, desenho e programação voltada para o baixo custo de manutenção do software.

Por que precisamos de um LDMC? Porque existem dados que correlacionam complexidade de um software com o custo da sua manutenção (e operação). Existem casos em que a manutenção e operação chegam a custar cerca de 75% do custo total do software em todo seu tempo de vida. Estes são normalmente softwares complexos e de missão crítica. A manutenção é alta porque a dinâmica do mercado exige um alto grau de mudanças funcionais sobre cargas e tecnologias que evoluem no tempo (de cliente/servidor para intranet, inclusão de serviços, etc.).

Se diferenciarmos assim, poderemos dizer que quem usa o MVC deve ganhar em manutenção ao compararmos com quem usa um form ASP.Net?

Resposta: Depende. O ASP.Net tem alta produtividade, tem muitos componentes prontos no mercado e pode ser excelente para projetos pequenos ou médios. O ASP.Net MVC, por sua vez, é menos produtivo, tem poucos componentes prontos, mas tem melhor manutenabilidade, além de permitir associar uma uri com o conteúdo dinâmico da página, tornando-a “searchable”.

E então, ...vocês compram o LCMD? (procurei um similar e não achei – se alguém souber, por favor, me avisa?)

 

PS.: Duas dicas finais:

1. Saiu o Visual Studio Team Test Quick Reference Guide: para quem usa o Visual Studio e trabalha com testes, é uma excelente ajuda;
2. O MSDN do Brasil lançou um DevCenter do Azure e junto uma série de vídeos sobre o Azure na página do Azure Academy. Boa diversão!

Comments

• Anonymous
  April 09, 2009
  PingBack from http://microsoft-sharepoint.simplynetdev.com/low-cost-maintenance-development-lcmd/

• Anonymous
  April 20, 2009
  The comment has been removed

• Anonymous
  April 30, 2009
  O último post do time do Entity Framework é bem interessante no contexto dos assuntos discutidos neste

• Anonymous
  May 08, 2009
  O MVC ainda acabou de dar os primeiros passos e acho também que ainda falta muito para ganhar a produtividade do WebForms. Não existe mundo perfeito nem projetos com 100% desenvolvedores arquitetos. Portanto levo sempre isso em consideração nas minhas avaliações.