¿Cuándo es aceptable NO reparar ventanas rotas?

En referencia a las ventanas rotas , ¿hay momentos en que es mejor dejar la refactorización para una actividad futura?

Por ejemplo, si un proyecto para agregar algunas características nuevas a un sistema interno existente se asigna a un equipo que no ha trabajado con el sistema hasta ahora, y se le da una breve línea de tiempo para trabajar, ¿puede justificarse alguna vez? diferir las refactorizaciones importantes al código existente en aras de cumplir con la fecha límite en este escenario?

La refactorización es, y debería ser, un proceso continuo. No es suficiente simplemente cumplir los requisitos con una implementación funcional y probada que todavía está un poco incompleta.

"Haz que funcione, luego haz que funcione mejor" .

No recuerdo dónde leí esa cita, pero esta es la clave para aplicar bien la refactorización, y lo considero poco profesional para hacer lo contrario.

La refactorización continua es como limpiar los derrames mientras cocina y limpiar los platos después de haber comido. La refactorización dirigida es como encontrar una cocina sucia, pero solo tener tiempo para lavar uno o dos vasos sucios. ¿Prefieres vivir con una cocina continuamente sucia o prefieres mantener las cosas limpias a medida que avanzas?

Obtiene el código para trabajar, luego refactoriza su código para asegurarse de que tiene la mejor implementación que pueda usar. Si está haciendo algo familiar, puede ser que implemente el mejor código la primera vez, sin embargo, lleva un momento verificar dos veces su trabajo para estar seguro. Si parece que podría mejorar su código, entonces intente refactorizar para asegurarse de que su código sea al menos tan simple y limpio como pueda hacerlo. Esto significa que está reduciendo la cantidad de deuda técnica que deja atrás, y hace que sea más fácil de leer y refactorizar la próxima vez que deba tratar el código. Este es el valor central detrás del mantra TDD "Red-Green-Refactor", excepto que en TDD refactoriza principalmente para eliminar la duplicación, también vale la pena revisar otros elementos que podrían ser refactorizados, como clases grandes, métodos largos,

Si se enfrenta a un rediseño importante, entonces tal vez pueda posponerlo por un tiempo, especialmente si se está quedando sin tiempo en su agenda. Sin embargo, esto siempre que la funcionalidad de su código no se vea comprometida, y también siempre que la implementación continúe cumpliendo con los requisitos. Este tipo de situación debería ser algo raro, y puede ayudar a garantizar que sea aún más raro si está refactorizando continuamente a medida que avanza. Sin embargo, aún más importante es que no puede arriesgarse a dejar sus cambios importantes durante demasiado tiempo, de lo contrario terminará creando una carga de trabajo aún más grande que podría ser mucho más costosa de arreglar o podría resultar en un costo aún más costoso fracaso del proyecto

Tengo la impresión de que muchas personas tienden a confundir las definiciones de Refactorización y Reingeniería . Los dos términos describen estrategias para manejar situaciones muy diferentes. Si desea rediseñar, se compromete a realizar un cambio drástico que alterará el comportamiento de un sistema. Esto invalidará algunas pruebas y también requerirá nuevas pruebas. Cuando refactoriza, se asegura de que su sistema continúe comportándose exactamenteigual que antes del cambio, sin embargo, también se asegura de que su código tenga longevidad y que sea más fácil de mantener con el tiempo. No está "proxenetizando" su código por el mero hecho de hacerlo, se está comprometiendo con un estándar profesional de código limpio que reducirá el riesgo de falla y garantizará que su código siga siendo un placer trabajar con él y con un estándar profesional .

Volviendo a la analogía de las ventanas rotas, si rompe la ventana, debe repararla de inmediato. Si no se ha dado cuenta de que una ventana está rota, debe decidir el costo si deja la ventana rota. Ahora, repita las dos oraciones anteriores, pero sustituya Bug por ventana. Terminas necesitando una estrategia diferente. Si ha creado un error mientras codifica, lo arregla de inmediato, o ve si los cambios requerirán un esfuerzo de reingeniería, y toma una decisión comercial sobre cuándo será mejor solucionar el problema. Por lo tanto, no refactoriza para solucionar un problema, refactoriza para asegurarse de que sea más fácil encontrar y solucionar problemas. No me importa lo increíble que creas que es tu código, los sistemas complejos siempre tendrán problemas que deberán abordarse con el tiempo. De esto se trata la deuda técnica, y por qué la refactorización debe ser un proceso continuo a medida que implemente su código , y no dejarla para un tiempo futuro arbitrario.

