¿Es una buena idea programar un horario regular para limpiar el código? [cerrado]

42

Estoy administrando un pequeño equipo de desarrolladores. De vez en cuando decidimos que vamos a pasar un día o dos para limpiar nuestro código.

¿Sería una buena idea programar un horario regular, digamos 1 semana cada 2 meses, para simplemente limpiar nuestra base de código?

user84667
fuente
99
Preferiría primero comenzar a registrar todas las cosas que requieren limpieza en una herramienta de seguimiento de problemas . El análisis de las cuestiones conectado el rastreador podría dar una idea mejor (mucho mejor) en lo que sería el enfoque más adecuado para un determinado proyecto
mosquito
44
Sería una mejor idea programar un horario regular para una revisión de código
l46kok
1
¿Qué quieres decir cuando dices 'limpiar'? ¿Está embelleciendo el código o manejando todas las etiquetas FIXME y TODO u obteniendo más rendimiento del código escrito rápidamente? ¿O algo mas? Cualquiera de estos podría clasificarse como limpieza, pero atribuiría diferentes prioridades a cada uno de ellos.
Paul
Otro "cerrado como demasiado popular", ¿eh, chicos?
MGOwen

Respuestas:

100

No.

Arreglalo mientras trabajas en él:

  • Si espera para refactorizar la parte en la que está trabajando, se olvidará mucho de eso y tendrá que pasar tiempo para familiarizarse nuevamente con él.
  • No terminará el código "dorado" que nunca se usará porque los requisitos cambiaron
MGOwen
fuente
2
Mi dinero en esta respuesta ..
Soner Gönül
2
+1 por excelente respuesta. No va a terminar el código "chapado en oro" que nunca termina siendo utilizado porque los requisitos cambiaron
Md Mahbubur Rahman
8
En un proyecto perfecto con una administración perfecta y un equipo de desarrolladores uniformemente excelentes, esta respuesta se mantendría. Lamentablemente, nunca he visto ni oído hablar de tal proyecto en mis diez años en la industria.
Ben
3
Intente hacer esto, pero cuando no pueda (y sucederá debido a la presión del tiempo o porque simplemente no sabe cómo hacerlo correctamente) cree un ticket en su sistema de tickets. De esta forma, es de esperar que pueda volver a resolverlo mientras el problema aún está fresco en su mente y no solo cuando finalmente comienza a causar problemas.
Sarien
1
Creo que este es un buen consejo, pero no aborda la pregunta formulada. Haivng manejó un equipo con una base de código horrible (era horrible antes de que llegara allí). Era tiempo muy bien empleado para abordar la refactorización y la limpieza de funciones específicas. Los llamamos proyectos de infraestructura y los trabajamos en cada sprint que pudimos. A menudo, estas cosas eran elementos que no formaban parte de otro cambio, pero eran cosas que el equipo había identificado como áreas problemáticas. Hicimos retrospectivas trimestrales y actualizaríamos esta lista regularmente.
Bill Leeper
21

Mi opinión personal: es absolutamente necesaria para el 90% de los proyectos.

Particularmente para proyectos que están fuertemente impulsados ​​por las ventas, generalmente hay un gran impulso para incluir nuevas características en cada lanzamiento, y inevitablemente terminas comprometiendo tus mejores instintos e introduciendo algunos trucos / trucos aquí y allá.

Eventualmente, ha acumulado suficiente 'deuda técnica' a través de estos pequeños compromisos que termina pasando una buena cantidad de tiempo trabajando en las fallas en la base del código, y no puede utilizar todo su potencial.

Por lo general, hay dos tipos de problemas generados de esta manera:

  • Pequeños que pueden repararse fácilmente pero que pueden ser sistémicos, por ejemplo, parámetros incorrectamente nombrados, manejo de errores incompleto, etc. Por lo general, tendrán poco impacto fuera del bloque de código donde aparecen. La mejor manera de lidiar con esto es revisar el código y verificar el código a medida que se escribe / modifica. Como han dicho otros, no es necesario reservar un ciclo de refactorización especial para corregir estos errores.
  • Grandes que pueden haber surgido de especificaciones incompletas o malas decisiones de diseño desde el principio, o dos desarrolladores / equipos que crean dos soluciones diferentes para el mismo problema. En general, estos son mucho más difíciles de solucionar y requieren un esfuerzo concertado para solucionarlos. Como resultado, generalmente se difieren, hasta convertirse en una molestia perpetua. Este tipo de problemas requieren un período de tiempo dedicado para solucionarlo.

Generalmente trato de reservar tiempo para un ciclo puro de refactorización / corrección de errores cada 3 o 4 ciclos. Siempre les pido a mis desarrolladores que me digan cuándo se sienten frustrados con el código base también. No todos los desarrolladores tienen que trabajar en el esfuerzo de limpieza, por lo general (pero no siempre) puede escalonar un poco a los equipos, por lo que solo un equipo está trabajando en la limpieza en un momento dado.

