¿Cómo se explica la refactorización a una persona no técnica?

¿Cómo explicas la refactorización (y la deuda técnica) a una persona no técnica (generalmente un PHB o un cliente)? ("¡¿Qué, me va a costar un mes de tu trabajo sin diferencia visible ?!")

ACTUALIZACIÓN Gracias por todas las respuestas hasta el momento, creo que esta lista proporcionará varias analogías útiles a las que podemos señalar a las personas apropiadas (¡aunque editar las referencias a PHB puede ser prudente!)

Cuando tienes un gran cine en casa y agregas cosas, lenta pero seguramente se forma un gran nido de ratas en la parte posterior.

Si a menudo reemplaza partes, a veces vale la pena enderezar todo eso.

Claro, si haces eso, estaba funcionando antes, y no funcionará mejor que cuando empezaste, pero cuando tengas que meterte de nuevo con eso, las cosas serán mucho más fáciles.

En cualquier caso, probablemente sea mejor hacer una comparación similar con algún área temática con la que el PHB o el cliente ya esté familiarizado, es decir, automóvil o construcción o algo ...

Re-factorizar es como el proceso de volver a empacar una maleta hasta que todo encaje perfectamente. A veces, en el proceso, te preguntas por qué estabas tratando de conseguir tanta basura allí para empezar.

No explicaría el concepto de deuda técnica, porque no es necesario. En cambio, enfóquese en la refactorización: está cambiando el diseño de su programa, no necesariamente para que sea "mejor" o "mejorado", lo está cambiando para que pueda aceptar un cambio que necesita hacer.

Una analogía de automóvil podría encajar: debe agregar un aire acondicionado a un automóvil, pero no fue diseñado originalmente para uno. No solo tiene que hacer un aire acondicionado extraño en forma de L, sino que también debe quitar algunas otras cosas primero y cambiar el sistema de ventilación.

También creo que es una mejor estrategia refactorizar cuando está incorporando nuevas funciones: de lo contrario, podría estar cambiando el diseño en algo que solo se vea "mejor", pero que en realidad no sea adecuado para las circunstancias que rodean la adición de su próxima función.

Utilizo el término Deuda técnica y lo relaciono directamente con algo que entienden: deuda corporativa. La deuda técnica es como pedir un préstamo. Usted paga intereses por ello. Por ejemplo, puede construir una nueva fábrica y pagarla directamente o puede obtener un préstamo. Si obtiene un préstamo, en realidad pagará más a largo plazo, pero tiene sentido financiero si los términos son correctos .

Sin embargo, si paga un interés del 25% sobre dicho préstamo, se coloca en una posición no sostenible. Esto es lo mismo con la deuda técnica. A veces tiene sentido asumir alguna deuda técnica. Sin embargo, llega un punto en el que el interés es demasiado alto y debe pagarse. Algunas deudas técnicas son como un préstamo hipotecario y otras como deudas de tarjetas de crédito. En emergencias, la deuda de la tarjeta de crédito es un activo importante y valioso. Sin embargo, también puede romper el banco (o el hogar si lo desea) si se usa imprudentemente.

Otro ejemplo: puede pagar $ 10,000 por una caída de correo de marketing para obtener más clientes potenciales para las ventas en el futuro. Estás pagando la "deuda de ventas". Este es un gasto con pago a largo plazo. Compare esto con el motivo por el que desea "gastar" dinero ahora refactorizando un fragmento de código. En ambos casos no hay una recompensa inmediata, pero se está preparando para un mejor rendimiento en el futuro.

Tiendo a usar el término "deuda xxxx" como analogía cuando hablo con quien sea el público objetivo. Por ejemplo, deuda operativa: la imprenta que tenemos ahora funciona bien, pero al detener la producción por un día (o una semana) y actualizar a una nueva máquina, podemos aumentar la producción en un 25%.

EDITAR - Aquí hay otra versión de esto

Limpieza de primavera.

No estás haciendo ninguna modificación a la casa. Solo estás cambiando cosas y deshaciéndote del polvo. Tal vez tirar algunas cosas que ya no usa o necesita. pero no estás agregando nada

