Semana Groovy 24! – Grails 3.0-M1 lançado!

Grails 3.0 M1 liberado para testes

Sem sombra de dúvidas o grande acontecimento da semana para nós foi a liberação do Grails 3.0 M1 para que possamos testar o framework. Abaixo seguem alguns links para os que desejam matar a curiosidade:

O download pode ser feito neste link:  https://github.com/grails/grails-core/releases/tag/v3.0.0.M1

Graeme Rocher gravou uma demonstração do framework que pode ser assistida neste link: https://www.youtube.com/watch?v=aro3_RZqgtU

Na documentação já começaram a escrever sobre as novidades da versão. Ainda falta muita coisa, mas acho que já dá pra se ter uma idéia. – http://grails.github.io/grails-doc/3.0.x/guide/introduction.html#whatsNew

Segundo evento da Maratona Groovy e Grails: “O que ganhamos com Groovy?”

Neste webinar gratuito irei expor o ecossistema Groovy. Veremos rápidamente alguns dos seus aspectos e em seguida uma série de aplicações interessantes da linguagem.

Anote na sua agenda: dia 4/2/2015 às 20 horas. Para se inscrever, basta acessar este link: http://institutopangea.org/curso/9-webinar-o-que-ganhamos-com-groovy?a=110

A propósito, todos os eventos são gravados e estarão disponíveis para quem se inscrever. Sendo assim, caso você chegue atrasado depois pode compensar assistindo os trechos que por acaso tenha perdido. :)

Posts

O Jedi das Collections – Jonatas Emídio nos faz uma rápida introdução ao GroovyCollections – http://santograils.org/2015/01/30/o-jedi-das-collections/

Grails 3.0.0 M1 Asset Pipeline Tips and Tricks – Começam a aparecer os primeiros posts sobre Grails 3.0. – http://davydotcom.com/blog/2015-01-29-grails-3-0-0-m1-asset-pipeline-tips-tricks

Groovy Goodness publicou também três posts interessantes sobre collections:

Getting all but last element in a collection with Init method – http://mrhaki.blogspot.com.br/2015/01/groovy-goodness-getting-all-but-last.html

Pop and Push elements in a list – http://mrhaki.blogspot.com.br/2015/01/groovy-goodness-pop-and-push-items-in.html

Getting the indices of a collection – http://mrhaki.blogspot.com.br/2015/01/groovy-goodness-getting-indices-of.html

Uma matéria rápida na InfoQ sobre o suporte a Android no Groovy 2.4 – http://www.infoq.com/news/2015/01/groovy14-android

Apresentações

Testing Grails – uma excelente apresentação no InfoQ sobre como escrever testes em Grails – http://www.infoq.com/presentations/grails-testing-2014

Ratpack Web Framework – um framework que na minha opinião você deveria prestar atenção. Uma bela apresentação no InfoQ – http://www.infoq.com/presentations/ratpack-2014

Dicas de Grails da itexto: mapeando views – mais um vídeo da série “Dicas de Grails” publicado – https://www.youtube.com/watch?v=A_ZLQvGHv3E

Lançamentos

Grooscript 1.0 – Finalmente foi lançada a versão 1.0 do Grooscript, que nos permite compilar código Groovy em JavaScript! –  http://grooscript.org/announcement.html

Projetos interessantes

Groovy Sandbox – permite executar scripts Groovy em um ambiente seguro. Um projeto extremamente interessante e útil para administradores de sistemas. – https://github.com/kohsuke/groovy-sandbox

Tipagem dinâmica ou estática?

Já se perguntou a respeito da vantagem de se usar tipagem dinâmica em uma linguagem como Groovy? Se sim, seguem alguns artigos muito interessantes a respeito.

Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages – Erik Meijer e Peter Drayton – Artigo interessantíssimo sobre o assunto que leva em consideração não o que tipagem dinâmica ou estática são, mas sim o que programadores realmente querem ao falar sobre o tema. – www.ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04meijer.pdf

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

Semana Groovy 23 – Maratona Groovy e Grails chegando!

