¿Cuál es una buena relación entre el tiempo de refactorización y el tiempo de desarrollo?

Question

Estoy tratando de construir un plan sobre cómo podríamos dedicar más tiempo a refactorizar. Así que quería comparar con los estándares de la industria, pero tengo dificultades para encontrar estudios o métricas sobre eso.

Creo que el 20% del tiempo de desarrollo dedicado a la refactorización parece una buena proporción, pero no tengo nada que mostrar.

En mi mente, para el 100% o el tiempo dev:

• 50% se gasta la escritura de código, depuración, etc ...
• 30% está dedicado a escribir unidad de pruebas
• 20% se gasta el código de refactorización

Así que alrededor de 1 línea de código para 2 escritos termina siendo en el producto enviado. Obviamente, el tiempo de diseño, tiempo de documentación, etc. está integrado en estos porcentajes.

¿Qué es un estándar de la industria? Como regla general, ¿qué está usando su equipo? Gracias, Olivier

Answer 1

Tu comentario dice que tienes millones de líneas de código pero no pruebas de unidades, y que te está costando convencer a la dirección de que las pruebas unitarias valen la pena. Según el libro de Fowler, la refacturación debe ir acompañada de pruebas unitarias para proporcionar la confianza de que no se está rompiendo nada mientras se refactoriza. Estoy de acuerdo, y sugeriría que las pruebas unitarias van a proporcionar más valor que cualquier otra cosa en esta etapa, así que apunte primero a ese objetivo. Recomiendo encarecidamente el libro de Michael Feathers "Trabajar eficazmente con código heredado" para obtener sugerencias sobre cómo hacer esto. Ni siquiera tiene que escribir más de unas pocas pruebas unitarias para que sea un esfuerzo que valga la pena, simplemente ejecute el marco.

Paso 0: obtenga un marco de prueba de unidades automatizado en su código.

No vas a tratar de lograr esto solo, ¿o sí? Este es un gran proyecto, y espero que seas parte de un equipo técnico superior que comparte el dolor contigo. Tienes que hacer que todos compren en este 100%. Necesitarás su respaldo cuando vayas a ver a tu jefe, necesitarás su experiencia para compartir la creación del diseño y necesitarás su total acuerdo en el diseño.

Paso 1: juntar un grupo.

Sin un plan y un objetivo, la refacturación no ayudará mucho. ¿Estás esperando simplemente cortar el código y hacer módulos más pequeños? ¿Vas a tener código organizado en dominios? ¿Vas a tratar de encajar algunas interfaces de servicio en él? ¿Vas a refactorizar a una arquitectura de n niveles? ¿Qué piensan usted y el grupo que necesitan hacer? ¿Y cómo vas a comunicar este plan de diseño y refactorización a las PE?

Paso 2: obtener la posición para hacer un diseño arquitectónico inicial y la planificación del estado final.

Ahora para la parte difícil. Está pidiendo el 20% del tiempo de 30 ingenieros, que probablemente sea de más de $ 500,000 por año. Necesitará mucha más justificación que la "deuda técnica acumulada". Necesitará mostrar el retorno de la inversión.

Así que prepárese para responder a la pregunta que su jefe seguramente formulará: "¿por qué debería hacerlo?" ¿Qué esperas obtener refactorizando? ¿Reducirá el esfuerzo de desarrollo en nuevas características en un 10%? 100%? ¿Aumentará la calidad del código/reducirá los errores/reducirá los costos de soporte? ¿Va a acelerar el tiempo de comercialización? ¿Por cuanto? ¿Esto le permitirá reducir el número de SE o contratistas? ¿Cuántos? ¿O podrá agregar más características por lanzamiento? También hay aspectos negativos: ¿cuántas características se retrasarán si le dan un año para montarse con refactorización? ¿Por cuánto tiempo se retrasarán?

Paso 3: hacer una estimación seria.

Ahora que está armado con un diseño, un plan, una justificación monetaria, y cuenta con el respaldo del personal técnico, vuelva con su jefe y presente su caso a él o ella. Tendrás mucha mejor suerte que decir "deberíamos gastar el 20% de nuestro tiempo en refactorizar, algunos tipos en Internet lo dicen".

Answer 2

Dudo que haya ninguna norma.

Para su desglose: la mayoría de los equipos no escriben pruebas unitarias y no refactorizan (hasta que algo se rompe o detiene el desarrollo). Más comúnmente, la asignación de tiempo de refactorización es < 1%.

Si usted está interesado en la buena práctica entonces ....

• Refactoring puede ser una actividad continua como parte del proceso de desarrollo. Ve un potencial de mejora y asigna personalmente un poco de tiempo para mejorar las cosas. Aquí el tiempo de refactorización < 5%.

• Realiza revisiones de código regulares. Diga, una vez en unos meses. Luego, puede dedicar unos días exclusivamente para que el equipo revise su código y lo mejore. Aquí también < 5%.

Answer 3

