Entendiendo las métricas del código

Question

Recientemente instalé el complemento de métricas de Eclipse y exporté los datos para uno de nuestros proyectos.

Es muy bueno tener estos bonitos gráficos, pero realmente me gustaría entender más en profundidad lo que significan. Las definiciones de las métricas solo van tan lejos como para decirle lo que realmente significa.

¿Alguien sabe de buenos recursos, libros, sitios web, etc., que puedan ayudarme a entender mejor lo que significa la información y a comprender cómo mejorar el código cuando sea necesario?

Me interesan las cosas como Acoplamiento eferente, y Complejidad ciclomática, etc., en lugar de líneas de código o líneas por método.

Answer 1

No creo que las métricas de código (a veces denominadas métricas de software ) proporcionen datos valiosos en términos de dónde puede mejorar.

Con las métricas de código, es agradable ver cuánto código se escribe en una hora, etc., pero más allá de eso no le dicen nada sobre la calidad del código escrito, su documentación y la cobertura del código. Son casi un intento de una semana de medir donde realmente no se puede medir.

Las métricas de código también discriminan a los programadores que resuelven los problemas más difíciles porque obviamente lograron codificar menos. Sin embargo, resolvieron los problemas difíciles y un programador junior que saca un montón de crap code se ve bien.

Otro ejemplo para usar métricas es el muy popular Ohloh . Emplean métricas para poner una etiqueta de precio en un proyecto de código abierto (usando número de líneas, etc.), que en sí mismo es un intento que es defectuoso como un infierno , como puedes imaginar.

Habiendo dicho todo lo anterior, la entrada de Wikipedia proporciona una visión general sobre el tema, lamento no responder a tu pregunta de una manera más compasiva con un sitio web o libro realmente genial, pero apuesto a que tienes la idea de que no soy un gran ventilador. :)

Algo que debe emplearse para ayudarlo a mejorar sería la integración continua y el cumplimiento de algún tipo de estándar cuando se trata de código, documentación, etc. Así es como puedes mejorar. Las métricas son solo una golosina para las reuniones: "ya hemos codificado eso".

Actualizar

Ok, bueno, mi punto es que el acoplamiento eferente o incluso la complejidad ciclomática pueden indicar que algo está mal, aunque no tiene que estar equivocado. Puede ser un indicador para refactorizar una clase, pero no hay una regla general que indique cuándo.

En mi humilde opinión, una regla como más de 500 líneas de código, refactor o DRY principal Son más aplicables en la mayoría de los casos. A veces es tan simple como eso.

Le doy mucho de que, dado que la complejidad ciclomática se grafica en un diagrama de flujo, puede ser una revelación. Pero una vez más, usar con cuidado.

Answer 2

En mi opinión, las métricas son una excelente manera de encontrar puntos de dolor en su base de código. También son muy útiles para mostrar a su gerente por qué debería dedicar tiempo a mejorarlo.

Esta es una publicación que escribí al respecto: http: / /blog.jorgef.net/2011/12/metrics-in-brownfield-applications.html

Espero que ayude