Primeiro evento da Maratona Groovy e Grails: panorama!

maratona_groovy_grails

Dia 28/1 às 20 horas (horário de Brasília) ocorrerá o webinar “Panorama Groovy e Grails” no qual farei uma apresentação panorâmica sobre estas duas tecnologias. Você entenderá por que as chamo de pontes e como você pode (e deve) tirar proveito das mesmas!

Para se inscrever, clique neste link: http://institutopangea.org/curso/8-webinar-panorama-groovy-e-grails?a=110

Ah, e por que as chamo de pontes? Já falei sobre isto neste link: http://www.itexto.net/devkico/?p=2025

Canal da itexto no YouTube

logo_freehand

A itexto possuí agora um canal no YouTube no qual publicaremos vídeos sobre as tecnologias que dominamos. Para começar, criamos a série “Dicas de Grails” que expõe aspectos do framework que muitas vezes são ignorados por seus usuários mas que podem tornar sua vida muito mais produtiva.

A partir de fevereiro serão publicados vídeos semanalmente. Para se inscrever, basta clicar neste link: https://www.youtube.com/channel/UCRKpnCLGZCrVEQu9rijqYeQ

Posts

Entrevista de Graeme Rocher sobre a saída da Pivotal – http://jaxenter.com/grails-future-113958.html

Um artigo rápido no site Jaxenter sobre o lançamento da versão 2.4 do Groovy com suporte a desenvolvimento Android – http://jaxenter.com/groovy-2-4-113941.html

“Keep calm & Groovy on!” – Post da Object Partners sobre a saída da Pivotal –  http://www.objectpartners.com/2015/01/23/keep-calm-groovy-on

Groovy Podcast ep. 5 – Com Graeme Rocher e Guillaume Laforge. Novidades sobre a questão da Pivotal e as novidades que virão para o ecossistema Groovy e Grails para 2015 – https://www.youtube.com/watch?v=UgpPy1LvXA0

The Future of Groovy – Peter Ledbrook expõe sua visão sobre o futuro da linguagem Groovy e seu ecossistema. Em breve escreverá sobre Grails. – http://blog.cacoethes.co.uk/groovyandgrails/the-future-of-groovy

(Este papo todo de Pivotal já está ficando chato, não acham? Espero que na próxima edição surjam links melhores para compartilhar com vocês)

Why Gradle – Finalmente outro assunto: Peter Ledbrook falando sobre Gradle. Leitura interessante para quem tem curiosidade sobre este sistema de build – http://blog.cacoethes.co.uk/software/why-gradle

Projetos interessantes baseados em Groovy mas pouco conhecidos

ORMLite – Imagine um ORM implementado em aproximadamente 1000 linhas de Groovy – https://code.google.com/p/ormlite/wiki/API

Gracelets – Facets + Groovy! Já disse o suficiente :) – http://sourceforge.net/projects/gracelets/

Como Groovy nasceu

Post no qual James Strachan (o real criador da linguagem) anuncia Groovy para o mundo. Interessante para entender as razões que levaram à criação da linguagem. – http://radio-weblogs.com/0112098/2003/08/29.html

Lançamento

Groovy Document Builder – criado por Craig Burke, tem como objetivo principal facilitar a geração de documentos nos formatos PDF e Word. Vale à pena ler o anúncio. – http://www.craigburke.com/2015/01/22/groovy-document-builder.html

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

Semana Groovy 22! (histórica!)

Nada melhor que na primeira Semana Groovy de 2015 começarmos com o pé direito e uma série de notícias e novidades que mudarão bastante (e para melhor) a nossa vida. Como verão, não foi por acaso que atrasei tanto a publicação desta edição: estive bastante ocupado com alguns projetos que divulgo agora. :)

Maratona Groovy e Grails pelo Instituto Pangea!

Em 2014 ministrei meu primeiro webinar sobre Groovy e Grails pelo Instituto Pangea e a recepção foi simplesmente excelente. Então pensamos: por que não repetir a dose, mas com esteroides? O resultado é a “Maratona Groovy e Grails”. Serão quatro webinares gratuitos nos quais apresentarei diversos aspectos sobre o mundo Groovy.

