Métricas para medir la refactorización exitosa

Question

¿Existen indicadores objetivos para medir la refactorización de códigos?

¿Funcionar findbugs, CRAP o checkstyle antes y después de una refactorización sería una forma útil de verificar si el código fue realmente mejorado en lugar de simplemente modificado?

Estoy buscando tendencias que podamos capturar que nos pueden ayudar a mejorar el proceso de revisión de código sin perder tiempo en el código que se cambia por simples preferencias personales.

Answer 1

¿Funcionar findbugs, CRAP o checkstyle antes y después de una refactorización sería una forma útil de verificar si el código fue realmente mejorado en lugar de simplemente modificado?

En realidad, como he detallado en la pregunta "What is the fascination with code metrics?", la tendencia de las métricas (findbugs, MIERDA, lo que sea) es el verdadero valor añadido de las métricas.
Es (la evolución de las métricas) que permite a priorizar la acción principal de fijación que realmente necesita para hacer que su código (en contraposición a tratar ciegamente a respetar todas las métricas por ahí)

Una herramienta como Sonar puede, en este dominio (monitoreo de métricas) puede ser muy útil.

---

Sal añade en los comentarios:

El verdadero problema está en control de lo que el código cambia un valor añadido en lugar de limitarse a añadir el cambio

Por eso, la cobertura de la prueba es muy importante, porque solo las pruebas (pruebas unitarias, pero también "pruebas funcionales" más grandes) le darán una respuesta válida.
Pero la refacturación no debe hacerse sin un objetivo claro de todos modos. Hacerlo solo porque sería "más elegante" o incluso "más fácil de mantener" puede no ser en sí mismo una buena razón suficiente para cambiar el código.
Debería haber otras medidas como algunos errores que se repararán en el proceso, o algunas funciones nuevas que se implementarán mucho más rápido como resultado del código "refactorizado".
En resumen, el valor agregado de una refactorización no se mide únicamente con las métricas, sino que también se debe evaluar con respecto a objetivos y/o hitos.

Answer 2

Número de unittests fallidos debe ser menor o igual a cero :)

Answer 3

Dependiendo de sus objetivos específicos, como las métricas cyclomatic complexity pueden proporcionar un indicador de éxito. Al final, cada métrica puede subvertirse, ya que no pueden capturar inteligencia y/o sentido común.

Sin embargo, un proceso de revisión de código puede hacer maravillas.

Answer 4

Tamaño del código. Cualquier cosa que lo reduzca sin romper la funcionalidad es una mejora en mi libro (eliminar comentarios y acortar los identificadores no contaría, por supuesto)

Answer 5

No importa lo que haga, asegúrese de que esta medida no se use para evaluar el rendimiento del programador, decidiendo promoción o algo por el estilo.

Answer 6