"¿Alguna vez has jugado Mouse Trap ? A medida que incorporamos nuevas funciones, cambiamos interfaces y corregimos errores, el código puede comenzar a parecerse mucho a eso. Llega un punto en el que tenemos que gastar mucho capital (tiempo y esfuerzo) , lo que equivale a dinero) asegurándonos de que todas las partes móviles funcionen bien con cada nuevo cambio o adición, o en su lugar podemos reservar tiempo para refactorizar el diseño, lo que resulta en menos partes móviles que tenemos que manejar cada vez que hacemos un cambio. puede parecer , desde la perspectiva del usuario final, que el refactor no tiene ningún beneficio, pero el beneficio ocurre cada vez que se agrega una nueva característica después del refactor. El proceso es más rápido, introduce menos errores y, a partir de entonces, es menos costoso, sin mencionar que el código refactorizado a menudo es más eficiente en general.

Quizás se pregunte por qué dejamos que parezca Mouse Trap en primer lugar:

• A veces, hacer algo ahora significa que tenemos que sacrificar la elegancia y la eficiencia para simplemente "hacer que funcione".
• Las características del lenguaje y otras tecnologías disponibles para nosotros como programadores a menudo cambian. A veces, las nuevas características nos permiten reemplazar un revoltijo de seis partes móviles con uno.
• A menudo, cuando agregamos la función C a las funciones A y B, no sabemos que B finalmente se eliminará y se agregará D. Una forma de lograr C puede funcionar muy bien con B, pero no muy bien con D.

En un esfuerzo por seguir construyendo una mejor trampa para ratones, tenemos que volver constantemente y encontrar lugares para reducir la complejidad y racionalizar lo que tenemos. Es la diferencia entre tener un software con muchas características y tener un software de realmente alta calidad ".

Esta es una versión un poco más gráfica de la analogía del cine en casa.

Si desea agregar un nuevo electrodoméstico más [también conocido como, nueva funcionalidad], en un apuro, probablemente pueda encajarlo en algún lugar.

Si desea agregar otro dispositivo más, puede comprar un cable de extensión, que le dará algo de tiempo.

Pero en cada adición, se hace más difícil encontrar una solución. Y te estás exponiendo a un riesgo ¹ de incendio [también conocido como errores], y tendrás que sacar grandes cantidades de dinero para pagarle a alguien para que coloque nuevos enchufes en la pared, lo que posiblemente podría escalar todo el camino hasta la tubería principal. placa de circuito, o incluso más.

¹ Otra cosa que los PHB no asimilan muy bien: "Bueno, si solo pudiera suceder, ¿de qué se preocupa?"

Refactorización: es como organizar su armario de ropa / cajón de herramientas.

• No tire su ropa / herramientas solo porque están por todas partes.

• Se podría argumentar que nunca deberían desorganizarse. Pero ellos lo hacen.

Justo como lo hace el código. Especialmente a medida que crece con el tiempo.

Y si no lo limpia, se preguntará qué pasó con esa camiseta que le encantó o con esa llave inglesa que siempre necesita pero que nunca puede encontrar.

Yo diría "mantenimiento de código" . Es importante usar palabras con las que la persona no técnica esté familiarizada y que tengan sentido para una visión del mundo no técnica. Si una persona no técnica (cliente) está familiarizada con el mantenimiento de la aplicación, entonces es fácil establecer paralelos entre el mantenimiento del código y el mantenimiento de la aplicación. Incluso si no son lo mismo, puede explicar que los clientes finales aquí son desarrolladores o aquellos que mantienen el sistema.

Digamos que usted es un mecánico especializado en la personalización de automóviles, incluso construyéndolos desde cero si el cliente lo requiere. Hay un cliente que vuelve a su tienda de vez en cuando para poner siempre algo nuevo y brillante en su limusina de gran tamaño.

Una vez que entra para tener un buen sistema de sonido instalado. Realiza diligentemente la tarea pasando cables y conectándolo todo correctamente. Sale un día después, está contento y paga generosamente, como siempre.

Al mes siguiente regresa, pero esta vez quiere instalar un cine en casa completo. Una vez más, tomas la limusina. Como profesional, vuelves a visitar el sistema de sonido y facilitas el mantenimiento instalando un sistema de tubos para pasar los cables alrededor del automóvil. De esta forma, los cables están protegidos y son más fáciles de extraer, y si necesita agregar más, también será fácil de hacer. Así que arrancas los cables viejos, instalas el tubo y pasas el sistema de sonido y los cables adicionales para el cine, lo cierras todo y listo.

