¿Cómo puedo hacer de la refactorización una prioridad para mi equipo?

"Es mejor pedir perdón que permiso" es cierto.

¿Por qué preocuparse por eso? Solo refactoriza las partes más horribles.

Ya sabes cuáles son los errores más costosos , ¿no?

Si no lo hace, entonces el paso 1 es definir de manera positiva y sin ambigüedades el código de problema más costoso, complejo, plagado de errores e infestado de errores.

Identifique el número de tickets de problemas, las horas de depuración y otros costos muy específicos y muy cuantificables .

Luego arregle algo en esa lista de problemas de alto costo

Cuando tiene que pedir perdón, puede apuntar a reducciones de costos.

En caso de que no lo sepa, la refactorización requiere unit pruebas para demostrar que los comportamientos de antes y después coinciden. Idealmente, esto debería ser una prueba automatizada y codificada, por ejemplo, una prueba unitaria.

Esto significa elegir una cosa . Escribe una prueba unitaria. Arregla eso una cosa Has hecho dos mejoras. (1) escribió una prueba y (2) reparó el código.

Iterar.

Siga la regla de los boy scouts: deje el lugar del campamento (código) un poco mejor de lo que lo encontró. Nunca he escuchado que alguien se haya redactado para hacer pequeñas mejoras de código "mientras estaban allí".

Tomaré un punto de vista quizás demasiado cínico.

Refactorizar es una píldora tan difícil de tragar. Obtienes la responsabilidad y la culpa, y los frutos de tu trabajo a menudo van a otra persona que se basa en tu base de código limpio.

Yo diría que si tales prácticas de ingeniería se han convertido en la cultura de su empresa, es posible que deba luchar en un nivel superior. Realmente no estás luchando por la refactorización, estás luchando por la excelencia en ingeniería, y ese es el tipo de cambio que solo surge en la administración cuando los golpea en la cara. En ese escenario, probablemente buscarán un zar de mejores prácticas, y todas sus grandes ideas se resumirán de todos modos.

Considere unirse a una compañía diferente donde se tomen más en serio las prácticas de ingeniería.

Me doy cuenta de que muchos de los carteles aquí parecen estar convencidos de que el problema en la administración, mientras que la pregunta no lo menciona.

Iría más allá de eso: en mi opinión, una base de código pésima casi nunca es directamente culpa de la administración. La administración no escribió ese código, los desarrolladores lo hicieron (hay algunas excepciones en mi empresa donde algunos de nuestros administradores actuales escribieron la base del código inicial). Por lo tanto, el problema de la cultura reside en los desarrolladores: si quieren que la cultura cambie, ellos mismos tendrán que cambiar.

Intento llevar esta realización y cambio de actitud a "mis" desarrolladores también. Cada vez que me preguntan "¿cuándo tendremos tiempo para refactorizar?", Actúo sorprendido y respondo "¡ya deberías estar refactorizando todo el tiempo!". La única forma en que creo que puedes mantener un código base en buen estado es triple:

1. Solo agrega código saludable.
2. Repare siempre el código que no sea tan saludable tan pronto como lo vea.
3. Si, por razones de la fecha límite, no puede hacer 1 o 2, siempre tenga una lista de problemas "corregir inmediatamente después de la fecha límite" y no acepte ninguna excusa para no trabajar en esa lista después de la fecha límite.

Invariablemente, el siguiente comentario de los desarrolladores es "pero, ¿cómo conseguimos tiempo para hacer esto, no tenemos tiempo ahora?". La única respuesta correcta (de nuevo IMHO) es "no tienes tiempo para NO hacer esto". Si no mantiene el código base en buen estado, encontrará que el tiempo de respuesta se hace cada vez más largo, los horarios se vuelven más impredecibles, los errores se vuelven más desagradables y el valor se reduce.

El cambio de actitud más importante que debe realizar en el equipo de desarrollo es que la "calidad" no es algo que haga en un momento específico en el tiempo ("cuando tengamos tiempo de refactorizar"), es algo que tiene que estar haciendo TODO. el tiempo.

