Todo programador deve aproveitar oportunidades de implementar algo que agrege valor para o projeto e/ou refatorar código legado para otimizar a manutenção do sistema.
Infelizmente em alguns ambientes, principalmente onde não há testes … o código funcionando por pior que esteja deve ficar como está, não se modifica uma virgula, ou ajax é considerado ‘firula’ do qual se evita utilizar … creio que para programadores ignorarem técnicas da nossa profissão como ajax, melhoria continua e refatoração, é um sinal que algo está faltando.
Esse foi a minha constatação ao participar de dois projetos PHP , onde percebi a diferença entre desenvolvedores e empresas(que utilizam PHP comparado ao Ruby), principalmente sobre teste unitário, ao convesar a respeito do assunto, ouvi respostas como: “aqui não rola teste unitário”, ou, “o que é teste unitário?”, e ainda, “não vimos utilidade no teste unitários, na verdade, achamos que iriam mais nos atrapalhar”.
Então procurei anotar algumas situações nestes projetos onde os testes trariam benefícios, que seguem abaixo:
- Em uma tarefa para uma correção de bug e criei alguns teste unitários, e mostrei para o responsável por aprovar as alterações, foi onde ouvi “Teste unitário aqui não rola!”, então ele pediu para excluir os testes do branch e subir apenas a correção. Alguns dias depois, quando surgiu um outro bug, no mesmo método, ele me pediu para testar bem as modificações antes de colocarmos em produção, se fazer isso manualmente para alguém que conhece todo o sistema não é eficiente, imagina para alguém novo no projeto.
- “Métodos pequenos não são necessário, aqui adicionamos novos requisitos e comentamos”. Havia métodos com mais de cem linhas e quando é necessário uma nova funcionalidade no sistema a regra é adicionar direto nos métodos existentes.. mas quando ocorreu um bug no meio de um destes métodos, com vários ‘ifs’ aninhados, que ninguém conseguiu identificar a causa do bug, o bug foi consertado, extraindo um trecho do algoritmo, mas a real motivo do erro não foi detectado.
- Em outra situação, ao desenvolver um script para buscar o geocode no gmap, estava sendo excedido o limite de consultas na API, travando o desenvolvimento da solução, e os teste (manuais) do script, obrigando a deixar essa tarefa para o dia seguinte. Nessa situação, mocks e stubs poderiam ser a solução para não interromper o desenvolvimento.
- Implementaram um padrão para codificação de código (do qual foi recentemente definido na empresa), como tabs, nome de funções, e espaços agora devem seguir o padrão, mas há muito código feito antes de se definir o padrão do qual esbarramos quando vamos corrigir um bug, que a regra é modificar apenas o código que a tarefa pede, ou seja, não faça refatoração, se você ver algo errado, deixe do jeito que está, tudo isso por medo de derrubar um sistema do qual a única maneira de verificar se algo deu errado é através dos logs de erros do sistema !! Claro que a empresa tem prejuízo se algum desenvolvedor fizer algo errado, mas um projeto que não é melhorado constantemente torna-se difícil de gerenciar e diminui a produtividade do time, talvez irá dar ainda mais prejuízo .
Minha conclusão ao retornar ao PHP depois de ruby, existem diferenças de linguagem e plataforma, mas a maior diferença é a cultura da comunidade de desenvolvedores, infelizmente a maioria dos programadores PHP não estão preocupados com boas práticas.
Estes dias eu e o 
Marco Moura 