pswg
fuente
1
No entiendo el mayor número de grandes empujones como un problema ágil.
JeffO
2
@JeffO No, no es un problema ágil. Es un problema de gestión. Sin embargo, por lo que he visto, las compañías que están fuertemente influenciadas por las ventas tienden a gravitar hacia ciclos de lanzamiento agresivos y grandes conjuntos de características. Las estrategias ágiles tienden a atraer a estas empresas (ya sea que realmente sigan las estrategias o no). Si bien me gusta el desarrollo ágil, mi experiencia ha demostrado que cuando una empresa se llama a sí misma 'ágil', generalmente significa que puedo esperar ver una buena cantidad de deuda técnica en la base del código.
pswg
Supongo que si no tienen ninguna metodología, pueden llamarse a sí mismos como quieran. Como ágil, es la palabra de moda actual, es la más atractiva. Ha pasado un tiempo desde que estaba en un proyecto de cascada; Fue un desastre de muchas otras maneras, que nunca lo uso como argumento en contra de la metodología.
JeffO
En cualquier proyecto, ágil o no, refactorizar y limpiar el código es algo que hace a medida que avanza, para mantener constantemente la deuda técnica al mínimo. Si no tiene en cuenta eso en sus estimaciones, tendrá que comenzar a hacerlo. No puede permitir que se acumulen deudas técnicas hasta que necesite detener todo para solucionarlo. En su lugar, siga la regla de exploración: "Deje siempre el código más limpio de lo que lo encontró".
Christoffer Hammarström
En mi experiencia, los equipos sin experiencia que comienzan con scrum, sin observar buenos principios de codificación (como XP), a veces pueden centrarse demasiado en la funcionalidad (historias). En su lugar, deberían decir que una historia no se hace hasta que el código sea lo suficientemente "bueno", pero no todos tienen la columna vertebral suficiente para hacerlo en un plazo inminente. Y con Agile, tiende a tener más plazos en un tiempo más corto, por lo que también lo asocio con los métodos Agile, mientras que estoy perfectamente consciente de que no son la causa.
markijbema
11

Tengo a mis desarrolladores ordenando su código antes de registrarse (Subversion) o fusionarse con la rama de desarrollo principal (Git).

Les hago hacer lo siguiente:

  • Eliminar comentarios irrelevantes
  • Asegúrese de que sus métodos, argumentos y variables se denominen adecuadamente
  • Asegúrese de que haya una estructura para sus clases y que los elementos estén encapsulados como deberían ser
  • Refactorizar para mejorar la legibilidad y reducir los olores de código

Para los proyectos más grandes, el código se revisa formalmente antes de fusionarse desde la rama de desarrollo a la rama principal.

Creo que "dedicar tiempo" significará que es algo que podría diferirse o postergarse debido a la cantidad de trabajo involucrado. Al hacer que los desarrolladores lo hagan en un check-in (que equivale a una solicitud / problema de cambio en JIRA) es mucho más manejable.

Sam
fuente
Solo por curiosidad: ¿Por qué estás usando dos VCS diferentes?
Eekhoorn
2
Hubo / hay una fase migratoria. Hemos migrado la mayoría de los repositorios SVN ahora, mencioné ambos por algún contexto.
Sam
Esto es lo que hago. Limpie el código antes de un registro y refactorícelo si vuelvo al código para mejorar la funcionalidad.
Barfieldmv
1
Esto no resolverá los problemas persistentes que acechan en áreas que pueden no ser parte de la solicitud de características del equipo del producto.
Bill Leeper
9

No en mi opinión Si deja pasar demasiado tiempo entre el momento en que se encuentra con la deuda tecnológica y cuando la repara, pierde el contexto de cuál es el problema. Tarda más en arreglarse y tiende a arreglarse peor. Lo más importante es que la gente abandona las ventanas rotas porque no es una "semana de limpieza".

Personalmente, negocio la limpieza técnica de la deuda en cada sprint si sé que hemos creado algunos antes. Mantiene la deuda fresca en la mente de las personas. Limita la cantidad de código usando el código del problema para que la refactorización sea más fácil. Evita que la deuda técnica se acumule. Y ayuda a impulsar a los desarrolladores a simplemente juntar algo, porque voy a hacer que lo hagan el próximo sprint (también podría hacerlo bien en primer lugar).

Telastyn
fuente
Tu segunda oración contradice la primera. Dijiste que no, pero luego dijiste que trabajas este tipo de cosas en cada sprint. De una manera que está programando tiempo para hacerlo.
Bill Leeper
2
@BillLeeper - enh. Cuando escucho "tiempo regular" eso significa que hay un intervalo regular para hacer el trabajo de limpieza. OMI, eso es incorrecto: todo el tiempo es el momento adecuado para hacer el trabajo de limpieza.
Telastyn
1
Buen punto, estoy de acuerdo en que el tiempo regular no funciona bien. Con demasiada frecuencia, las prioridades hacen que se canceló etc.
Bill Leeper
4

Definitivamente diría que sí, con una condición: debe hacerse con frecuencia, preferiblemente semanalmente. Creo que una revisión de código regular programada junto con la acción real sobre los elementos que salen de la revisión de código vale la pena muy rápidamente. Ver la respuesta de pswg