esta configuración depende de muchos factores como el tipo de negocio que se encuentra, el tipo de proceso de su uso de la empresa, el tipo de equipo que se encuentra, qué idioma se está utilizando, etc.

No son absolutamente ninguna respuesta correcta. Si se encuentra en un campo que se mueve mucho en el requisito y si el cliente cambia mucho y utiliza un método ágil, será más susceptible de refactorización. Si está en un banco y tiene un equipo que usa un enfoque en cascada, es más propenso a escribir código cada vez más a refactorizar.

Answer 4

Creo que una relación así variaría ampliamente según las personas, el proyecto, las herramientas y, probablemente, otras cosas. Normalmente, sin embargo, esto se contabilizaría en la depuración y/o prueba, ya que en un nuevo proyecto normalmente sería parte de lidiar con los problemas descubiertos más tarde. También estaría sucediendo algo en la escritura del código inicial.

Answer 5

Mi enfoque para refactorizar es hacerlo al mismo tiempo que arreglar cosas. Los beneficios de refactorizar solo se obtienen cuando se mantiene el código, por lo que el código de refactorización ofrece muy pocos beneficios, pero no presenta muchos errores y no requiere funciones nuevas.

Cuando estoy solucionando un error, busco la forma de refactorizar, es decir, el tiempo de refactorización se incluye en la categoría de escritura del código/depuración (que yo diría que es dos categorías separadas).

Answer 6

Realmente no designo una cantidad de tiempo separada para cosas como refactorización, pruebas de unidad y documentación. Simplemente los considero como parte del producto terminado, y el trabajo no está terminado hasta que lo estén.

Answer 7

¿Cuál es su enfoque de diseño? ¿Cascada? ¿Ágil? ¿Qué tan grande es tu proyecto? ¿Qué tan grande es tu equipo?

Lo más productivo que he estado haciendo mientras tanto El desarrollo ágil tiende a 33/33/33, o incluso a 30/30/40. Una vez que haya escrito la prueba, y luego haya escrito el código para pasar la prueba, entonces puede refactorizar y afinar el código, con la confianza de que no está rompiendo nada.

En un proyecto pequeño, puede hipotéticamente diseñar su código a la perfección y nunca tener que probar/refactorizar (nunca lo he visto funcionar). En un proyecto grande, o uno con muchas manos, o uno con muchos clientes pidiendo muchas cosas diferentes, la refacturación y las pruebas son mucho más importantes que el código en sí.

Es como preguntar, durante la vida útil de una casa, muchas veces debe construir la casa, cuántas veces debe consultar el código de construcción y cuántas veces debe realizar el mantenimiento. Obviamente, la construcción de la casa es lo más importante, y en teoría, puedes diseñar una casa "perfecta" que no requiera renovación en el futuro, pero es poco probable.

Es más probable que dedique un año o dos a la construcción de la casa y que el resto de la casa se renueve periódicamente. Reforzar los miembros portadores de carga es más importante que construir un mazo, incluso si sus clientes están pidiendo un mazo. Serán infelices, pero estarán aún más descontentos si cae el techo y todo lo que tienen que vivir es una cubierta.

Del mismo modo, gastaría X cantidad de tiempo escribiendo el código, pero una mayor cantidad del tiempo lo refabricación y la optimización a lo largo del ciclo de vida del proyecto.

Answer 8

Primer punto, escribir código/depuración/refactorización es IMO una actividad única que debe ocurrir durante toda la vida del proyecto. Un diseño perfecto no existe realmente, ya que un diseño es algo efímero. Algo perfecto hoy puede ser totalmente invalidado por nuevos requisitos mañana.

Segundo punto, he visto muchos proyectos en los que las pruebas de unidad de escritura toman más tiempo que escribir el código para que pasen.

Así que para mí, las proporciones son más como:

• 50%: pruebas unitarias

• el resto: la codificación/depuración/refactorización/documentación

Answer 9

Para código bueno y bien diseñado, el 5% o menos me suena correcto para el desarrollo continuo.

Para código problemático que necesita un rediseño serio, es posible que tenga que presupuestar un porcentaje mucho mayor para la refactorización inicial, antes de agregar nuevas características o corregir errores graves.

Answer 10

Si tiene dificultades para entender su código, entonces es hora de refactorizar.

De lo contrario, corre el riesgo de perder tiempo de depuración debido a malentendidos de lo que hace su código; en otras palabras, ha incurrido en demasiada deuda para arriesgarse a no refactorizar.

Del mismo modo, si no está seguro de qué es una pieza de código, asegúrese de escribir una prueba unitaria que verifique su comprensión.

Estas son solo reglas generales que sigo para que no pierda demasiado tiempo en el depurador. Por lo tanto, el tiempo real que dedico a la refactorización varía mucho según la complejidad del código y la etapa en la que estoy en desarrollo. Además, si el código es demasiado complejo, suele ser una señal de que las clases deben dividirse en piezas más pequeñas, fáciles de entender y más fáciles de mantener.