Refatorando inovação

February 3rd, 2008 § 0 comments

Conversando com um amigo, ele estava me dizendo como está sem motivação para programar. Principalmente no que tange a aplicações Web, ele está cansado de repetir as mesmas soluções, montar as mesmas estruturas e continuar na vida de cadastros e relatórios. Ironicamente, ele se vê na posição de recriar frameworks mais avançados como Rails e Django a cada nova aplicação.

Ele me perguntou o que eu faço para coibir esse processo e eu lhe expliquei algumas regras que sigo. Depois pensei que isso daria um texto permanente e este é o resultado.

Leitores regulares sabem que a minha empresa deriva a maior parte de sua receita com aplicações .NET para empresas de médio e grande porte aqui em Belo Horizonte. Por mais que eu queira usar o que há de melhor e mais novo, isso simplesmente não é possível no atual mercado. As coisas estão mudando mas vai demorar um tempo até que as empresas aceitem que há vida além do .NET e Java.

Para não cair no marasmo e manter um ambiente produtivo, eu sigo algumas regras simples:

  1. Cada nova versão ou aplicação contém uma inovação em relação às versões ou aplicações anteriores
  2. A inovação geralmente representa a mudança que vai render mais mesmo que o esforço seja um pouco maior
  3. Antes de implementar eu leio sobre o que quero fazer, faço uma análise básica mas razoável e experimento um pouco mais a fundo
  4. Se mesmo assim, depois de implementar um pouco eu perceber que não vai funcionar, eu abandono a modificação imediatamente

Obviamente, qualquer desenvolvedor vai reconhecer na descrição acima a tradicional técnica de refatorar em progressão ascendente aqui. O resultado tem sido muito bom e também confirma o que eu penso sobre como lidar com manutenções de maneira mais coerente.

Para dar um exemplo concreto de como isso aconteceu, eu posso traçar o o que fiz quando comecei a programar em .NET, nos idos de 2004. Eu havia retornado a uma empresa em que trabalhara anteriormente e a primeira ordem que recebi foi: passe duas semanas aprendendo .NET porque você tem que começar uma nova aplicação depois disso. Na época, .NET era algo que a empresa ainda não dominava.

A minha seqüência de aprendizado foi a seguinte:

  • O primeiro protótipo foi básico, com o modelo tradicional de páginas separadas e componentes ligados diretamente a views e stored procedures.
  • Na implementação da primeira versão, as páginas separadas deram lugar a uma estrutura formalizada de componentes reaproveitáveis
  • No segundo ciclo de implementação, as views e stored procedures deram lugar a estrutura igualmente formalizada de acesso a banco de dados baseada em um ORM simples
  • No terceiro ciclo, as classes de dados passaram a utilizar uma DSL que simplificou enormemente a construção de queries
  • A segunda versão da aplicação viu o nascimento de uma estrutura MVC separando completamente as camadas da aplicação–lembrando que na época não havia nenhum dos frameworks .NET atuais
  • Na versão seguinte, um ORM completo unido a componentes dinâmicos gerou a aplicação final

Como é possível perceber, em nenhum momento houve um salto múltiplo. Cada atualização acima permitia substituir somente as partes sendo evoluídas de uma maneira gradual. Um trabalho assim é demorado, mas permite um aprendizado enorme. Do protótipo inicial à terceira e última versão, seis meses transcorreram.

Essa era uma aplicaçâo pequena com maiores possibilidades de experimentos rápidos mas a técnica escala para aplicações maiores guardadas as devidas proporções. E mesmo que hoje eu use um conjunto maior e melhor de técnicas e ferramentas, é sempre possível seguir adiante com mais inovação.

Uma pergunta que pode ser feita é porque a aplicação não foi reescrita em alguma ponto. Aqui eu concordo plenamente com Joel Spolsky que reescrever geralmente é são suicídio. É possível progredir sem ter que jogar tudo o que foi feito embora. E as outras aplicações vão se beneficiando do que vai acontecendo com a aplicação original–o converso também é verdadeiro.

No final das contas, manter uma aplicação dessa forma não é algo cansativo e representa uma oportunidade boa de crescer em incrementos gerenciáveis que não vão contra prazos e nem fogem à realidade.

Em última instância, eu não estou escrevendo nada de novo. Mas não custa nada explicar mais uma vez e ajudar que está enfrentando problemas similares. Como sempre, outras dicas são muito bem-vindas nos comentários.

Leave a Reply

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

What's this?

You are currently reading Refatorando inovação at Superfície Reflexiva.

meta