Me mantendría alejado de las métricas para medir el éxito de refactorización (aparte de #unit failures de prueba == 0). En cambio, iría con revisiones de código.

No hace falta mucho trabajo para encontrar objetivos obvios para refactorizar: "¿No he visto ese mismo código antes?" Por lo demás, debes crear ciertas pautas sobre lo que no debes hacer, y asegurarte de que tus desarrolladores las conozcan. Luego, podrán encontrar lugares donde el otro desarrollador no siguió los estándares.

Para refactorizaciones de alto nivel, los desarrolladores y arquitectos más experimentados necesitarán ver el código en términos de dónde ven moverse la base de códigos. Por ejemplo, puede ser perfectamente razonable que el código tenga una estructura estática hoy; pero si saben o sospechan que se requerirá una estructura más dinámica, pueden sugerir utilizar un método de fábrica en lugar de usar nuevo, o extraer una interfaz de una clase porque saben que habrá otra implementación en la próxima versión.

Ninguna de estas cosas se beneficiaría de las métricas.

Answer 7

Hay dos resultados que desea refactorizar. Desea formar un equipo para mantener un ritmo sostenible y desea cero defectos en la producción.

La refabricación se lleva a cabo en el código y en la compilación de prueba de la unidad durante el desarrollo controlado por prueba (TDD). La refactorización puede ser pequeña y completa en una pieza de código necesaria para terminar una tarjeta de historia. O bien, la refacturación puede ser grande y se requiere una tarjeta de historia técnica para abordar la deuda técnica. La tarjeta de historia se puede colocar en la cartera de pedidos del producto y priorizar con el socio comercial.

Además, a medida que escribe pruebas unitarias como lo hace con TDD, continuará refactorizando la prueba a medida que se desarrolla el código.

Recuerde, de manera ágil, las prácticas de administración, tal como se definen en SCRUM, le brindarán colaboración y le asegurarán que comprende las necesidades del socio comercial y que el código que desarrolló cumple con las necesidades del negocio. Sin embargo, sin las prácticas de ingeniería adecuadas (según lo define Extreme Programming) su proyecto perderá un ritmo sostenible. Muchos proyectos ágiles que no empleaban prácticas de ingeniería necesitaban ser rescatados. Por otro lado, un equipo disciplinado y empleado tanto en la gestión como en la práctica ágil de ingeniería pudo sostener la entrega de forma indefinida.

Por lo tanto, si su código es liberado con muchos defectos o su equipo pierde velocidad, refactorización y otras prácticas de ingeniería (TDD, paring, pruebas automatizadas, diseño evolutivo simple, etc.), no se están empleando correctamente.

Answer 8

Sí, varias medidas de calidad de código pueden indicarle si una refactorización mejora la calidad de su código.

• Duplicación. En general, menos duplicación es mejor. Sin embargo, los buscadores de duplicaciones que he usado a veces identifican bloques duplicados que son estructuralmente similares pero que no tienen nada que ver semánticamente entre sí y, por lo tanto, no deben desduplicarse. Esté preparado para suprimir o ignorar esos falsos positivos.

• Cobertura del código. Este es de lejos mi métrica favorita en general, pero solo está relacionada indirectamente con la refactorización. Puede y debe aumentar la cobertura baja escribiendo más pruebas, pero eso no es refactorización. Sin embargo, debe supervisar la cobertura del código mientras refactoriza (como con cualquier otro cambio en el código) para asegurarse de que no se apague.La refactorización puede mejorar la cobertura del código eliminando copias no verificadas del código duplicado.

• Tamaño métricas tales como líneas de código, clase total y por, método, función, etc. A Jeff Atwood post enumera algunos más. Si una refactorización reduce las líneas de código mientras se mantiene la claridad, la calidad ha aumentado. Las clases, métodos, etc. inusualmente largos son probablemente buenos objetivos para la refactorización. Esté preparado para usar el juicio al decidir cuándo una clase, método, etc. realmente necesita ser más largo de lo normal para hacer su trabajo.

• Complexity metrics como cyclomatic complexity. Refactoring debe tratar de disminuir la complejidad y no aumentarla sin una razón bien pensada. Los métodos/funciones con alta complejidad son buenos objetivos de refactorización.

• de Robert C. Martin package-design métricas: Abstracción, la inestabilidad y Distancia de la secuencia principal abstracción-inestabilidad. Él los describió en his article on Stability in C++ Report y su libro Agile Software Development, Principles, Patterns, and Practices. JDepend es una herramienta que los mide. Refactorización que mejora el diseño del envase debe minimizar D.

he utilizado y seguirá utilizando todos ellos para controlar la calidad de mis proyectos de software.

Answer 9

Veo la pregunta desde el punto de vista del olfato. Los olores podrían tratarse como indicadores de problemas de calidad y, por lo tanto, el volumen de instancias de olores identificadas podría revelar la calidad del código del software.

Los humos se pueden clasificar en función de su granularidad y su posible impacto. Por ejemplo, podría haber olores de implementación, olores de diseño y olores arquitectónicos. Debe identificar olores en todos los niveles de granularidad antes y después para mostrar la ganancia de un ejercicio de refactorización. De hecho, la refactorización podría estar guiada por olores identificados.

Ejemplos:

• Implementación Olores: método largo,, Missing caso complejo condicionada por defecto, método complejo, larga declaración, y números mágicos.
• Olores de diseño: abstracción multifacética, abstracción perdida, encapsulación deficiente, encapsulación sin explotar, modularización tipo eje, modularización cíclicamente dependiente, jerarquía amplia y jerarquía rota. Puede encontrar más información sobre los olores de diseño en este book.
• Olores de arquitectura: Capa faltante, dependencia cíclica en paquetes, capa violada, interfaces ambiguas y funcionalidad dispersa parásita. Encuentre más información sobre olores de arquitectura here.