#DevDay2012 nas Gerais

Tive o prazer de ter a submissão da minha palestra aprovada para o #DevDay2012! O pessoal da organização foi extremamente atencioso e nos receberam com uma agradável surpresa!

O evento

O evento aconteceu na UNA Campus Aimorés, mas primeiramente por um pequeno erro de interpretação no mapa de um certo colega palestrante fomos parar em outro campus…

É  uma iniciativa do Dev Island e eles se denominam uma comunidade de desenvolvimento plural, não pertencente a uma tecnologia ou linguagem. Tanto que foram feitas palestra de Java do Juan Lopes, de Python do Luciano Ramalho, … E várias outras distribuídas por 3 salas, durante o dia todo.

Encontrei além do Juan Lopes,  que é do RJ, o Elemar Jr. que é do RS; Essa é uma boa “desculpa” para ir nesses eventos, dá para reencontrar amigos distantes… Mas também outros que estão aqui do lado em SP, como o Victor Cavalcante, Rodrigo Yoshima e o Vinícius Quaiato, que foi comigo e espantou um cara da nossa fileira no avião antes mesmo da decolagem!

Continue lendo “#DevDay2012 nas Gerais”

#TDC2012

Tenho escrito pouquíssimo aqui no blog, falha minha! Não estou conseguindo me organizar para manter a constância. Tenho vários posts em rascunho que preciso publicar, tentarei encaixar essa tarefa nas lista de atividades semanais.

E falar sobre o TDC 2012 é algo que eu não posso deixar de fazer apesar de atrasado!

Continue lendo “#TDC2012”

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é.