Dia 28/1 irei apresentar o “Panorama Groovy e Grails“. Vou mostrar por alto o que é Groovy, quais as vantagens da linguagem e o que ela nos trás de novo. Você entenderá por que digo que esta linguagem é uma excelente porta de entrada para quem quer entrar no mundo Java e também por que pode nos tornar melhores programadores. Em seguida, mostrarei o Grails e vocês verão como é trabalhar com este framework.

Dia 4/2 será o evento “O que ganhamos com Groovy?“. Groovy não é só a linguagem de programação por trás do Grails: há todo um ecossistema e oportunidades que apresentarei neste webinar e que, acredito, todos nós devemos tirar máximo proveito.

No dia 10/2 ocorrerá “Grails na prática“: vou construir junto com vocês uma aplicação web Grails do zero. Iremos partir da modelagem da aplicação, passando pela implementação e, finalmente, sua implantação em um servidor de aplicações. É uma experiência muito boa para que vocês conheçam como é o fluxo de trabalho que o framework nos oferece.

Finalmente, no dia 12/2 vamos ter o “Groovy e Grails no mundo real” no qual convido alguns membros da comunidade nacional para contarem suas experiências. É uma excelente oportunidade para ver casos reais de uso: as principais dificuldades e ganhos experimentados por aqueles que usam as tecnologias no seu dia a dia.

Se interessou? No vídeo a seguir falo um pouco mais sobre os eventos!

Treinamentos itexto de Groovy e Grails

logo_freehand

Este é um ano importantíssimo e muito feliz para a itexto: estamos lançando alguns produtos voltados para a comunidade, dos quais os principais neste momento são os treinamentos de Groovy e Grails. Você pode ter uma visão geral sobre o modo como trabalhamos neste link.

Há algumas ementas que propomos, mas você ou sua empresa são livres para customizá-las de acordo com suas necessidades. Seguem os descritivos dos nossos treinamentos Groovy e Grails.

E estão vindo mais novidades por aí. Meu livro já está bem adiantado e deve ser lançado por agora. O que posso adiantar é que, bem: digamos que está com a profundidade que acredito merecermos e seu formato é ágil como Groovy e Grails.

Outra novidade importantíssima que virá são mais melhorias no Grails Brasil: coisas que vocês com certeza vão gostar. Acreditamos muito em comunidades, e há ainda mais coisas por vir. :)

E a Pivotal pulou fora

A notícia da semana foi sem dúvidas o anúncio da Pivotal de que irão parar de financiar os projetos Groovy e Grails a partir do dia 31 de março deste mês. Foi um anúncio que pegou a todos nós de surpresa e, claro, gerou aquele frio na barriga com relação a estas tecnologias. Já adianto pra vocês algo: não é necessário se preocupar, pois Groovy e Grails já existiam bem antes da Pivotal e com certeza continuarão ainda por um bom tempo após esta.

Seguem alguns links sobre o assunto para que vocês saibam melhor o que aconteceu e para onde iremos.

Groovy e Grails sem a Pivotal: e daí? – Meu parecer sobre a situação no qual mostro que este é apenas o modo como o mundo open source funciona. Nada para nos assustar. :)

O anúncio da Pivotal – o post que abalou a Internet esta semana. Reparem um detalhe: a própria Pivotal diz que parou o financiamento por que mais da metade das contribuiçoes aos projetos hoje vêm da comunidade.

O FAQ da Pivotal sobre sua decisão – uma leitura interessante que torna mais clara a postura da empresa.

O anúncio do acontecimento feito pelo Graeme Rocher

O anúncio do acontecimento feito pelo Guillaume LaForge

A entrevista que Guillaume LaForge deu ao site InfoQ

A repercussão no Grails Brasil

Um texto interessante no site IntelliGrape: “Groovy and Grails: GR8 without Pivotal

