Brownfield, Greenfield, Legacy, … O que é tudo isso?

Motivado pela minha participação no Void podcast, episódio #017 – Strawberry Brownfields Forever, (valeu pelo convite Elemar Jr. (@elemarjr), Leandro Daniel (@leandronet) e Vinícius Quaiato (@vquaiato)) resolvi começar a publicar uma série que eu estava preparando desde o ano passado, como uma continuação da palestra sobre o tema que fiz em duas cidades, São Paulo e Florianópolis, no TDC 2011, post sobre o evento, e aproveitando já foi liberada a data do evento esse ano, entre no site: The Developers Conference.

Brownfield

Apesar de trabalhar com Brownfield, não sabia que existia um nome para este “momento” ou situação no desenvolvimento. Me deparei com o termo ao encontrar o livro Brownfield Application Development in .NET, de Kyle Baley and Donald Belcham, publicado na Manning Publications Co.,o qual existe versão PDF, ePub e MOBI, veja aqui. O engraçado é que o título do livro dá a entender que o assunto será construir uma aplicação Brownfield! o_O Não poderia estar mais errado!

O termo é uma analogia a um terreno que está contaminado por lixo ou entulho, mas tem potencial, se for feita uma limpeza. No desenvolvimento de software o termo é a classificação de uma aplicação que sofreu a ação do tempo em suas linhas de código, ou seja,  uma aplicação que foi recebendo atualizações, modificações, até mesmo de objetivo; sem uma preocupação com a qualidade e como essas ações interferem  no código, deixando o processo de atualização ruim.

Mas não é só uma aplicação já em produção que se torna Brownfield. No início de um novo desenvolvimento, chamamos a aplicação de Greenfield, um campo novo no qual começamos a criar. Se não tomarmos cuidado,  essa aplicação já vai entrar em produção como Brownfield!

Do Green ao Brown

Quando não planejamos corretamente, não analisamos totalmente ou não temos toda a informação é que surgem as péssimas técnicas, metodologias, processos, que não precisam ser ensinadas, elas simplesmente acontecem na nossa cabeça. É mais difícil fazer algo bem feito do que algo mal feito. É simples, rápido, fácil, parecem ser características boas, mas são somente em um primeiro momento, ou a curto prazo! Porém,  quando se desenvolve um software ele não é uma solução de curto prazo ou uma ferramenta temporária, mas pelo contrário, vai durar e bastante. Todo mundo já ouviu alguém pedir uma solução momentânea, que ganha atualizações por que outra área achou interessante usar também, e que no fim vai ficando e ficando, e dali a algum tempo é core dos negócios da empresa. Uma simples parada para manutenção desse serviço poderá causar perda financeira para o negócio. Se um chef de cozinha, que está cozinhando uma refeição, que será consumida em seguida e em uma ou duas horas, mantém seu ambiente de trabalho limpo e organizado. Por quê é diferente quando se está codificando algo que vai existir por meses, anos, talvez décadas?

Exceções existem! Existem aplicações que tem um tempo de vida tão curto que invalida a necessidade de técnica, práticas, metodologias; e não estou falando de simples scripts para automatização de tarefas.  Na Forward Internet Group, uma empresa londrina, as aplicações nascem e morrem muito rapidamente! Como o foco são campanhas publicitárias que entram e saem rapidamente do ar,  para eles não existe a necessidade de fazer testes! Até mesmo por que a aplicação é tão pequena que os testes poderiam ter mais linhas de código do que a própria aplicação. Veja mais nessa apresentação da QCon 2011, em Londres.
Por isso não gosto tanto da definição do Michael Feathers de que código legado é código sem teste, pois invalida outros cenários ou situações.

A falta de planejamento constante, validando as funcionalidades a serem implementadas,  se realmente se encaixam no domínio do problema que o software se propõe a resolver; de refactoring; fazendo a limpeza do código que está sendo produzido; de controle da dívida técnica e até mesmo da organização da equipe de desenvolvimento, do turnover, levam uma aplicação do Greenfield ao Brownfield, às vezes de maneira assustadoramente rápida.

Ninguém gosta de trabalhar nesse tipo de código. Alterações tendem a gerar problemas inesperados, que fazem a equipe estender o horário de trabalho, a dificuldade de evolução faz você trabalhar nos fins de semana,  você não consegue mudar um framework de maneira simples,  não é preciso dizer que o custo aumenta exponencialmente com o passar do tempo. Uma verdadeira bola de neve, ou mais tecnicamente, um código macarrônico sem fim.

Lá e de volta outra vez…

Não é uma solução viável simplesmente reescrever o código, já que se estaria solucionando o sintoma somente e não o problema. Sair de um Brownfield não é fácil, é bem trabalhoso, mas trabalhoso por trabalhoso é melhor você se empenhar para resolver o problema do que continuar apenas queimando tempo em problemas recorrentes causados pelo desleixo com o código.

No episódio do podcast chegamos a conclusão de que alguns passos são inevitáveis:

  1. Convencer sua equipe: de que existem outras soluções, outras maneiras de trabalho; de que é possível entregar algo de qualidade com mais facilidade do que entregar com baixa qualidade
  2. Conseguir apoio para mudar: ou você resolve na calada da noite ou consegue que algumas horas gastas nas melhorias
  3. Refactoring, técnicas, metodologias: são necessárias ou você terá muito mais trabalho e não vai compensar e vai desistir
  4. Métricas: é preciso mostrar onde foi a melhoria, o que ela trouxe de benefícios

Próximos passos

Leia o livro indicado no começo do post e acompanhe o blog, vou publicar mais textos sobre o tema. Comentários são bem vindos. Até.

4 Replies to “Brownfield, Greenfield, Legacy, … O que é tudo isso?”

  1. Salve Brandão,

    O assunto é extenso e bem interessante. Imaginando um cenário onde você tem que converncer a área de negócios, as métricas tem que estar logo no passo 1. De cara voce pode levantar o numero de chamados e horas gastas em uma determinada aplicação para identifica-la como um brownfield, ou como seu brownfield mais problemático. A redução dessas medidas pode ser o primeiro indicativo que o seu trabalho está valendo a pena.

  2. E ai Brandão tudo certo?

    O void me trouxe até aqui e gostaria da sua opnião no que to tentando fazer.

    Hoje onde eu presto serviço em uma empresa que vende um produto, porém o desenvolve como projeto, isso acaba trazendo sempre os mesmo problemas, redundância e práticas ruins, como o “cópia e cola”.

    Cerca de 30% do sistema é customizado para cada cliente(geralmente as telas de CRUD), mas os cálculos que envolvem esse produto não são alterados, são geralmente replicados.

    A minha idéia é criar um “core”, onde ficaria essas coisas que não muda e a forma de comunicação dela com as outras partes seria parecido como uma API.

    Para parte da aplicação propriamente dita, estou pensando em criar aqueles templates do VS para cada segmento(já que cada qual tem algumas caracteristicas únicas). Estou estudando o principio Open/Closed para que a aplicação possam extender funcionalidades, sem sair quebrando o template original.

    O que você acha?

    Valeu!

    1. Armando,

      Legal a ideia do Core, acesso via API, etc… Acho que é por aí! Mas sem ver não dá para ser taxativo. Você tem que experimentar, faça PoC’s, etc…

      Se você tem muita customização veja sobre MEF, acho que te ajudaria em algumas coisas.

      No mais boa sorte com o trabalho e querendo trocar figurinhas é só escrever.

Leave a Reply

Your email address will not be published. Required fields are marked *