En resumen, la respuesta de que en raras ocasiones puede ser aceptable diferir los cambios importantes en el código para establecer una fecha límite, sin embargo, no debe considerarse una práctica normal tratar la refactorización como un ejercicio independiente de su trabajo de implementación diario, y ciertamente nunca utilizado como una excusa por equipos que no están familiarizados con el código base como una opción para evitar asegurarse de que su implementación sea tan simple y limpia como puedan hacerlo bajo las circunstancias.

Algunos desarrolladores dicen que están "arreglando ventanas rotas" cuando realmente están "reorganizando las tumbonas en el Titanic". Refactorizar el código que funciona pero ofende su sentido del olfato es relativamente fácil. Si descubre que sigue volviendo a ese tipo de tarea en lugar de agregar nuevas capacidades para sus usuarios o hacer que la aplicación sea más útil para ellos (la optimización significa que hacer que la aplicación funcione más rápido es bueno aquí, la optimización significa que el código sea más legible es diferente) entonces quizás estás ordenando demasiado. No porque ordenar es malo, sino porque la compañía está pagando por el desarrollo para desarrollar algo. Sin duda, no quieren una solución frágil, difícil de leer y mal diseñada, pero tampoco quieren una media solución hermosa y pulida.

Ordene cuando necesite hacer algo simple "para ponerse en marcha", o cuando esté esperando que otro equipo le diga si su problema es realmente culpa suya, o cuando esté esperando una decisión. Habrá muchas oportunidades. Si tienes la oportunidad de mover toda la aplicación hacia adelante, tómala, a menos que comiences a sentir que todo se ha vuelto frágil. Probablemente no lo haya hecho. Tendrá la oportunidad de refactorizar, no necesita preocuparse por eso.

Para volver a la segunda mitad de su pregunta, un sprint para agregar características que se enfrentan a una línea de tiempo corta, sería un error decir "y no haremos ninguna refactorización, no hay tiempo". También sería un error decir "Sé que han pasado 6 semanas y parece exactamente igual para los usuarios, pero estas ventanas rotas realmente necesitan ser reparadas". Ajuste la refactorización en las brechas que suceden en cualquier proyecto. No se refugie en ordenar a costa de cumplir con el objetivo del proyecto.

Desde una perspectiva comercial, la refactorización es una inversión especulativa: invertir tiempo y esfuerzo (dinero) ahora, con la esperanza de que ahorrará más tiempo y esfuerzo (dinero) en algún momento en el futuro.

Sin entrar en el debate sobre cuánto ahorrará el esfuerzo para refactorizar en el futuro (esto depende de demasiadas variables para que sea una discusión significativa aquí), está claro que es el momento de refactorizar cuando el "valor presente neto" del costo que lo deja excede el costo de hacerlo ahora.

Eso es fácil, excepto que no tienes idea de cuánto costará el futuro. También debe tener en cuenta todas las ideas normales de planificación financiera, como el retorno de la inversión, la gestión del riesgo (valor de la marca, responsabilidad legal, riesgo asegurable frente a no asegurable), costo de la operación, etc.

En la mayoría de los casos, es mejor decidir cuándo refactorizar a las personas que dirigen el negocio. A pesar de lo que dicen muchos carteles en este foro, los gerentes generalmente saben más sobre la administración de un negocio que los programadores. Tienen una idea más amplia en mente que incluye maximizar la rentabilidad para el accionista. Es raro que arreglar cosas que no están rotas contribuya a esto, el código no es una excepción.

Editar: He leído un artículo interesante sobre programas de mantenimiento en infraestructura crítica. La esencia es que el movimiento está lejos de la rutina de mantenimiento (refactor) para reparar cuando sea necesario (corregir errores). La principal diferencia son los niveles de monitoreo: por ejemplo, una planta de energía nuclear monitorea con gran detalle y repara cuando está "rota" pero mucho antes de fallar. Lo que se ha encontrado es que la fijación a un esquema de mantenimiento no solo cuesta más, sino que es menos confiable debido a interrupciones causadas por el programa de mantenimiento. Se requiere una idea similar para el software: refactorizar los bits que están a punto de romperse, lo que solo se puede saber por medición.

Es aceptable cuando el daño al negocio al repararlos es mayor que al no repararlos.

Las situaciones en las que esto ocurre pueden ser:

• donde se puede perder una fecha límite u oportunidad de negocio debido al tiempo necesario para arreglar
• donde un código está (genuinamente) programado para ser retirado en una escala de tiempo muy corta, por lo tanto, casi no hay ningún beneficio en refactorizarlo.