Finalmente, una historia de advertencia. Si es presionado, negaré que esto haya sucedido. En una empresa para la que trabajé, había una aplicación de larga data con una base de código grande y heredada que se originó hace 10 años. Muchos desarrolladores, incluido yo, creían que esta base de código heredada era mala o, por lo menos, desactualizada, no con tecnología de punta. Así que presionamos para un gran proyecto de refactorización con éxito, y comenzamos el proyecto de reescritura, después de lo cual creímos que todo sería mejor.
Trabajamos largo y duro implementando casi todo de una manera nueva y moderna, usando nuevas bibliotecas, nuevas funciones de lenguaje. Cerca del final realizamos un esfuerzo masivo para juntar todo para permitir un nuevo lanzamiento de la aplicación de larga data con la nueva y mejorada base de código.
Como era de esperar, la nueva versión tuvo algunos problemas, debido a las nuevas bibliotecas con las que aún no estábamos familiarizados, y algunas interacciones en nuestro código que no habíamos previsto. Sin embargo, finalmente logramos que el lanzamiento fuera del mismo nivel que nuestros lanzamientos anteriores y fuera de la puerta. Respiramos aliviados ante nuestro "éxito". Luego, un subgrupo de desarrolladores regresó a la administración y solicitó un nuevo proyecto de refactorización porque nuestro nuevo código no era la bala de plata que esperaban, y vieron algunas oportunidades para volver a escribir algunas cosas ...

Moraleja de la historia: a menudo las cosas no están tan rotas como parecen, y 'comenzar de nuevo' generalmente significa que intercambiará una serie de problemas conocidos con una serie de problemas desconocidos, al menos como peludos. Refactorizar una parte a la vez!

Alguien me dijo una vez que cuando voy a una entrevista, no debo olvidar que también estoy entrevistando a la compañía. ¿Es un lugar donde quiero trabajar? ¿Hacen revisiones de código? ¿Tienen pruebas de integración automatizadas? Pruebas unitarias? ¿Qué piensan de la programación en parejas? Personalmente encontraría otro trabajo, y no olvide hacer algunas preguntas también esta vez.

Encuentra otra empresa, honestamente. Tales mejoras en el proceso de desarrollo requieren grandes saltos culturales, por lo que tomará un tiempo significativo antes de que todos se pongan en la misma página y para entonces ya no se preocupará tanto.

Si sientes que aún tienes algo de pelea en ti y aún no te has hundido, haz un empujón final. Trate de obtener el mayor apoyo de los miembros del equipo con ideas afines, revele su agotamiento a los superiores que se preocupan por su bienestar, evite la derivación y distanciara a cualquiera que pueda oponerse a sus creencias e intente incluir algunas horas obligatorias de refactorización en la planificación de nuevas proyectos / características.

Si te apasiona lo que haces y te importa tu empresa, ese sería un esfuerzo encomiable por tu parte. Si no se aprecia, entonces respétate y rescata antes de convertirte en un programador vacío.

Si tuviera que introducir una práctica para mejorar las cosas en este tipo de contexto, serían las revisiones de código. Las revisiones de código son

• generalmente aceptados intuitivamente por los desarrolladores como un factor para un mejor código, menos errores, etc.
• colaborativo y democrático
• no es demasiado lento si los haces de manera adecuada
• un buen lugar para hacer refactorización si no tiene tiempo para hacerlo durante el desarrollo "normal"
• un caballo de Troya bastante eficaz para introducir gradualmente todo tipo de mejores prácticas en términos de diseño de código, pruebas de unidad ...

No tiene que hacer revisiones de código de manera sistemática, solo al cometer partes de código grandes / complejas al principio.

Por supuesto, si cree que necesita respaldo oficial antes de introducir revisiones de código, es posible que primero tenga que convencer a su jefe de que la base de código se colapsará si las cosas se dejan como están.

Esto es lo que hago en tales situaciones (en los 15 años de mi carrera como desarrollador me he encontrado con ese código casi todos los días)

1. Liderar con el ejemplo: me aseguro de volver a factorizar el código que toco. Elimino sin piedad el código antiguo comentado y los grandes párrafos de comentarios.
2. Pida que se realicen los cambios de factor cada vez que me pidan que revise un cambio de código, sin lo cual no apruebo la revisión del código.
3. Lentamente la gente ve el cambio, cuando el código se vuelve más ágil, más legible y, por lo tanto, menos con errores. Lleva tiempo pero, lentamente, todo el equipo aprecia y adopta la práctica.

La administración nunca dedica tiempo para volver a factorizar el código (¡nunca tienen suficientes recursos!), por lo que hacerlo de forma lenta y constante es un enfoque correcto.

Haga que la gerencia investigue un poco sobre la "deuda técnica". También refiérase a la "Teoría de la ventana rota", ambos efectos tienen un impacto directo en la eficiencia, la calidad y la moral.

