Estou trabalhando em uma empresa com 11 pontos no Joel Test - pelo menos no papel.
Na prática, no entanto, nada funciona tão bem quanto o esperado, e o projeto está no DEFCON 1 há meio ano. Agora, a maioria dos meus colegas fica feliz se eles podem voltar para casa às 18h - no domingo.
Uma das práticas aparentemente boas que me pareceu não funcionar é o uso de ferramentas de análise estática. O projeto rastreia os avisos do gcc -Wall e uma ferramenta proprietária e muito cara "C / C ++" .
Os avisos do Gcc geralmente apontam para erros reais (se na maioria das vezes inofensivos).
As ferramentas proprietárias, no entanto, listam itens como projeções implícitas e tamanho de uma string literal. Elencos implícitos também estão na lista negra de seus livros de estilo.
A prática padrão é que as pessoas sejam pressionadas a calar todos os avisos. Observe que isso exclui avisos que são predominantemente falsos positivos, esse não é o problema.
O resultado é:
- As pessoas adicionam conversões de tipo a cada valor e a todos os argumentos, ocultando incompatibilidades de tipo problemáticas reais no processo.
- As pessoas se apresentam por um erro ou usam um recurso diferente de linguagem problemática (strlen em vez de sizeof, strncpy em vez de strcpy, etc.)
- Os avisos são silenciados.
- Os relatórios de erros começam a aparecer.
O ponto principal é que o código original estava funcionando e escrito por pessoas que estavam jogando com segurança dentro de suas habilidades de linguagem, enquanto as correções não estavam.
Agora, eu realmente não acho que essa empresa possa ser salva. No entanto, gostaria de saber se existe uma maneira melhor, de preferência funcionando, de usar as ferramentas "profissionais" ou se devo evitá-las por completo caso eu seja quem tome a decisão no futuro.
Uma solução que não assume que todos os programadores são gênios que não podem errar. Porque bem, se forem, não há necessidade de usar as ferramentas em primeiro lugar.