1 semana cada 2 meses definitivamente no es suficiente. Esto habla a la mayoría de las otras respuestas que respondieron con 'No' a su pregunta. La esencia de la mayoría de estas respuestas es que si espera demasiado tiempo ya no estará en contacto con el código y, por lo general, lleva mucho más tiempo arreglarlo / limpiarlo / refactorizarlo.

Mauritz Hansen
fuente
Hacemos un "martes de deuda técnica" para esto. Está a mitad de camino de una semana de trabajo israelí y nos permite dar un paso atrás para tratar los problemas
Zachary K
1

No está tan claro si se refería a un ejercicio adicional de limpieza del código de vez en cuando. En ese sentido, si. Cualquiera que sea la práctica que sigamos, siempre se produce cierta degradación.

No debe usar eso como excusa para no hacer lo correcto [Aplicando principios SÓLIDOS, pruebas unitarias relevantes, inspecciones, etc.] en primer lugar.

Jayan
fuente
1

Creo que las dos respuestas populares "No" y "Sí" son dos aspectos de la misma verdad. Recuerde que el OP está hablando de un grupo que está administrando, no solo de sí mismo como individuo. No podemos suponer que todos los desarrolladores del grupo sean lo suficientemente disciplinados como para escribir código limpio y fácil de leer; y está el problema de la presión externa y las metodologías de estilo ágil. Además, incluso con los mejores esfuerzos de las personas, sus diferencias de estilo significarán que podrían escribir código que se consideraría limpio cuando se separara, pero inmundo cuando se considerara junto con otras personas (sin mencionar las interfaces chirriantes).

Por otro lado, el "arreglarlo mientras se trabaja en él" es, en mi opinión, un ideal al que aspirar. Puede hacer que su código salga aún más "arreglado"

  • cuidado de pares CRing
  • escribir pruebas unitarias junto con el código mismo
  • adoptando pautas de codificación
  • utilizando formateadores y linters automáticos (pero YMMV)
  • etc.

Ahora, si el equipo del OP adopta lo anterior, y si alienta a sus subordinados, por ejemplo, durante las revisiones de código y durante las sesiones periódicas de limpieza de código, para tratar de anticipar los escollos y evitar la fealdad por adelantado, con el tiempo, con suerte, necesitará menos tiempo de limpieza (Y luego podrían dedicar ese tiempo a la documentación, la refactorización más profunda y el intercambio de conocimientos de lo que han escrito y consolidado).

einpoklum - reinstalar a Monica
fuente
1

Creo que programar un horario regular es muy bueno, ya sea que sea una tarea en un proyecto de estilo cascada normal o historias en uno ágil. Tener un horario establecido puede no ser tan valioso como simplemente incluirlo en su horario. Esto le permite hacerlo como parte del cronograma versus cancelar el día de limpieza porque está atrasado en el proyecto.

Habiendo administrado un proyecto que tenía una enorme cantidad de deuda de código, trabajar en ellos de manera regular fue clave para que las cosas funcionen sin problemas. Algunas de nuestras cosas eran grandes, otras pequeñas.

Después de unos meses de este tipo de trabajo, el líder de nuestro equipo de operaciones me dijo lo fácil que estaba todo.

Puede que cada artículo no parezca mucho, pero al igual que todas las deudas, se anuncia.

Bill Leeper
fuente
1

La respuesta ideal es No, porque sigue los pasos necesarios para evitar que esto sea una necesidad (limpie a medida que avanza por varias razones ya mencionadas).

Este puede ser el objetivo al final, pero es posible que tenga un equipo que esté lejos de poner esto en práctica.

Los gerentes deben asumir cierta responsabilidad. No siempre es culpa del desarrollador. Los gerentes pueden decir una cosa, pero comienzan a presionar para que los proyectos se terminen y hacen sugerencias que promueven las malas prácticas. Literalmente pueden decir, "lo limpiaremos más tarde" o si funciona, es suficiente.

Es posible que deba comenzar dedicando un tiempo particular para mostrar que esto es importante. Una vez que sepa que su equipo es capaz de limpiar su código (no es un hecho), puede intentar incorporarlo con más frecuencia.

Finalmente, no debería tener que establecer una hora.

Personalmente, lucho por resolver un nuevo problema y hacer que funcione mientras trato de mantener las cosas ordenadas. Estoy mejorando en eso, pero a menudo tomo un descanso deliberado y limpio las cosas. Es una mentalidad diferente para mí. Finalmente, las prácticas sólidas se convierten en hábito.

JeffO
fuente
-1

No, debes hacer esto mientras estás codificando. Esto se llama refactorización si está utilizando TDD. El problema cuando espera un mes o dos para arreglar y limpiar su código es que puede alterar el comportamiento del código porque no recuerda cada parte de su código.

Sugiero refactorizar, que se basa en codificar primero el código necesario para que algo funcione, y tan pronto como funcione, rediseñarlo, optimizarlo y hacerlo bonito.

Ricardo Mogg
fuente
Esto se denomina refactorización si está utilizando TDD o no. Esta pregunta no tiene nada que ver con TDD ...
Ben Lee