Após ler todos estes posts, acredito que se você sentia algum medo, este deixou de existir. Apenas para lembrar, um exemplo recente: quando a Nokia abandonou o projeto Qt, ele continuou, prosperou, e a Nokia se foi. Esta é a beleza do código aberto e da comunidade: nós definimos o futuro da tecnologia.

Lançamentos importantes

Groovy 2.4 lançado!

Este é um release importantíssimo pois é o primeiro que oferece suporte ao desenvolvimento de aplicações Android. Acredito que será algo tão ou mais revolucionário que o próprio Grails. Você pode ler o anúncio aqui.

Outros lançamentos

Spring Batch 3.0.3

Spring Boot 1.2.1

 Spring Session, um novo projeto da Spring Source que resolve diversos problemas interessantes sobre gestão de sessões e que, na minha opinião, vocês deveriam prestar bastante atenção.

Posts interessantes

Groovy Weekly 54 – Uma edição histórica no site do Guillaume LaForge

Dois posts meus que tiveram uma boa repercussão. “O que é legado?” e “A crescente irrelevância do MongoDB“. O segundo traduzi para o inglês e fiquei espantado com o efeito que teve no exterior!

 

 

Groovy e Grails sem Pivotal: e daí?

groovylogoMinha história com Groovy e Grails é velha e você pode ler aqui. Quando vi ontem o post da Pivotal dizendo que não iriam mais financiar Groovy e Grails não achei que fosse uma notícia boa ou ruim. Para quem acompanha e trabalha com projetos open source (e já possuí alguma maturidade) fica claro que é apenas notícia. Financiadores de projetos open source vêm e vão, mas o que mantém viva a coisa é a comunidade.

Groovy e Grails já existiam bem antes da Pivotal e continuarão a existir depois. Um financiador ajuda bastante mantendo uma equipe focada no desenvolvimento do framework e linguagem, mas se você observar diversos outros projetos open source bem sucedidos notará que nem sempre existe este grande financiador. Normalmente são mantidos pela própria comunidade ou seus criadores originais que fazem dinheiro com consultorias, livros, artigos, etc.

Muitas vezes chegamos até mesmo a pensar que grandes instituições mantém projetos open source mas na prática quem realmente mantém é um grupo pequeno que se dedica ao projeto e que sequer é pago. Basta ver a infinidade de projetos mantidos pela Apache. Alguns exemplos? Wicket, MyFaces,  Apache Commons e a maioria dos projetos Apache. Isto sem mencionar projetos gigantescos que também são mantidos sem a figura do financiador monstruoso, mas sim seus criadores e comunidades. Alguns exemplos? Vaadin, Prime Faces, Ruby on Rails, VRaptor, jQuery, jFreeChart, HighCharts, JUnit . Estes são apenas alguns exemplos, mas se você fizer uma consulta, constatará a mesma coisa: projetos open source evoluem sem um grande mantenedor desde que possuam qualidade.

Mas ninguém usa Grails né?

Bom, no Brasil, apenas no Grails Brasil, temos quase 2100 membros cadastrados hoje. A imagem a seguir é um slide que costumo apresentar em minhas palestras com algumas empresas com as quais tive contato direto ou indireto. Repare: eu tive contato. A realidade é bem mais abrangente.

grails_no_brasil

E fora do Brasil, quem usa isto? De novo, mais um slide com alguns grandes players que usam Grails em seu dia a dia e muitas vezes você sequer se dá conta:

grails_fora_do_brasil

E a lista é pequena. A abrangência é muito maior que isto. Hà alguns sites inclusive que você pode consultar para ver casos de sucesso, como esteeste e este.

Sobre o futuro do Grails? Em março sairá a versão 3.0 que será ordens de magnitude superior ao que temos hoje e ainda será compatível com as versões anteriores. Mais do que isto, estão surgindo cursos aqui no Brasil (um é meu) sobre o framework, assim como eventos a partir deste mês.

 

Mas quem usa Groovy?