Al darse cuenta de que el cliente no le pidió que reemplazara el viejo sistema de sonido, se quita parte del costo de los reemplazos y de los tubos. Sin embargo, todavía ganas dinero con el trato, pero no tanto como lo hubieras hecho si hubieras unido el sistema como lo hiciste la primera vez.

Un mes más tarde regresa, esta vez quiere un sistema de iluminación y quiere nuevos altavoces que hayan dañado los antiguos a principios de semana.

Debido a que mantuvo todo bien y ordenado, puede pasar rápidamente los nuevos cables de iluminación a través de su tubo, instalar el sistema y reemplazar el altavoz. Esta vez, sin embargo, ha terminado mucho más rápido, la refactorización valió la pena al mantenerlo en la cima de su juego.

Su competidor que se estaba riendo de usted por arrancar cables perfectamente buenos e instalar todos estos tubos adicionales todavía está luchando para que su cliente esté satisfecho. Claro que lo hizo más rápido que usted la mayoría de las veces, pero a medida que pasa el tiempo, sus clientes se quejan de que cada vez hay más demoras y que la calidad general del trabajo es degradante.

Al observar esto, se da cuenta de que su objetivo no solo es permanecer en el negocio, sino ser el arma principal, es equilibrar lo que hace para satisfacer las demandas del cliente y lo que hace para facilitar su vida en el futuro. Muy rara vez un cliente pagará por ambos, por lo que debe administrar de cerca. Usted apuesta que haciendo las cosas de manera proactiva, incluso a costa de hacer las cosas dos veces, mantendrá los costos de mantenimiento en un porcentaje estable y controlado de su productividad.

El software es el mismo, excepto que los programadores pueden jugar con cinta adhesiva digital durante MUCHO tiempo antes de que los clientes y gerentes sientan realmente los efectos. Desafortunadamente para ese momento, el costo de volver a hacer las cosas bien crece exponencialmente con respecto a la cantidad de cinta adhesiva presente y la edad promedio de dicha cinta adhesiva.

Por eso es importante que sigamos refactorizando el sistema. Muy a menudo la experiencia nos mostrará una nueva forma más eficiente de hacer lo mismo o podemos combinar una funcionalidad similar y explotar redundancias en lugar de simplemente copiarlas. Así es como mantenemos el sistema delgado y malo. El tiempo mostrará que re-factorizar constantemente el sistema para satisfacer las demandas mantendrá la productividad constante al controlar la cantidad colocada en mantenimiento.

Colocar cinta adhesiva aumentará momentáneamente la productividad a costa de llevar un sistema subóptimo. La deuda técnica se incurre cuando se favorece la productividad inmediata en detrimento de los otros aspectos de un sistema. La analogía de la deuda es buena porque al igual que los intereses sobre el capital prestado consumen las ganancias, el tiempo prestado para hacer las cosas rápidamente conlleva un mayor mantenimiento y aumenta la fragilidad del sistema, lo que obliga a un equipo a gastar recursos adicionales en mantenimiento en lugar de crear. Al igual que su pariente financiero, si los préstamos continúan sin disminuir, la mayoría de los recursos se gastan en el pago de intereses, dejando muy poco para mejoras. La deuda técnica va a consumir los recursos técnicos hasta el punto en que la mayoría de los recursos se gasten simplemente manteniendo el sistema funcionando para detener todas las otras mejoras posibles.

Entonces, en última instancia, las preguntas no son si deberíamos hacerlo o no, sino que es ético dejar que los gerentes y los clientes crean que pueden confiar en cifras de productividad artificialmente infladas con el uso de cinta adhesiva digital. Algunos pensarían que es una decisión comercial, pero, francamente, esto es así solo porque los gerentes no lo entienden. Al final, alguien tendrá que pagar la deuda ya sea mediante una refactorización pesada o migrando a un nuevo sistema. En última instancia, para nosotros, los programadores, mantener los sistemas mantenibles, no debería tener que pedir volver a factorizar, ya que es una parte inherente del trabajo, no comprender esto es no comprender de qué se trata la ingeniería de software. Dicho esto, me doy cuenta de que existen sistemas que ya han incurrido en una deuda importante y el pago de esta deuda requerirá decisiones de los pagadores. Su trabajo es tal situación es al menos hacer su parte para dejar de pedir prestado. Esta deuda fue incurridaPOR NOSOTROS tal vez porque no lo sabíamos mejor, porque estábamos presionados para hacerlo, aún así, asumimos esta deuda y, muy a menudo, las personas a quienes les entregamos la deuda no la entienden, por lo tanto, no pueden manejarla adecuadamente.