Y estas situaciones sí ocurren: las situaciones comerciales a menudo idearán plazos artificiales que deben cumplirse cuando haya pasado la oportunidad de negociarlos, y requisitos que tienen un componente de tiempo, por ejemplo, un cambio en la legislación o las normas fiscales que entran en vigor una fecha específica: existen.

El truco está en identificar estas situaciones y evaluarlas adecuadamente. El código que está programado para ser retirado a menudo se mantendrá durante años. Es posible que se deban cumplir plazos artificiales, pero a menudo se pueden cumplir de diferentes maneras (por ejemplo, el software puede presentarse, demostrarse y "lanzarse" en una fecha determinada sin que la versión de lanzamiento final esté necesariamente terminada hasta más tarde).

Cuando se le presenta este tipo de cosas, debe abordarlo con una mente abierta, pero siempre pregunta si es lo que parece. ¿Son realistas los supuestos involucrados? ¿Hay otra forma de cumplir con el objetivo sin enviar un código deficiente? Si no existe, ¿cómo uso mejor el tiempo que tengo disponible?

Y si no hay alternativa siempre está bien, pero ¿cuándo lo arreglaremos?

Porque debería ser casi, casi, casi siempre cuando , no si .

Si los gerentes deciden que quieren acumular deuda técnica . Esta es una decisión justa si uno, por ejemplo, solo quiere un prototipo temprano para que algunos clientes iniciales reciban sus comentarios.

Puede pensarlo de la misma manera que pedir crédito. ¿Está bien pedir dinero prestado para invertir en X a corto plazo y pagarlo a largo plazo? No hay una respuesta definitiva, puede ser en el mejor interés de la organización (por ejemplo, para cumplir con las expectativas actuales del cliente), o puede ser un desastre si se hace de manera irresponsable.

Todo se reduce a las prioridades, y la administración debe ser consciente de que, aunque la prioridad número uno es hacer que el "código funcione", implementar nuevas funciones y cumplir con las expectativas del cliente, cada vez que abandona las ventanas rotas, la prioridad número uno es más lenta , más difícil y que requiere más inversión de recursos. Además, el 99% de las veces no es posible dejar de desarrollar nuevas funciones y concentrar todos los esfuerzos en "arreglar la base de código".

En conclusión, sí, es aceptable dejar ventanas rotas a veces, al igual que es aceptable pedir un préstamo ... solo recuerde que realmente tiene que pagarlo en el futuro. Y en el futuro, el tiempo para hacerlo probablemente no será mucho mayor que el tiempo que tiene ahora.

Normalmente, cuando pueda, debe solucionarlo. Esto evitará el tiempo potencial dedicado al mantenimiento. Sin embargo, algunas prácticas bárbaras no ágiles tienden a dejar el statu quo mientras esté funcionando. Algunos gerentes temen los "efectos imprevistos" del cambio.

Mi decisión es dejarlo solo si funciona como debería (solo se rompe por la optimización pero no por la funcionalidad) y no tiene tiempo para probarlo, si realiza alguna refactorización. Sin embargo, debe tener en cuenta que se debe solucionar más tarde lo antes posible.

Si está roto por la funcionalidad y sus nuevas características dependen de él, sería mejor arreglarlo lo antes posible también.

La mayoría de los programadores están en el negocio de ganar dinero para su empleador. Entonces, ¿cuándo debería suceder la refactorización ?: cuándo se gana dinero. La refactorización es el tiempo dedicado no gastado en otros proyectos y el tiempo ahorrado en el futuro en este proyecto.

Si vale la pena, depende principalmente de su gerente.

Los programadores deben informar a la parte comercial sobre el alcance de la deuda técnica, para que puedan tomar una decisión informada. Si la necesidad de llegar al mercado antes supera el riesgo de su código, no tiene muchas opciones. La falta de flujo de efectivo prevalecerá sobre muchas decisiones técnicas.

Para poner algunos de los problemas en una perspectiva no técnica, señale el tiempo extendido para corregir errores y agregar nuevas características. Si la gerencia tiene experiencia en ventas y mercadeo, pueden entender esto. Odian tener que decirles a los clientes que estas cosas llevarán más tiempo.

Si está pensando en expandir su equipo, este puede ser un buen momento para contratar a un desarrollador junior. La cobertura de prueba será un gran salvador en este caso. Aprenderán más haciendo que leyendo la documentación.

¿Puede ser justificable diferir las refactorizaciones importantes al código existente en aras de cumplir el plazo en este escenario?