Groovy é simplesmente a segunda ou terceira (o segundo lugar fica empatado com Scala) linguagem mais usada na JVM: só perde para o Java. Já sabíamos disto em 2010, mas o uso da linguagem vai bem além do uso direto. Basta lembrar a quantidade de projetos que usam Groovy como dependência direta ou indireta. Alguns com dependência direta: Jasper Reports, Spring,  OpenEJB, Tapestry e tantos outros. E indireta, basta buscar em seu repositório Maven.  É uma das linguagens mais difundidas da história graças ao fato de ser fácilmente embarcada.

Isto sem mencionar o que nos espera para o futuro como, por exemplo, desenvolvimento para Android, que será tão revolucionário (ou mais) que o próprio Grails. E há também todo um ecossistema que vale muito à pena ser mencionado aqui: frameworks fascinantes como RatPack, Griffon, Spock, GPars e tantos outros.

Isto sem mencionar o fato de que o mecanismo de build mais popular atualmente e que mais tem crescido é inteiramente baseado em Groovy. Talvez vocês já tenham ouvido falar dele, se chama Gradle e é o novo padrão usado para o desenvolvimento de aplicações Android.

Comunidade Groovy e Grails

Além disto, é interessante lembrar da comunidade Grails. Há diversos grupos de usuários Grails e Groovy pelo mundo além de um ecossistema de plugins que hoje é imenso. E já mencionei os eventos internacionais como Gr8Conf e Greach totalmente dedicados a Groovy e Grails? Isto sem contar a participação massiva em outros eventos como JavaOne ou Devoxx e tantos outros. São tecnologias extremamente reconhecidas, tanto é que o Geeks Choice Awards do ano passado foi para quem? Groovy.

Se duvida do que digo, convido você a participar das diversas mailing lists que existem hoje tanto para Groovy quanto para Grails. Isto sem mencionar a nacional que é o Grails Brasil. Aliás, já adianto: neste mês começo uma série de eventos pelo país voltados a estas tecnologias. Nâo sou idiota a ponto de apostar em algo que não acredito. Aliás, como já disse antes aqui neste blog (versão em inglês), o valor social de Grovy e Grails neste país é imenso.

É tudo uma questão de postura

Eu sei que é assustador você apostar em uma tecnologia e de repente ver o maior financiador pulando fora. Você se questiona se haverá futuro e coisas do gênero, mas quando observa o tamanho e atividade da comunidade e passa a ter uma visão mais profunda do modo como o mundo open source funciona, estes medos somem pois normalmente só se teme o desconhecido.

Minha sugestão é que todos nós vejamos esta saída da Pivotal como uma excelente oportunidade. Convenhamos, ela não era tão boa assim. Em todos estes anos de Pivotal escrevi para eles diversas vezes e nunca fui respondido. Além disto é interessante observar que também mataram os fórums de Spring, Groovy e Grails movendo-os para o StackOverflow.

Se você realmente gosta de Groovy e Grails que tal parar de simplesmente esperar e ficar plantando o medo por aí e passar a retribuir um pouco para a tecnologia que ajuda a pagar suas contas (tal como eu faço)? Se não souber como, aqui estão dois links ensinando a ajudar a equipe Groovy e Grails.

Eu sei que acreditar no fim do mundo é uma idéia tentadora e fácil de ser abraçada, mas também sei como funcionam projetos open source. Apenas para lembrar, falamos a mesma coisa quando a Oracle comprou a Sun, lembram?  Disseram que o Java estava morto, que não evoluiria, etc. Hoje vemos que estaría morto se continuasse na Sun: a linguagem prosperou, o ecossistema aumentou e todos ganhamos com isto.

E também me lembro de um tempo em que Grails mais prosperou e cresceu. Uma época antes da Pivotal e da Spring Source, quando era um projeto pequeno mantido apenas por seus criadores em uma empresa chamada G2One e que tinha uma comunidade muito mais ativa e próxima dos desenvolvedores originais.

Sem a Pivotal voltamos à época da G2One e, sinceramente, vejo isto como uma excelente oportunidade. Há duas posições: você pode prosperar ou ficar falando bobagem por aí. Opto pela primeira.

PS:

