Estoy manejando 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, solo para limpiar nuestro código base?
No.
Repáralo mientras trabajas en él:
Mi opinión personal: es absolutamente necesario para el 90% de los proyectos.
Particularmente para los proyectos que están fuertemente impulsados por las ventas, usualmente hay un gran impulso para incluir nuevas características en cada lanzamiento, y inevitablemente terminas teniendo que comprometer tus mejores instintos e introducir algunos kludges / hacks aquí y allá.
Eventualmente, ha acumulado suficiente "deuda técnica" a través de estos pequeños compromisos que termina gastando una buena cantidad de tiempo resolviendo 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:
Por lo general, trato de reservar tiempo para un ciclo de corrección de errores / corrección de errores puros cada 3 a 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; normalmente puede (pero no siempre) escalonar un poco a los equipos, por lo que solo un equipo está trabajando en la limpieza en un momento dado.
Tengo a mis desarrolladores ordenando su código antes de registrarme (Subversion) o fusionándome con la rama de desarrollo principal (Git).
Les pido que hagan lo siguiente:
Para los proyectos más grandes, el código se revisa formalmente antes de fusionarse de la rama de desarrollo a la rama principal.
Creo que "dedicar tiempo" significará que es algo que se puede diferir o postergar debido a la cantidad de trabajo involucrado. Al hacer que los desarrolladores lo hagan de forma automática (lo que equivale a una solicitud / problema de cambio en JIRA) es mucho más manejable.
No en mi opinión. Si deja pasar demasiado tiempo cuando se encuentra con una deuda tecnológica y cuando la arregla, pierde el contexto de cuál es el problema. Lleva más tiempo arreglarlo, y tiende a arreglarse peor. Lo más importante es que la gente deja 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 creamos algo en el sprint anterior. Mantiene la deuda fresca en la mente de las personas. Limita la cantidad de código que usa el código de problema para que la refactorización sea más fácil. Evita que la deuda técnica se acumule. Y ayuda a empujar a los desarrolladores simplemente por abofetear algo, porque voy a hacer que lo hagan bien en el próximo sprint (así que, en primer lugar, podría hacerlo bien).
Definitivamente diría que sí, con una condición: debe hacerse a menudo, preferiblemente semanalmente. Creo que una revisión regular programada del código junto con la acción real sobre los elementos que salen de la revisión del código se amortiza muy rápidamente. Vea la respuesta de p.s.w.g.
1 semana cada 2 meses definitivamente no es suficiente. Esto habla de la mayoría de las otras respuestas que respondieron con 'No' a su pregunta. Lo esencial de la mayoría de estas respuestas es que si esperas demasiado tiempo ya no estarás en contacto con el código y, por lo general, demora mucho más en arreglarlo / limpiarlo / refactorizarlo.
No está tan claro si te referías a un ejercicio de limpieza de código adicional de vez en cuando. En ese sentido, sí. Cualquiera que sea la práctica que seguimos, siempre se produce alguna degradación.
No debe usar eso como excusa para no hacer lo correcto [Aplicar los principios de SOLID, las pruebas de unidades relevantes, las inspecciones, etc.] en primer lugar.
Creo que las dos respuestas actuales de "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 asumir que todos los desarrolladores del grupo son lo suficientemente disciplinados como para escribir código limpio y fácil de leer; Y está el tema de la presión externa y las metodologías de estilo ágil. Además, incluso con los mejores esfuerzos de la gente, sus diferencias de estilo significarán que pueden escribir código que se considerará limpio cuando esté separado, pero impuro cuando se lo considera junto con otras personas (sin mencionar las interfaces chirriantes).
Por otra parte, 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" por
Ahora, si el equipo del OP adopta lo anterior, y si él alienta a sus subordinados, por ejemplo. durante las revisiones de códigos y durante las sesiones periódicas de limpieza de códigos: para tratar de anticipar las fallas y evitar la fealdad por adelantado, con el tiempo se espera que ellos / ellas necesiten menos tiempo de limpieza. (Y luego podrían dedicar ese tiempo a la documentación, refactorización más profunda e intercambio de conocimientos de lo que han escrito y consolidado).
Creo que programar el horario regular es muy bueno, ya sea que se trate de una tarea en un proyecto de estilo de cascada regular, o de historias en un proyecto ágil. Tener un tiempo establecido puede no ser tan valioso como simplemente incluirlo en su agenda. Esto le permite hacerlo como parte del programa en lugar de cancelar el día de limpieza porque está atrasado en el proyecto.
Después de haber gestionado un proyecto que tenía una enorme cantidad de deuda de código, trabajar en forma regular fue clave para que las cosas funcionen sin problemas. Algunas de nuestras cosas eran grandes, otras eran pequeñas.
Después de unos meses de este tipo de trabajo, el jefe de nuestro equipo de operaciones me dijo cómo funcionaba todo.
Es posible que cada elemento no parezca mucho, pero al igual que todas las deudas, se eleva.
La respuesta ideal es No, porque toma los pasos necesarios para evitar que esto sea una necesidad (limpie a medida que avanza por varias razones ya indicadas).
Este puede ser el objetivo al final, pero es posible que tengas 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 malas prácticas. Pueden decir literalmente, "lo limpiaremos más tarde" o si funciona, eso es lo suficientemente bueno.
Es posible que deba comenzar dedicando un tiempo determinado para demostrar que esto es importante. Una vez que sepa que su equipo es capaz de limpiar su código (no es un dato), puede intentar incorporarlo con más frecuencia.
Eventualmente, no deberías tener que establecer una hora.
Personalmente, me cuesta resolver un problema nuevo y hacer que funcione mientras trato de mantener las cosas ordenadas. Estoy mejorando en eso, pero a menudo tomo un descanso deliberado y limpia las cosas. Es una mentalidad diferente para mí. Eventualmente, las prácticas sólidas se convierten en hábito.
No, debes hacer esto mientras estás codificando. Esto se llama refactorización si está utilizando TDD. El problema cuando esperas uno o dos meses para arreglar y limpiar tu código es que puedes alterar el comportamiento del código porque no recuerdas cada parte de tu código.
Sugiero refactorizar, que se basa en codificar primero el código necesario para hacer que algo funcione y, tan pronto como funciona, rediseñarlo, optimizarlo y hacerlo bonito.
Lea otras preguntas en las etiquetas project-management refactoring programming-practices maintenance