"Un sitio de trabajo limpio es un sitio de trabajo seguro y productivo", y cada contribución a un desastre complica el desastre de una manera exponencial, no lineal.

Si la situación no se resuelve, eventualmente cruzará un punto de no retorno, donde se volverá económicamente inviable, al enfrentarlo de manera incremental, antes de que eso suceda, los beneficios se recuperarán y le dará más combustible para enfrentar el problema. usted va.

Parece que tus problemas son más generales.
El problema de la refactorización es tanto un síntoma como un posible alivio de parte del problema.

El responsable del software y el equipo asignan el tiempo del equipo

Desde mi experiencia, creo que puede estar encontrando un problema al que llamo "todo el mundo es un administrador de software". Los gerentes de producto, los gerentes de proyecto y, en ocasiones, los ingenieros y evaluadores de sistemas pueden ser conocidos por tratar de microgestionar a los desarrolladores que probablemente ya tengan un gerente de software con experiencia. Incluso puede tener algunos miembros en su equipo que creen que su función es administrar.

Si usted es el administrador de software, haga asignaciones para la refactorización que desea, o mejor aún, haga que su equipo le proponga una refactorización para su aprobación. Para no volver a utilizar el sistema de microgestión, es posible que tenga directrices sobre la edad / autor / tamaño / contexto del código que debe ser refactorizado y que puede ser refaccionado libremente frente a la necesidad de aprobación. Si un miembro de su equipo quiere refactorizar masivamente cuatro clases grandes de código antiguo complejo que no escribió que no son parte de su característica, su distracción de dos semanas es su problema, por lo que necesita la oportunidad de decir no.

Puede escabullirse, pero creo que es mejor construir sus estimaciones cuidadosamente con tiempo para el análisis, diseño, codificación, múltiples formas de prueba (al menos unidad e integración), refactorización y riesgo según lo juzgado históricamente y por La falta de experiencia o claridad asociada a la tarea. Si ha sido demasiado abierto con respecto al funcionamiento de su equipo (o tiene miembros en su equipo que lo son), puede ser conveniente limitar los canales de comunicación para que lo revisen y discutan recursos y resultados, no métodos.

Las primeras opciones del proyecto crean un ciclo vicioso para refactorizar

El mantenimiento del software es difícil. Es doblemente difícil si otros en la organización están haciendo elecciones a sus expensas. Esto está mal, pero no es nuevo. Ha sido abordado por Barry Boehm, uno de nuestros grandes escritores de software que presenta un modelo de gestión que describe como Theory W.

enlace

A menudo, los desarrolladores de software son golpeados para producir bajo el enfoque de gestión de Theory-X que dice que los trabajadores son básicamente flojos y que no se desempeñarán a menos que sean sometidos a la sumisión. Boehm resume y contrasta su modelo propuesto de la siguiente manera:

"En lugar de caracterizar a un gerente como un autócrata (Teoría X), un entrenador (Teoría Y) o un facilitador (Teoría Z), la Teoría W caracteriza el papel principal de un gerente como negociador entre sus diferentes constituyentes y un empaquetador de soluciones de proyectos con condiciones de éxito para todos los partidos. Además, el administrador también es un defensor de objetivos, un monitor del progreso hacia los objetivos y un activista en la búsqueda de conflictos de proyectos diarios de ganar-perder o perder, confrontándolos y cambiándolos a situaciones de ganar-ganar ".

Rápido y sucio a menudo es solo sucio

Boehm continúa señalando la razón por la cual las cosas son tan miserables para los desarrolladores del equipo de mantenimiento.

"La creación de un producto rápido y descuidado puede ser una" ganancia "a corto plazo y de bajo costo para el desarrollador y el cliente del software, pero será una" pérdida "para el usuario y el mantenedor". Tenga en cuenta que en el modelo de Boehm, el cliente es más un administrador de contratos en lugar de un usuario final. En la mayoría de las empresas, piense en el gerente de producto como un sustituto del cliente, o quizás en la persona que compra el producto para su lista de características.

Mi solución sería no lanzar el equipo de desarrollo original (o al menos el cable original) hasta que el código sea refactorizado para al menos cumplir con los estándares de codificación.

Para el cliente, creo que es razonable contar con el gerente de producto como un sustituto del cliente, y el grupo de personas recompensadas por entregar algo rápido y sucio ciertamente puede ampliarse, por lo que hay un gran número de miembros para hacer las cosas de manera incorrecta .

La refactorización no es negociable

