O artigo do Gamasutra Truques sujos de codificação é uma leitura fantástica. Uma parte dele, em particular, me tocou.
Considere a dor que senti ao trabalhar em uma conversão de um jogo de tiro em terceira pessoa 3D do PC para o PlayStation original.
Agora, o PS1 não tem suporte para números de ponto flutuante, portanto, estávamos fazendo a conversão basicamente recompilando o código do PC e sobrecarregando todos os números flutuantes com ponto fixo. Na verdade, isso funcionou muito bem, mas o problema foi na detecção de colisões.
A geometria do nível que nos foi fornecida funcionou razoavelmente bem na versão do jogo para PC, mas, quando convertida em ponto fixo, todos os tipos de emendas, junções em T e outros problemas surgiram devido às diferenças microscópicas nos valores entre fixos e flutuantes. Esse problema se manifestava quando o personagem principal (chamado “Damp”) simplesmente caía por esses pequenos buracos, no abismo abaixo do nível.
Remendamos os buracos que encontramos, ajustando a geometria até que o Damp não caísse mais. Mas então o jogo entrou em teste na editora e, de repente, recebemos uma enxurrada de bugs do tipo “cair do mundo”. Todos os dias, um novo lote de locais era encontrado com esses pequenos buracos pelos quais Damp podia passar. Nós corrigíamos essa parte da geometria e, no dia seguinte, eles nos enviavam mais dez. Isso continuou por vários dias. O departamento de testes da editora empregava um funcionário cujo único trabalho era saltar ao redor do mundo durante dez horas por dia, procurando lugares pelos quais ele pudesse cair.
O problema aqui era que a geometria era ruim. Não era uma geometria justa e contínua. Funcionava no PC, mas não no PS1, onde a matemática de ponto fixo ampliava enormemente os problemas. A solução ideal era corrigir a geometria para torná-la perfeita.
No entanto, essa era uma tarefa enorme, impossível de ser realizada no tempo disponível com nossos recursos limitados, portanto, contávamos com o departamento de testes para encontrar as áreas problemáticas para nós.
Nunca há tempo para fazer direito, mas sempre há tempo para fazer de novo. Se isso lhe parece familiar, o senhor não está sozinho. Às vezes, eu me pego caindo nesse padrão, corrigindo continuamente o mesmo código várias vezes. É o tipo de código que, quando enviado para revisão, o senhor se sente tentado a apresentar de forma autodepreciativa como o senhor já conheceu meu cachorro, patches?
Embora a “correção” nem sempre seja uma coisa ruim – o venerável Apache HTTP Server é uma prova disso -, é provavelmente uma exceção.
O FAQ original no site do projeto Apache Server, de 1996 a 2001, afirmava que “O resultado após a combinação de [the NCSA httpd patches] foi um servidor irregular”.
A leitura do artigo do Gamasutra me obrigou a atacar uma seção do código extra-patchy do Stack Overflow. Código que eu tinha que ajustar constantemente de várias maneiras para que funcionasse corretamente. Mas, primeiro, tive que superar meu medo. Medo. Foi isso que levou a todos os patches em primeiro lugar. Era óbvio que isso era código funcional que havia se tornado complicado com o tempo, mas ele estava funcionando. E essa é uma das principais partes da funcionalidade do site. Nessas circunstâncias, é fácil justificar mentalmente “apenas essa pequena alteração, apenas dessa vez” em vez da reescrita fundamental de que o senhor realmente precisa.
Quando o senhor finalmente perceber que passou os últimos seis meses dizendo a si mesmo a mesma mentira “só essa pequena mudança, só essa vez”, então o senhor também conheceu os adesivos do seu cachorro.
Agora, o que o senhor vai fazer em relação a esse patife?