edit

Como não matar um projeto um dia de cada vez

Publicado por Vinicius Manhães Teles há aproximadamente 1 ano.

A maioria dos projetos de software se comporta assim:

No gráfico, o eixo vertical representa a velocidade do desenvolvimento, enquanto o horizontal representa o tempo. Interpretando, notamos que a velocidade é alta no início do projeto e cai drasticamente algum tempo depois.

À medida que o tempo passa e mudanças vão chegando, os desenvolvedores começam a fazer alterações na aplicação, sem refatorar o código. Duplicações começam a surgir, métodos começam a crescer, classes passam a conter mais responsabilidades do que deveriam etc. Tudo vai "bem", até que a equipe começa a perder velocidade. Cada alteração no código se torna mais complicada e gera mais bugs. A velocidade, que começou alta, reduz-se rapidamente, até que a equipe não é mais capaz de alterar o software sem causar estragos significativos. Assim se criam os sistemas legados.

Essa é uma armadilha comum, que me faz lembrar uma passagem de Frederick Brooks no livro The Mythical Man-Month:

• Como um projeto atrasa dois anos?
• Um dia de cada vez!

A partir dessa questão, pode-se formular outra:

• Como o código de um aplicativo torna-se impossível de ser alterado?
• Um dia de cada vez!

O problema está nas pequenas decisões que nós, como desenvolvedores, tomamos várias vezes por dia. Toda vez que introduzimos uma gambiarra, estamos incorrendo em débito técnico. É como se pedíssemos dinheiro emprestado. Como em todo empréstimo, um dia a conta tem que ser paga e com juros. Em programação, os juros são altos. Cada pequena gambiarra leva o software em direção a um estado de caos.

Sabe o que acontece quando uma pessoa está sempre endividada? Ela começa a pedir dinheiro emprestado para pagar os juros de empréstimos anteriores. Ou seja, a coisa vira uma bola de neve. O mesmo acontece com o código. O efeito de várias gambiarras sucessivas não é linear, é exponencial. A complexidade que elas adicionam cresce mais rapidamente do que se possa esperar e, eventualmente, a equipe é pega de surpresa quando, "inesperadamente" não consegue mais avançar.

Existem algumas coisas que podem ser feitas para evitar essa armadilha. A primeira é começar o projeto mais lentamente, criando uma boa estrutura de código, especialmente com alta cobertura de testes automatizados. A segunda é aprimorar o design permanentemente, durante todo o projeto, através de freqüentes refatorações.

No produto em que estamos trabalhando, não queremos vivenciar a curva anterior. Ao invés dela, preferímos o gráfico a seguir:

A idéia é produzir pouco código no início do projeto e avançar gradativamente, à medida em que a equipe se integra, compreende melhor o que precisa ser feito, aprende a usar adequadamente as ferramentas e começa a criar uma estrutura que é suficiente para as fucionalidades que estão sendo criadas e mantém-se de forma sustentável ao longo do tempo.

Decidimos que nosso produto será escrito em Ruby on Rails. Por essa razão, investimos boa parte do nosso tempo, no mês de dezembro, implementando algumas funcionalidades prioritárias e experimentando algumas ferramentas, sobretudo ligadas à automação de testes. No ponto em que estamos agora, temos algumas das funcionalidades mais importantes implementadas e 100% de cobertura de testes em toda a aplicação.

Outro ponto importante é começar com uma equipe pequena. Nada é pior do que começar um projeto com uma equipe grande, já que em uma base de código pequena, inevitavelmente "um começa a pisar no pé do outro". No nosso caso, começamos com uma equipe de apenas três pessoas e a idéia é mantê-la nesse tamanho durante muito tempo.

Tags rails, refactoring | nenhum comentário