"El camino hacia el rendimiento está lleno de suciedad con bombas de código".
Consejos de programación para #programadores.
-----------------------------------------------------------------------
LIBRO: 97 COSAS QUE TODO PROGRAMADOR NECESITA SABER.
POR: KEVLIN HENNEY.
-----------------------------------------------------------------------
73° "EL CAMINO HACIA EL RENDIMIENTO ESTÁ LLENO DE SUCIEDAD CON BOMBAS DE CÓDIGO":
La mayoría de las veces, para ajustar el rendimiento de un sistema es necesario modificar el código. Cuando necesitamos alterar el código, cada fragmento que sea demasiado complejo o altamente acoplado, hay una bomba de código sucio al acecho para descarrilar el esfuerzo. La primera víctima del código sucio será su horario. Si el camino a seguir es sencillo, será fácil predecir cuándo terminarás. Encuentros inesperados con el código sucio hará que sea muy difícil hacer una predicción sensata.
Considere el caso en el que encuentre un punto crítico de ejecución. el curso normal de acción es reducir la fuerza del algoritmo subyacente. Digamos que respondes a la solicitud de presupuesto de tu gerente con una respuesta de 3 a 4 horas. A medida que aplica la solución, rápidamente se da cuenta de que ha roto una pieza dependiente.
Recomendado por LinkedIn
Dado que las cosas estrechamente relacionadas a menudo están necesariamente acopladas, esta ruptura es más probablemente esperada y contabilizada. Pero, ¿Qué pasa si arreglar esa dependencia resulta en que otras piezas dependientes se rompan?. Además, cuanto más lejos esté la dependencia es desde el origen, menos probable será que la reconozcas como tal y considéralo en tu estimación.
De repente, su estimación de 3 a 4 horas puede fácilmente aumentar a 3 a 4 semanas. A menudo, esta inflación inesperada en el cronograma ocurre uno o dos días a la vez. No es raro ver refactorizaciones "rápidas", finalmente tardará varios meses en completarse. En estos casos, el daño a la credibilidad y el capital político del equipo responsable variarán desde graves a la terminal. Si tan sólo tuviéramos una herramienta que nos ayudara a identificar y medir este riesgo... De hecho, tenemos muchas formas de medir, controlar el grado, la profundidad de acoplamiento y complejidad de nuestro código. Las métricas de software se pueden utilizar para contar la aparición de características específicas en nuestro código. Los valores de estos recuentos se correlacionan con la calidad del código. Dos de una serie de métricas que miden el acoplamiento son en abanico y en abanico. Considere la distribución en abanico de las clases: se define como el número de clases a las que se hace referencia directa o indirectamente desde una clase de interés. Tú puedes pensar en ésto como un recuento de todas las clases que deben compilarse antes de que tu clase se pueda compilar.
Fan-in, por otro lado, es un recuento de todas las clases que dependen de la clase de interés. Conociendo el fan-out y el fan-in, podemos calcular un factor de inestabilidad usando I = fo / (fi + fo). Cuando me acerco a 0, el paquete se vuelve más estable. A medida que me acerco a 1, el paquete se vuelve inestable. Los paquetes que son estables son objetivos de bajo riesgo para la recodificación, mientras que los paquetes inestables es más probable que estén llenos de bombas de códigos sucios. El objetivo de la refactorización es acercarme a 0. Al utilizar métricas, hay que recordar que son sólo reglas generales, basándonos puramente en matemáticas, podemos ver que aumentar fi sin cambiar fo hará acercarme I a 0. Sin embargo, un valor de abanico muy grande tiene una desventaja:
Éstas clases serán más difíciles de modificar sin separar a los dependientes. También, sin abordar la distribución. En realidad, no estás reduciendo tus riesgos, por lo que es necesario lograr un equilibrio.
Debe aplicarse una desventaja de las métricas de software, es la enorme variedad de números que producen las herramientas métricas que pueden resultar intimidante para los no iniciados. Dicho esto, el software y las métricas pueden ser una herramienta poderosa en nuestra lucha por un código limpio. Éstos, pueden ayudarnos a identificar y eliminar bombas de código sucio antes de que representen un riesgo grave para un ejercicio de ajuste del rendimiento.
-Udi Dahan-