Mejores prácticas para renombrar, refactorizar y romper cambios con equipos

¿Cuáles son algunas de las mejores prácticas para refactorizar y renombrar en entornos de equipo? Traigo esto con algunos escenarios en mente:

1. Si una biblioteca a la que se hace referencia comúnmente se refactoriza para introducir un cambio importante en cualquier biblioteca o proyecto que haga referencia a ella. Por ejemplo, cambiar arbitrariamente el nombre de un método.

2. Si los proyectos cambian de nombre y las soluciones deben reconstruirse con referencias actualizadas a ellos.

3. Si la estructura del proyecto se cambia para que sea "más organizada" al introducir carpetas y mover proyectos o soluciones existentes a nuevas ubicaciones.

Algunos pensamientos / preguntas adicionales:

1. ¿Los cambios como este son importantes o el dolor resultante es una indicación de que la estructura salió mal?

2. ¿Quién debería asumir la responsabilidad de corregir los errores relacionados con un cambio radical? Si un desarrollador hace un cambio importante, ¿debería ser responsable de entrar en los proyectos afectados y actualizarlos o debería alertar a otros desarrolladores y pedirles que cambien las cosas?

3. ¿Es esto algo que se puede hacer de forma programada o es algo que se debe hacer con la mayor frecuencia posible? Si una refactorización se pospone por demasiado tiempo, es cada vez más difícil conciliar, pero al mismo tiempo en un día gastando incrementos de 1 hora arreglando una construcción debido a los cambios que ocurren en otros lugares.

4. ¿Se trata de un proceso de comunicación formal o puede ser orgánico?

Cada uno de los escenarios que enumeró pertenece a la categoría de "API / código publicado". Esto es difícil de refactorizar, por lo que no se debe cambiar nada a la ligera. Por el contrario, debe negociar los cambios planificados de antemano con todas las partes involucradas. Es al menos una cuestión política tanto como técnica.

Entonces, el consejo número uno con respecto a esto de Martin Fowler es no publicar sus interfaces (nombres y estructuras de proyectos) prematuramente .

Sin embargo, si ya está hecho y necesita ser reparado, probablemente sea mejor intentar hacer los cambios necesarios en el menor número de pasos posible, para minimizar la interrupción de otras partes. Lo cual se está desviando bastante del concepto original de refactorización, pero por una buena razón.

Además, si es posible, considere agregar el nuevo método (mientras descarta el existente) en lugar de renombrar el existente. Esto garantiza que el código del cliente no se rompa y les proporciona un período de transición para que actualicen su código para cumplir con la última API. El inconveniente es que complica tu API. Aunque el estado es solo temporal, sin embargo, puede llevar un tiempo considerable antes de que pueda eliminar de forma segura los métodos API obsoletos (en el caso de la biblioteca de clases Java, años).

Casi siempre puede evitar estos problemas refactorizando en dos pasos. En el primer paso, introduzca el nuevo código y desaproveche el código anterior. Cuando todos los equipos hayan migrado al nuevo código, elimine el código anterior. También uso esta técnica para refactorizar gradualmente un solo módulo. De esta manera, puedo limitar la cantidad de código que debe cambiarse entre las ejecuciones de prueba.

Tenga en cuenta que esta es una de las razones principales para tener un servidor de compilación, que ejecuta pruebas.

Si sucede algo que rompa un programa determinado, se le informa lo más rápido posible y puede buscar al culpable y resolver los problemas mientras los detalles aún están frescos.