Aquí está su software, todo listo, espero que les guste ... Pero por cierto, maximicé su tarjeta de crédito haciéndolo, espero que no les importe ... cya

El objetivo de la refactorización es simplificar el diseño y eliminar las ineficiencias. Esto hace que sea más fácil corregir errores y agregar nuevas funciones en el futuro.

La depuración es el doble de difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código de la manera más inteligente posible, por definición, no es lo suficientemente inteligente como para depurarlo.

Si continúa agregando nuevas funciones al código, la refactorización se amortizará rápidamente. Esto será visible en una tasa de error más baja, una depuración más rápida y soluciones más rápidas.

Escribir software es muy parecido a escribir un gran libro de no ficción o una enciclopedia.

El primer borrador siempre apesta. Siempre se puede mejorar reorganizándolo, eliminando secciones que no necesitan estar allí y asegurando un estilo consistente en todo momento.

Siempre que tenga que revisar, lo más simple es agregar una nueva sección, cambiar algunas palabras, etc. Pero a medida que las revisiones se acumulan, el libro comienza a perder su organización. Entonces tienes que hacer más pases de reorganización. Si no lo haces, el libro se convierte en un revoltijo sin sentido.

Tome su computadora de escritorio, por ejemplo. Tiene una torre, monitor, teclado, mouse, impresora, escáner y parlantes. En definitiva, todo lo que quieres es un bonito escritorio organizado. Así que simplemente conecta las cosas a ciegas, y unos minutos después, he aquí, todo está configurado de la manera que lo desee. Bueno ... casi como quieres.

Un día después, cuando cambia el equilibrio de sus altavoces, se da cuenta de que colocó accidentalmente sus altavoces izquierdo y derecho en las áreas equivocadas, por lo que desea cambiar sus posiciones. Pero oh no! Hay una jungla de cuerdas enredadas; cuando mueves los altavoces, el cable de tu mouse se engancha y ahora el mouse se arrastra junto con los altavoces. Además, su teclado ahora no tiene holgura: solía poder moverlo del escritorio a su regazo.

Muy bien, puedes simplemente desconectar el mouse y el teclado y volver a insertarlos para que todo esté arreglado. Pero esto no ayudará con futuras reorganizaciones y adiciones futuras. También tejer los cables de tu mouse y teclado a través de la jungla es una molestia.

La mejor solución es volver a enchufar todo para volver a enchufarlos de una manera limpia y ordenada donde cada cable no interfiera con el otro. Ahora los cambios futuros son fáciles y continúan siendo fáciles. Invierte un poco por adelantado para obtener grandes ganancias más adelante.

El punto clave es que la solución original funcionó principalmente. Eso es lo que pasa con la refactorización: para empezar, funciona, pero debe cambiar la forma en que las cosas ya existen para hacer cambios futuros fácilmente (mover los altavoces).

Es como limpiar la casa después de una fiesta salvaje y loca de la noche anterior.

Digamos que la sala de estar quedó totalmente destrozada. La casa sigue siendo una casa, la sala de estar sigue siendo una sala de estar. Funciona pero no es como podría ser. Después de mirar el desastre, te das cuenta de que debe limpiarse.

Entonces, comienzas a embolsar la basura. Ya se ve mejor. Entonces, miras alrededor de la habitación y decides enderezar los muebles. Vuelves a poner una pieza, luego la siguiente y la siguiente. Wow, la habitación se ve muy bien. Estas orgulloso.

Tu hermana entra y dice que la habitación parece basura, debes arreglar la estantería y aspirar la alfombra. Ella está en lo correcto. La habitación se ve muy, muy bien.

Miras a tu alrededor y ves que las persianas se verían mucho mejor si estuvieran a la misma altura. Hecho. Wow, la habitación es asombrosa.

Trata tu código de la misma manera.

¡Fácil!

Tómelo con un ejemplo ... todos en sus vidas han escrito una carta a un ser querido. Tiene que ser alguien querido porque en esas cartas generalmente también prestamos atención a la composición.

