¿Es útil mirar fragmentos de código aleatorio para determinar rápidamente la calidad de un proyecto?

Para tener una idea de la calidad de un proyecto que nunca antes había visto (por lo general, proyectos de código abierto que estoy considerando usar o no), a menudo empiezo abriendo archivos aleatorios y mirando los detalles del código.

Busco cosas como:

• Estilo (sigue las convenciones aceptadas para el idioma y es coherente)
• Calidad y consistencia de los comentarios.
• Problemas comunes específicos del idioma (p. Ej., No siempre se usan ===en javascript)
• ¿Se ve lógicamente estructurado?

Creo que esto me da una buena idea de la habilidad de los desarrolladores que escribieron el código, incluso si no sé absolutamente nada acerca de lo que el código debe hacer.

¿La gente piensa que esto es útil? ¿Qué se debe tener en cuenta para evaluar rápidamente la calidad de la base de código de un proyecto, suponiendo que no se sepa cómo funciona realmente?

¿Qué tan fácil sería para mí corregir un error en este código?

Cada vez que encuentro una nueva base de código, me hago esa pregunta.

Familiarizarme rápidamente con el código me permite identificar puntos en común con los desarrolladores que lo crearon. Tiendo a buscar lo siguiente (sin ningún orden en particular):

• uso constante de convenciones de nomenclatura
• una aversión a hacer que el código sea complejo: adherirse al principio KISS
• pruebas unitarias que funcionan fuera de la caja
• Un breve archivo Léame que describe el proyecto con consejos útiles para comprender
• buenos comentarios
• uso de patrones de diseño cuando sea apropiado
• estilo consistente en comentarios y diseño de código
• uso de bibliotecas de soporte conocidas y respetadas (por ejemplo, Boost, Guava, etc.)
• presencia de idiomas idiomáticos

Cuanto más de lo anterior esté presente, más confianza tengo en las habilidades y experiencia de los desarrolladores para que cuando sea inevitable WTF? En este momento, estoy mucho más inclinado a mirar hacia mí mismo por la falta de comprensión del dominio del problema que asumir que el desarrollador original ha cometido un error.

Si elige solo una opción, es probable que lo esté haciendo mal. :) Aparte de eso, esto es esencialmente un muestreo aleatorio , un enfoque bastante respetable para recopilar información en casos como los que usted describe. Para obtener más detalles científicos sobre cómo se podría hacer esto, estudie sobre el método de Monte Carlo .

Con respecto a las cosas que debe buscar, considere encontrar, estudiar y adaptar a sus necesidades específicas alguna lista de verificación de revisión de código probada y verdadera .

Algunos otros aspectos que vale la pena considerar al evaluar un proyecto se enumeran a continuación ( lista de verificación resumida de mi experiencia anterior ):

• Publicaciones (junto con el registro de cambios), control de versiones y disciplina de publicación
  En general, es mucho más fácil investigar los problemas cuando se puede descubrir que se encontró un error en la versión 1.2.3, disponible para descargar hace mássome URL de dos años, alguien me envió un correo con el binario adjunto .

• Documentación del desarrollador, referencia de API y ejemplos de código
  Ayuda a evitar esfuerzos desperdiciados en reinventar la rueda y aprender lo básico por prueba y error.
  Tenga en cuenta que estos también se pueden muestrear al azar para un estudio rápido.

• Seguimiento de errores
  Si no hay ningún seguimiento, es una gran bandera roja; si hay uno, considere revisarlo rápidamente utilizando el mismo enfoque de muestreo aleatorio que para el código fuente

• Comentarios positivos
  Conozca a los usuarios del proyecto e intente hacer un estudio de muestreo aleatorio de sus comentarios.

Creo que este método revela más bien las habilidades de diseño y la capacidad de hacer que el código sea legible, pero no dice nada sobre las habilidades lógicas, analíticas y de resolución de problemas de los desarrolladores que trabajan en el código.

Entonces, cuando analiza el código de esta manera, obtiene información solo sobre cuán "bueno" se ve el código y si es legible o no. Pero aún no tiene idea si el código está optimizado, si funciona bien, si está bien estructurado, etc.

Las características a las que presta atención son muy importantes. Muestran si el código es legible y mantenible. Pero hay muchos programadores que brindan soluciones excelentes pero que realmente no prestan atención a los comentarios y al estilo (que creo que es mucho más fácil de aprender que la programación en sí).

Sí, creo que es una buena idea. Los proyectos que están mal escritos tienen más probabilidades de ser abandonados.

Pero no base su decisión solo en eso. El historial del código fuente de mi cuenta y el número de confirmadores son un factor mucho más importante.

Creo que mirar pequeñas secciones de código es una excelente manera: si está bien codificado, las variables / clases / métodos se nombran bien y se comentan bien, entonces comprender qué hace una pequeña sección y cuál es su propósito debería ser fácil. Si tiene grandes dificultades para comprender un bloque pequeño (como cualquier cosa entre paréntesis), entonces probablemente no esté tan bien codificado.

a menos que los ejemplos sean muchos y grandes, existe una gran posibilidad de que no obtenga una buena sección transversal de la base de código. Podría terminar con las pocas piezas buenas o las pocas manzanas malas con bastante facilidad.