A análise de trechos aleatórios de código é útil para determinar rapidamente a qualidade de um projeto?

Para ter uma idéia da qualidade de um projeto que eu nunca vi antes (geralmente projetos de código aberto que estou pensando em usar ou não), geralmente começo abrindo arquivos aleatórios e detalhando detalhadamente o código.

Eu procuro coisas como:

• Estilo (segue as convenções aceitas para o idioma e é consistente)
• Qualidade e consistência dos comentários
• Dicas específicas de linguagem comum (por exemplo, consistentemente não usando ===javascript)
• Será que olhar logicamente estruturada

Acho que isso me dá uma boa idéia da habilidade dos desenvolvedores que escreveram o código, mesmo que eu não saiba absolutamente nada sobre o que o código deve estar fazendo.

As pessoas pensam que isso é útil? O que é preciso levar em consideração para avaliar rapidamente a qualidade da base de código de um projeto, sem assumir o conhecimento de como ele realmente funciona?

Quão fácil seria para eu corrigir um bug neste código?

Sempre que encontro uma nova base de código, faço a mim mesma essa pergunta.

Familiarizar-me rapidamente com o código permite-me identificar pontos em comum com os desenvolvedores que o criaram. Costumo procurar o seguinte (em nenhuma ordem específica):

• uso consistente de convenções de nomenclatura
• uma aversão a tornar o código complexo - aderindo ao princípio do KISS
• testes de unidade que funcionam imediatamente
• um pequeno arquivo leia-me que descreve o projeto com dicas úteis para entender
• bons comentários
• uso de padrões de design, quando apropriado
• estilo consistente nos comentários e no layout do código
• uso de bibliotecas de suporte conhecidas e respeitadas (por exemplo, Boost, Guava etc.)
• presença de idiomas

Quanto mais dos itens acima estiverem presentes, mais confiança tenho nas habilidades e na experiência dos desenvolvedores para que, quando o inevitável WTF ?! momento que ocorre, estou muito mais inclinado a procurar por mim mesmo uma falta de compreensão do domínio do problema do que supor que o desenvolvedor original cometeu um erro.

Se você fizer apenas uma escolha, provavelmente estará fazendo algo errado. :) Fora isso, trata-se essencialmente de uma amostra aleatória , uma abordagem bastante respeitável para coletar informações em casos como você descreve. Para mais detalhes científicos sobre como isso pode ser feito, estude sobre o método de Monte Carlo .

Em relação às coisas a procurar, considere encontrar, estudar e adaptar às suas necessidades específicas uma lista de verificação de revisão de código testada e verdadeira .

Alguns outros aspectos que vale a pena considerar ao avaliar um projeto estão listados abaixo ( lista de verificação resumida em minha experiência passada ):

• Versões (junto com o changelog), controle de versão e disciplina de publicação
  Geralmente, é muito mais fácil investigar problemas quando se pode encontrarsome URL um bug na versão 1.2.3, disponível para download há mais de dois anos atrás, alguém me enviou um email com o binário conectado .

• Documentação para desenvolvedores, referência de API e exemplos de código
  Ajuda a evitar esforços desperdiçados em reinventar a roda e aprender o básico por tentativa e erro.
  Observe que eles também podem ser amostrados aleatoriamente para um estudo rápido.

• Rastreamento de bugs
  Se não há rastreamento, é uma enorme bandeira vermelha; se houver, considere verificar rapidamente usando a mesma abordagem de amostragem aleatória usada para o código-fonte

• Feedback positivo
  Conheça os usuários do projeto e tente fazer um estudo de amostragem aleatória de seus comentários.

Acho que esse método revela habilidades de estilo e a capacidade de tornar o código legível, mas não diz nada sobre as habilidades lógicas, analíticas e de resolução de problemas dos desenvolvedores que trabalham no código.

Portanto, quando você analisa o código dessa maneira, obtém informações apenas sobre o quão "bom" o código parece e se é legível ou não. Mas você ainda não tem idéia se o código está otimizado, se funciona bem, se está bem estruturado etc.

As características nas quais você presta atenção são muito importantes. Eles mostram se o código é legível e de manutenção. Mas existem muitos programadores que oferecem excelentes soluções, mas não prestam atenção aos comentários e estilos (o que eu acho muito mais fácil de aprender do que programar em si).

Sim, acho que é uma boa ideia. Projetos mal escritos têm mais probabilidade de serem abandonados.

Mas não baseie sua decisão apenas nisso. O histórico do código-fonte imho e o número de confirmadores são um fator muito mais importante.

Eu acho que olhar para pequenas seções de código é uma ótima maneira - se for bem codificado, as variáveis ​​/ classes / métodos serão bem nomeados e comentados, então será fácil entender o que uma pequena seção faz e qual é seu objetivo. Se você tiver grandes dificuldades para entender um pequeno bloco (como qualquer coisa entre parênteses), provavelmente ele não está muito bem codificado.

a menos que as amostras sejam muitas e grandes, há uma boa chance de você não obter uma boa seção transversal da base de código. Você pode acabar com as poucas peças boas ou as poucas maçãs podres com bastante facilidade.