Coisas que você não deve fazer ao desenvolver software

Construindo um código

O título deste artigo é uma extensão de um artigo famoso escrito por Joel Spolsky. Aqui ele fala basicamente de alguns erros estratégicos que nós nunca deveremos cometer. Infelizmente os casos são recheados de exemplos e as empresas que os cometeram e sofreram sérios prejuízos dos quais servem de mau exemplo para que a comunidade não cometa os mesmos erros.

O grande exemplo dele está na construção de um software chamado Netscape. A Netscape era um browser famoso no mercado. O firefox é uma continuação sobre outros termos após perceberem o grande erro. A história do Netscape é bem simples: até a versão 4.0 eles foram remendando o código e, muitas coisas dentro do software, apresentava lentidão. O grande problema é que da versão 4.0 pulou para a 6.0. Porém passou-se alguns anos e a Netscape perdeu mercado com isso pelo simples motivo de que eles resolveram escrever a versão 6.0 do Zero.

Um dos argumentos dele é que nós somos programadores. E programadores não gostam de mexer no código dos outros (códigos macarrônicos detected!). Ler um código é mais difícil do que escrever. Essa é uma grande verdade e o motivo pelo qual reusar código é muito díficil.

A ideia de que um código novo é melhor que o antigo soa um pouco absurda. O código antigo está sendo usado. Já foi testado pelo cliente. Muitos bugs foram encontrados e resolvidos. Não existe nada errado com ele.

Mas... "o código antigo possui uma função com duas páginas!!" Bom, vamos a seguinte afirmação: o código funciona e possui bugs corrigidos! Um bug de resolução para um componente específico ou um código que funciona apenas em um determinado navegador. Quando você começa um código do zero você perde todo esse conhecimento.

Quando vc despreza isso, se o seu sistema for grande, você dá de presente ao seu concorrente um ou dois anos de vantagem. Isso é simplesmente uma eternidade em termos de software.

O que você pode fazer nesses casos? Ir tomando controle do código aos poucos. Escreva testes para determinadas funções chaves, vá documentando o código. Quando um mingau está quente você come pelas beiradas. A mesma abordagem para o código. O controle não nascerá da noite para o dia, ele é conquistado.

A refatoração de código é um processo lento, passo-a-passo, que deve ser executado com calma e paciência. Aos poucos é possível ir "tomando o controle".

Um outra razão pela qual os programadores não gostam de mexer em um código é por que ele é lento. Isso pode ser uma pequena parte do código ou partes isoladas. Essas partes, devidamente refatoradas ou reescritas otimizam melhor o projeto do que recomeçar.

Talvez o mais importante é que você não tem nenhuma razão para acreditar que irá fazer um trabalho melhor do que você fez no passado.

Até a próxima.

Blog Comments powered by Disqus.
Utilizando o Alexa para Abrir uma garagem Um novo recomeço