No abandone su rol como administrador de software. Debe tener autoridad y discreción para usar el tiempo de su equipo en el proceso y las mejoras del producto. En ese rol, es posible que deba negociar sus elecciones para que su equipo sea más profesional. Sin embargo, con respecto al proceso, no negocies con el marketing, porque en mi experiencia, es un juego perdido. Negociar con la dirección de ingeniería. Demuestra que tienes visión. Crear un equipo de software profesional es una extensión de su función y es mucho más probable que se vea como un ganar-ganar.

Siempre se puede esperar. Eventualmente, el equipo no cumplirá con suficientes plazos y producirá software con suficientes errores, la gerencia se echará a perder y dirá que por Dios algo es mejor que cambie

Bien, esa es una proposición arriesgada. Pero en realidad es lo que sucedió en nuestra tienda hace varios años (parte de la dificultad estaba en comunicarse con la administración sobre los plazos de , pero esa es otra historia), y es una de las razones por las que ahora tenemos decenas de miles de pruebas automatizadas, propiedad de código compartido, la libertad de refactorizar, la voluntad de eliminar el código muerto y las versiones de mayor calidad que hemos tenido.

Tal vez lo más sorprendente es que nadie perdió su trabajo en el proceso, algo que le acredito a nuestro jefe que viene a batallar por nosotros, y un consultor que defendió el caso de refactorización e integración continua en nuestro nombre. Siempre suena más convincente cuando alguien del exterior lo dice.

Creo que la respuesta a cómo encontrar el tiempo depende de por qué quieres refactorizar el código.

Si funciona, no es necesario un refactor especial y puedes hacerlo cuando tocas esa parte del código. Por lo tanto, no necesitas un tiempo especial para eso.

Si ralentiza el desarrollo de su equipo, necesita hablar con el líder del equipo sobre eso y crear una tarea especial para refactorizar y tendrá tiempo.

Lo mismo para la velocidad de ejecución y otros casos, si el refactor puede mejorar algo y no solo su "buen código" o su opinión sobre cómo debería ser el código, y proporcionar un beneficio real, crear tareas o hablar con alguien que sea responsable de que.

Me reí un poco de la forma en que describiste las cosas, ya que suena bastante similar al código base en el que trabajo, por lo que creo que nuestras situaciones son bastante similares. Afortunadamente, en mi situación, tengo un administrador con visión de futuro que ha decidido que la mejor manera de mejorar el código base es a través de la modularización utilizando un marco de desarrollo web moderno en lugar de simplemente refactorizar todo el código base. De esta manera, los puntos problemáticos de la aplicación principal pueden reescribirse como módulos separados y luego integrarse en la aplicación principal (pero aún así ser esencialmente independientes). Este puede ser un enfoque que desee mencionar ya que no requeriría refactorizar todo el código base (¿presumiblemente grande?) Con el que está trabajando.

Por supuesto, puedo estar un poco alejado de lo que está diciendo ya que quizás su base de código no sea tan mala como con la que trabajo, en ese caso diría, ¿por qué no hacer pequeñas optimizaciones a medida que avanza? Los desarrolladores de mi equipo no tienen problemas para eliminar comentarios estúpidos o obsoletos y cosas de esa naturaleza, y no creo que eso sea algo que deba requerir aportaciones de la administración, ya que generalmente los desarrolladores reciben algún poder para optimizar las cosas según sea necesario.

Si el código base es realmente frágil, debe tener cuidado y esto puede deberse a que no quieran realizar una refactorización importante, ya que esto podría terminar convirtiéndose en un proyecto de un mes de duración y probablemente requiera la bifurcación de un proyecto y su puesta a punto. Los desarrolladores están en ese proyecto y se llevan otras tareas de desarrollo, como la solución inmediata de errores que pueden hacer que pierdan clientes, etc.

Todas las cosas consideradas, en cuanto a otras personas que dicen que debe renunciar, etc., creo que depende de cómo la administración ve las cosas, si entienden la situación y se dan cuenta de por qué algunas cosas pueden demorar más de lo que deberían, entonces las cosas podrían Estaré bien en lo que respecta al entorno de trabajo, pero si se están metiendo constantemente con usted sobre un trabajo atrasado, eso podría ser perjudicial con el tiempo. Soy afortunado de tener una administración que básicamente se da cuenta de que la aplicación es un pedazo de basura, pero tiene muchos clientes y dinero, por lo que sigue siendo valioso y vale la pena hacer correcciones de errores, aunque solo sea a corto plazo. .