Mas se você realmente acha que é fundamental haver um financiador aqui está uma pequena lista de candidatos: Netflix, RedHat, Oracle, Apache (não financiaria, mas sim ofereceria infraestrutura), Atlassian, MercadoLivre e, quem sabe, você e eu.

Posicionamento do Guillaume Laforge sobre Pivotal

Posicionamento do Graeme Rocher sobre Pivotal.

 

Então você é o legado?

O que é legado?

Santo Agostinho, que de santo mesmo tinha muito pouco.

Dica: você sempre encontrará frases divertidas em Santo Agostinho

De uns tempos para cá tenho notado que cada vez mais pessoas falando sobre “software legado”. E sabem o que acho mais interessante? Elas caem em uma situação parecida com a que Santo Agostinho enfrentou ao falar sobre o tempo.

“Que é, pois o tempo? Se ninguém me pergunta, eu sei; se quero explicá-lo a quem me pede, não sei.” – Santo Agostinho

Troque a palavra “tempo” por “sistema/software legado” e faça uma auto crítica. Se eu te perguntar o que é software legado você vai saber me responder de forma clara e imediata? Já falei aqui como lido com legado, mas nunca apontei uma definição para este. Neste post faço isto,  mas antes vou mostrar algumas definições faláciosas.

“Todo software que você escreve depois de um tempo vira legado, assim como todo aquele que não foi escrito por você.”

Esta definição é um contra-senso e dá pra provar com lógica pura, quer ver? Se digo que um software é legado, a palavra “legado” denota uma categoria (ou conjunto) no qual alguns softwares se encaixem e outros não. Legado é adjetivo. Se é adjetivo, diferencia, se diferencia, deve haver algo que não seja legado.

Se tudo é legado, não há diferenciação, portanto não há legado. O software que você está escrevendo não é legado pois ainda não foi para produção e para o cliente sequer existe de fato, então cairia fora desta definição, mas aí entra aquela outra que também é furada.

“Se foi para a produção virou legado!”

Também não se aplica, a primeira versão do seu sistema, a qual você possui completo controle sobre o código fonte e arquitetura, que está brilhando de lindo pode ser chamado de legado? Sabemos que não. É apenas uma variação da primeira definição que mostrei.

“Legado é todo aquele software que precisa ser substituído por ser obsoleto ou não servir mais!”

Também não. Este software não é legado, mas sim inadequado ao contexto em que se encontra. Entra aí o conceito de obsoleto. Em que sentido obsoleto? Regras de negócio que não se aplicam mais? Uma plataforma de desenvolvimento que NINGUÉM no MULTIVERSO conheça?

A história do ambiente de desenvolvimento críptico também é furada. Ok, você pode ter dificuldade em encontrar mão de obra especializada, mas nada além do custo (que nem sempre é tão exorbitante assim quanto nos vendem) impede que você treine ou aprenda aquele ambiente também antes né? (sempre me soa a preguiça)

“Código legado é código sem testes.” – Michael C. Feathers

Sim, eu li o livro

Sim, eu li o livro

Desconfio que esta falação toda em cima de código legado é motivada pelo livro do Michael C. Feathers que o Robert Martin tem divulgado bastante atualmente. Neste livro há uma definição bem interessante: “código legado é código sem testes”.

Em uma primeira análise é uma boa definição: se o código não tem testes você não sabe explícitamente o que ele faz, logo não há controle sobre ele. Você não sabe se vai quebrá-lo quando for implementar uma nova funcionalidade ou mudança.

O problema desta definição é o escopo: apenas o programador (e talvez o arquiteto). Para o programador código legado é aquele que considera ruim o que, normalmente não passa de uma questão de ego (Fabio Akita tem um texto excelente sobre isto) e ignorância a respeito do contexto que gerou aquele sistema. É simplesmente não ter uma resposta honesta para a pergunta “o sistema deveria ser deste modo por que eu quero ou por que realmente é uma necessidade?”.

(Sobre o livro, bom: me decepcionou pois é mais um livro de refactoring do que sobre arquitetura na minha opinião. Um dia ainda escrevo um review sobre ele. Resumindo: micro demais e macro de menos, mas mesmo assim recomendo a leitura.)