• Si algo está roto, lo más probable es que no. No conducirás un automóvil con frenos parcialmente funcionando, ¿verdad? (A menos que el riesgo de no llegar a algún lugar a tiempo sea mayor que el riesgo de estrellarse debido a los frenos defectuosos). Lejos de ser la solución ideal, pero desafortunadamente sucede.

Sin embargo, si está hablando de volver a factorizar el código de trabajo, entonces consideraría lo siguiente:

• Si dependiera de nuestros desarrolladores sénior o director técnico, nunca lanzaríamos ningún software. Siempre re-factorizamos y luchamos por el perfeccionismo.

• Si la refactorización tendrá un impacto negativo en la rentabilidad del negocio, entonces debe reprogramarse.

• Si su empresa ha prometido entregar cierta funcionalidad en una fecha determinada, entonces la refactorizará más adelante. Piense en la organización benéfica del Día de la Nariz Roja: cada año pueden recolectar donaciones por un período de 24 o 48 horas. No hay forma de que vuelvan a factorizar su base de código si pensaran que podría evitar que reciban donaciones en ese lapso de tiempo. Además, si hay una ventana rota, pero no afectará su capacidad de recibir donaciones, es muy probable que elijan no re-factorizar.

• Siempre encontrarás una mejor manera de hacer algo. Es un proceso natural y es muy importante poder dibujar una línea.

En respuesta a su pregunta sobre la refactorización, diría "sí". Como alguien más señaló en las respuestas anteriores, la refactorización es un proceso continuo, y algunas veces hay decisiones tácticas y comerciales que reemplazan la necesidad de reescribir el código que ya está funcionando (aunque quizás de una manera deslucida).

Con respecto a "ventanas rotas": escuché este término por primera vez en el contexto del desarrollo de software, hace unos 10 años. Pero en ese momento, se usó para describir permitir pruebas unitarias rotas . Esto describía el escenario en el que las personas tienen la tentación de no reparar las pruebas unitarias rotas, porque parece más conveniente recordar qué pruebas están "bien para fallar", en lugar de arreglar las pruebas rotas (que se rompieron válidamente debido a la interfaz o los requisitos cambios, por ejemplo).

Creo que aplicar la metáfora de la ventana rota a las pruebas unitarias rotas es más apropiado y más descriptivo del peligro de permitir "ventanas rotas" en el vecindario del software. En mi opinión, si estaba hablando de pruebas unitarias rotas (como ventanas rotas), entonces la respuesta sería que nunca está bien. (En la medida en que podamos decir nunca ...)

Si realmente está roto, entonces debe ser reparado.

¿Pero está realmente roto? ¿Estás seguro de que no solo estás equiparando "no bonito" con roto.

Debe aplicar un cálculo de "valor hundido" antes de volver a factorizar el código de trabajo porque no le gusta el estilo o porque cree que causará problemas en el futuro.

Para re-factorizar el código que escribió la semana pasada, el costo hundido es el tiempo que pasó codificando la semana pasada, no vale la pena preocuparse si el código se mejora sustancialmente.

Refactorización de código que ha sido sometido a prueba unitaria. Ahora no solo necesita volver a escribir, debe redefinir y volver a ejecutar todas las pruebas realizadas hasta ahora, esto está empezando a parecer costoso.

Refactorización de código que se ha pasado a producción. Aún más pruebas por hacer, más un despliegue para los usuarios y el riesgo de entregar algo que no funciona tan bien como la versión anterior. Debe justificar esto y aclararlo con el gran jefe antes de seguir adelante.

Vuelva a factorizar el código que ha estado en producción durante un tiempo y ha pasado por varias versiones y correcciones de errores. A menos que sepa que el software dejará de funcionar, ¡ni siquiera vaya allí!

Según mi experiencia, la fecha límite es lo más importante para el negocio. Realmente depende de quién va a usar su aplicación. En mi caso, fue para el software del sistema operativo del teléfono móvil ... los plazos incumplidos significaron objetivos de ventas incumplidos y golpes en los precios de las acciones.

Nos encontramos con muchos momentos de WTF cuando miramos el código que heredamos y que claramente necesitábamos cambiar. Sin embargo, debido a que este código funcionó "casi" (la asincronía es poco conocida) no hubo ningún incentivo para que la administración realmente permitiera la refactorización, mientras que había compromisos pendientes por cumplir. No fue hasta que se vio un error 'en la naturaleza' que se nos permitió cambiar cualquier cosa, a pesar de que podríamos romperlo fácilmente a través de casos de borde oscuro. Una vez refacturé aproximadamente 10k líneas de código en mi propio tiempo y terminé teniendo que tirarlo a la basura. El tiempo necesario para las pruebas y otras personas que revisan, etc., no se pueden justificar.