Su principal problema es que los códigos no tienen suficiente visibilidad.

Sugiero usar una herramienta de integración continua como Jenkins , y una herramienta de análisis de código estático integrada a ella que mide la complejidad ciclomática, los estándares de denominación, la longitud del código, etc.

Cuando un programador realiza un cambio, Jenkins ejecutará las pruebas de unidades, ejecutará la herramienta de análisis de código estático y generará un informe web que todos pueden ver, con un estado de color similar al del semáforo.

Cuando la calidad del código es visible para todos (especialmente el jefe del equipo y el jefe) y las pruebas de control de versiones y unidades están ahí para que su espalda ... la gente se sienta animada a refactorizar.

El código llegó de esta manera lentamente sobre muchos cambios pequeños. Tendrá que arreglarse de esa manera también.

En primer lugar, puede hacer esto a medida que avanza: aumente todas las estimaciones en un 10% para permitir la mejora del código y el mantenimiento a largo plazo. Si alguien se queja, pregúntele si es mejor revisar el aceite del motor de un automóvil todas las semanas o esperar hasta que el motor se bloquee por completo.

Organice una reunión y determine los estándares de codificación constantes.

Introduzca reglas básicas para usar a medida que avanza:

Cada vez que se introduce un nuevo código en una clase, se deben escribir pruebas automatizadas para probar que la clase funciona (no solo el nuevo código).

Siempre que se corrija un error, se deben escribir pruebas automatizadas para probar que la clase funciona (no solo el código fijo).

Cada vez que un programador modifica un archivo, debe corregir todas las advertencias del compilador en ese archivo y actualizar el código para que cumpla con los nuevos estándares de codificación.

Después de un tiempo, el código más utilizado estará actualizado y será cubierto por pruebas automatizadas. El código más antiguo se actualizará cuando se cambie, si nunca se cambia, nunca tendrá que preocuparse por él.

Lo importante es integrar estos hábitos en las tareas de codificación estándar para que ninguno de ellos tome una gran cantidad de tiempo lejos del trabajo "real", pero todos ofrecen beneficios reales. ¡No intentes hacer un proyecto de refactorizar el código antiguo, es un dolor horrible, aburrido y complicado que se verá como mucho tiempo desperdiciado para los no técnicos!

La forma de obtener los recursos (tiempo) que necesita es concentrarse en alinear la capacidad y el deseo. Su jefe es impulsado por objetivos (generalmente, ganancias o tiempos de entrega para nuevas características), y ve a la refactorización como ingenieros que pierden tiempo y se dedican a esos objetivos. Necesita encontrar una manera de convencerlo de que los objetivos se cumplirán y se superarán si dedica tiempo a refactorizar.

El primer paso es averiguar qué dolor siente su jefe. Identifica cuáles son sus mayores problemas. Luego resuelva cómo se alinea lo que quiere hacer con la solución de sus problemas y presente un caso de negocio sólido para hacerlo. Use sus sistemas de seguimiento de defectos y planificación de proyectos (tiempo excedido) para proporcionar evidencia de dónde se encuentran los problemas. Necesitas hechos, no sentimientos. Sin las métricas (recuento de errores / módulo, costo para solucionarlos), la refactorización es solo un programador que tiene un juego a expensas de alguien. Su jefe solo le dará los recursos necesarios si puede mostrar un caso de negocio sólido para hacerlo.

La mayoría de las veces, el código basura es demasiado costoso de arreglar. Sin pruebas de regresión automatizadas, el costo de probar el código refactorizado es extremadamente alto.

La mayoría de las veces he visto un código incorrecto en una necesidad real de refactorización, ha habido una gran cantidad de características no documentadas y complejidad en los requisitos que no se pueden entender desde el principio. No es una tarea menor y mi experiencia es un orden de magnitud más difícil de estimar el costo de un trabajo de refactorización que agregar una nueva función.

Me abstendré de seguir adelante y hacerlo detrás de ustedes, jefes atrás (si no se rompió y usted lo rompió, cómo se ve) - corrija el código que debe cambiar de todos modos, pero si no está roto no lo arregles

Extrañamente nadie menciona esto:

Para que las cosas sean una prioridad, hazlas fáciles: Obtén una buena herramienta de refactorización.

Existen excelentes herramientas de refactorización (al menos para .NET afaik). Ah, y no olvides escribir pruebas unitarias de antemano (como ya lo han indicado otros).

¡Buena suerte!