Entonces, tienes tu texto, ... el significado pasará de cualquier manera, ¡pero quieres que todo suene bien! ¿Derecho?

Refactorización, lo mismo ... misma información, más o menos, pero la composición es mejor. Y probablemente dará como resultado una mejor revisión por parte del lector.

Otro ejemplo: escribir un artículo para una revista. Dos escritores, ambos saben "sus cosas", la única diferencia es que uno sabe "cómo escribir" y el otro escribe como aprendió a escribir a partir de respuestas como estas.

¿De quién será el artículo que recordarás?

Todas las analogías con las cosas en el mundo físico, como construir un teatro, son, en mi opinión, terribles.

Debe explicar que el código de refactorización es como ... el código de refactorización. El software es maleable de una manera que los análogos físicos no lo son. A medida que las cosas se vuelven cada vez más complejas, uno debe reactivar (o rehacer, como desee) partes masivas o pequeñas de una base de código para que podamos continuar aumentando la complejidad sin volvernos locos.

¿Por qué refactorizamos? Porque el código que nunca se refactoriza cuesta más por minuto para mantener y cambiar, y finalmente se vuelve más problemático.

Lo interesante de la refactorización es que rehacemos la base de código pero, al menos al principio, la funcionalidad sigue siendo la misma.

Re-factorizar es lo mismo que limpiar algo y darle a las cosas un nuevo lugar para 'quedarse'

Fácil simple y algo que puede tomar muchas veces. A veces incluso agrego que esa persona X dejó un gran lío de cosas y tengo que limpiarlo.

Pensé en otro ejemplo, que aparentemente nadie ha mencionado aquí: refactorizar es casi exactamente lo mismo que reorganizar una ecuación en matemáticas (aunque eso podría quedar fuera del alcance de la 'persona no técnica, supongo).

Cuando reorganiza una ecuación, simplemente 'mueve cosas' para que sea más legible y más utilizable, sin cambiar el significado .

Dales una ecuación matemática simple. Por ejemplo:

¿Cuál es más simple?

y = x + x

o

y = 2x

La refactorización es un concepto similar, excepto que, en lugar de simples ecuaciones matemáticas, pones algoritmos. La idea principal es que puedes cambiar entre dos formas de hacer las cosas porque producirán el mismo resultado.

La refactorización más simple que se puede hacer es renombrar.

doX() { ... }
{
   doX()
}

Ahora, como realmente no queremos que las cosas se llamen doX porque realmente no sabemos lo que significa, cambiamos el nombre a algo que se explica más por sí mismo y lo reemplazamos en cualquier lugar donde lo hayamos utilizado.

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

Esto le ahorrará dinero más adelante cuando haya un problema o mejora, ya que reduce el tiempo para que las personas entiendan y arreglen su aplicación. Para ahorrar más dinero, existen herramientas gratuitas que hacen este trabajo por usted automáticamente, dependiendo del idioma que esté utilizando. Estas herramientas también tienen licencia para que no sea restrictivo y requiera que haga algo especial además de reconocerlo si lo usa directamente.

Una imagen dice más que mil palabras. Por ejemplo, la refactorización tiene dos casos de uso:

• Cuando las cosas no se hacen bien la primera vez:

• Cuando las cosas son tediosas:

Referencias

• xkcd: buen código

• xkcd: ¿vale la pena el tiempo?

Considere una respuesta dada en Refactorización , y no se la explique a una persona no técnica. La refactorización es una actividad técnica que no necesitan conocer:

Por supuesto, muchas personas dicen que están motivadas por la calidad, pero están más motivadas por el horario. En estos casos doy mi consejo más controvertido: ¡No lo cuentes!

¿Subversivo? No lo creo. Los desarrolladores de software son profesionales. Nuestro trabajo es construir software efectivo tan rápido como podamos. ... Un gerente basado en el horario quiere que haga las cosas lo más rápido que pueda; cómo lo hago es asunto mío. La forma más rápida es refactorizar; Por lo tanto, refactorizo.

(Refactorización, Martin Fowler, 2000, página 61)

Por supuesto, esto no funcionará si va a pasar un mes haciendo nada más que refactorizar, pero creo que, en general, es una mala idea, y es mucho mejor simplemente refactorizar en la medida necesaria para facilitar su tarea actual o la próxima. , o para limpiar el código con el que acaba de trabajar.