Ruby on Rails já está aí há cerca de 5 anos, e durante todos esses anos diversas aplicações foram desenvolvidas. Várias dessas aplicações foram criadas enquanto os desenvolvedores estavam aprendendo Ruby e Ruby on Rails, e por consequência, não utilizaram as melhores práticas de desenvolvimento. Apesar disso, as aplicações continuam online.
Estas aplicações web crescem ao longo dos anos, e com o aumento do número de linhas de código elas ficaram com uma manutenção muito complicada, enquanto isso, provavelmente o desenvolvedor original também já foi trocado. Esta é a situação que diversos programadores se encontram e, provavelmente, não sabem qual é a melhor solução a tomar ou até por onde começar.
Um novo livro foi lançado para ajudar a resolver problemas como este, o nome dele é Rails Rescue Handbook, de Mike Gunderloy. O livro foi liberado como PDF e os compradores ficam recebendo atualizações para sempre. A InfoQ teve a oportunidade de entrevistar Mike para tentar entender melhor as ideias que estão por trás deste livro.
Quando perguntado para descrever o novo livro:
Rails Rescue Handbook é a minha visão sobre os passos que você deve seguir quando estiver de frente com uma aplicação em Rails que está uma bagunça e quer trazê-la para os padrões profissionais (ou apenas fazê-la funcionar de novo). O livro fornece um overview sobre vários pontos de dificuldades em aplicações Rails, e oferece conselhos em níveis estratégicos e táticos para sair do buraco e voltar a um desenvolvimento produtivo.
O público-alvo do livro são pessoas que não são iniciantes em Ruby on Rails. Mike explica quem deve achar este livro interessante:
Como citado acima, este livro é para os desenvolvedores rails que estejam em dificuldades com suas aplicações e precisam de ajuda. Em vários casos, ele será para o sucessor do desenvolvedor original de um projeto, que não conseguiu entregar o código como previsto. Mas, algumas vezes, pode ser que seja o desenvolvedor original. Não há nada que impeça você de tentar melhorar seu projeto, uma vez que detectou algum problema (ou até vários problemas).
Uma parte de tentar consertar os problemas é, inicialmente, conhecer os problemas, alguns óbvios, outros nem tanto. No tópico sobre identificando áreas de problemas:
Externamente, a indicação número 1 de que há algum problema numa aplicação rails, é que não foi entregue o que o cliente necessitava. Tipicamente, vejo isso se manifestar de duas maneiras. Ou o desenvolvedor realmente não consegue entregar as features num tempo razoável, ou a entrega de uma nova feature quebra outra área da aplicação. Evidentemente, que o último demonstra um dos problemas mais tradicionais: falta de cobertura adequada de testes. Quando você tem acesso ao código fonte, é comum encontrar outros pontos negativos: má performance em função da falta de consideração relativa a camada de banco de dados, controllers inacreditavelmente gordos, views cheias de sql e por aí vai.
Assim que essas áreas problemáticas são identificadas é necessário que haja uma abordagem estruturada para corrigí-las. Mike prescreve um método estruturado e aberto:
Primeiramente, deve-se entrar num acordo com o cliente sobre a ordem do que vai ser melhorado. O cliente deve entender que será um período de poucas, ou nenhuma nova característica, pelo menos enquanto as coisas estão sendo estabilizadas. Uma parte importantíssima do processo, é achar uma maneira de manter sempre o cliente informado – sempre você vai ter que lidar com um backlog incrivelmente frustrante em função de trabalho anterior que deveria ter sido entregue. Transparência é a chave aqui.
Depois que você tiver certeza que entrou num acordo e que vai ter todo suporte necessário, o próximo passo é explorar o código o máximo possível (assumindo que não foi você que escreveu). Olhe a versão do Rails, traga uma cópia do código para sua máquina (se puder), olhe os roteamentos, os models, os controllers e as views. Comece a mapear os pontos negativos. Normalmente, o cliente vai saber onde estão os problemas de performance e de funcionalidades, escute-o.
Quando tiver identificado os “hot spots” no código, comece a refatorar tornando-o melhor. Geralmente, isso envolve a criação de testes pela primeira vez. Você quer ter certeza que está deixando as coisas melhores e também que tem o processo de desenvolvimento sob controle.
Nós então conversamos sobre abordar projetos através de pegar “as frutas mais baixas” primeiro para alcançar ganhos fáceis:
Existem algumas dicas no livro que possibilitam um ganho fácil para o cliente (e também ajudar você a virar o desenvolvedor responsável). Por exemplo, tempo gasto entendendo o modelo de dados e olhando o schema sempre revelam lugares onde uma simples adição de índice já garante uma melhora de performance.
Existem diversas áreas que você deve ficar atento para ter ganhos relativamente fáceis. Mike sugere alguns pontos para se começar:
Além de prestar atenção na camada de banco de dados (que geralmente é negligenciada por desenvolvedores em seu primeiro ou segundo projeto rails), rodar uma ferramente como o Google Page Speed sempre vai lhe mostrar lugares para ganhos rápidos de performance (e performance é uma área que os clientes geralmente estão muito atentos). Em um site disponível publicamente, certificar-se de que você tem algum tipo de notificação de exceptions configurada para lhe dizer o que está “falhando de verdade” é um outro primeiro passo fácil que pode apontar as partes do código que precisam urgentemente de mais atenção.
Quando questionado sobre seu background na comunidade Rails e como ele ganhou esse senso de atenção em relação aos problemas mais comuns, Mike apontou os vários anos de experiência prestando consultoria e também de aprendizado através da prática:
Eu ajudei a recuperar uma dúzia de projetos nos últimos dois anos, mas eu levo muito a sério a confidencialidade do cliente e por isso não posso revelar seus nomes. Eu também tive a chance de fazer revisões de códigos em outros projetos em função do que venho fazendo com o Action Rails. Isso variou de simples sites com 10 ou menos modelos que perdiam muito da funcionalidade básica do Rails, como associação entre modelos (usavam código customizado para fazer isso) até grandes aplicações que possuíam funcionalidades substanciais, mas que estavam cheias de relatórios de bugs. Eu tenho passado muito do meu tempo com Rails alocado em projetos de clientes ou subcontratos, ao invés de trabalhar com produtos ou plugins, o que me deu chances de ver como os projetos podem falhar.
Mais informações sobre o livro Rails Rescue Handbook podem ser encontradas no site do livro.
Mike Gunderloy tem vinte anos de experiência em diversas linguagens e plataformas. Ele vem trabalhando com Rails em full time desde 2006, e tem vasta experiência em trabalhar com times ágeis distribuídos passando por todos os níveis, desde gerente até desenvolvedor. Ele contribui enviando patches para o core do Rails e também é membro do time de documentação do Rails. Além do seu trabalho como consultor através da Lark Group, ele também é sócio da high-end Rails consultancy Action Rails e um dos fundadores do RailsBridge.