wizardofoz1

Então você é o legado?

O que é um sistema legado?

Sistema legado é aquele cujo controle foi perdido por seus principais stakeholders. – Definição Lobo Weissmanniana

Software legado tem valor e prova disto está no fato de ser usado. Ignorar isto é menosprezar seu cliente e divulgar aos sete ventos sua própria arrogância e cegueira.

Software legado é aquele cujo controle sobre sua evolução foi perdido pelos principais interessados. E ei: o principal interessado não é o programador ou a equipe de desenvolvimento, mas quem o financiou e os usuários finais. Minha diferença em relação a Feathers é o foco: o dele é a equipe de desenvolvimento, o meu o usuário final.

Testes são importantes? Não, são vitais pois garantem a malha de segurança para a equipe de desenvolvimento e tudo o mais que todos nós, desenvolvedores, já estamos cançados de saber. No entanto para quem financia são na prática apenas um dialeto desconhecido. No que diz respeito à proximidade dos testes com o cliente final o mais próximo que iremos ter é o BDD mas, convenhamos, o usuário executivo não se interessa tanto assim por eles quanto se interessa pelo sistema final NO MUNDO REAL.

Quão “antiga” é a plataforma de desenvolvimento também não fazem um sistema legado. Prova disto é a imensidão de sistemas feitos em Ruby on Rails, Grails, Spring, .net e outros feitos às pressas como “MVP” que deixam seus patrocinadores desesperados com uma quantidade imensa de bugs a serem resolvidos e evoluções caríssimas. Em contrapartida, temos um verdadeiro universo de sistemas feitos em COBOL, FORTRAN, DELPHI e VB cujas instituições financeiras possuem completo controle sobre si e não podem ser considerados como legado. A diferença entre um e outro? Controle.

Quando evoluo um sistema legado o objetivo final é simples: devolver o controle a quem interessa. Mas como se perde este controle? De imediato as seguintes causas me vêem à mente:

  • Perda de contato com a equipe responsável pelo desenvolvimento do sistema.
  • Complexidade ingerenciada: você mantém a equipe mas esta perdeu o controle sobre a complexidade do sistema devido a problemas arquiteturais.
  • Perda do próprio conhecimento do sistema decorrente de ausência de documentação ou alta rotatividade dos stakeholders envolvidos na confecção original.
  • Aparente perda de controle: sinistro mas já vi acontecer. Ocorre quando alguém diz que o sistema é ruim apenas para justificar sua reescrita sem apresentar fatos concretos. (muito comum, especialmente quando você está buscando consultorias no mercado para evoluir seu legado)
  • Perda do código fonte.
  • Ou qualquer outra ausência do elo que ligava você à idéia original que gerou aquele sistema.

Entenda: simplesmente refatorar uma base de código não restaura o controle ao stakeholder pois ele nos paga essencialmente para não ter de se preocupar com isto. Para o investidor ter novas funcionalidades ou evoluções e adaptações implementadas em um prazo e custo aceitável, em um todo que seja compreensível, isto sim é ter controle sobre um sistema. ISTO é evoluir um legado, ou melhor, atualizar um sistema.

(Sabe aquele sistema que “não serve mais” ou é “obsoleto”? Quando é verdade, você tem controle sobre ele, pois sabe que não mais se aplica. Por isto não considero legado. Nestas situações há consciência de que deve haver um descarte. O máximo de descontrole que pode haver neste caso são pessoas que ainda o usam.)

Concluindo

É sempre a questão de uma boa definição. Claro que outras definições existem e podem até ser melhor que a minha, no entanto o que observo é que raríssimas vezes vejo a palavra chave fundamental, controle, ser aplicada. Se você domina um sistema, não há problema, você sabe como ele pode e deve evoluir. De resto, é o mito do legado como bem descrito no blog do Fabio Akita que citei acima.

PS: uma definição alternativa poderia ser “o que separa o desenvolvedor infantil do aduto”, mas achei que poderia soar um pouco agressiva.