Header Ads Widget

Ticker

6/recent/ticker-posts

El problema de revisión de código para la migración

 Cuanto mayor sea el cambio de código , más difícil será revisarlo. Entonces, ¿qué sucede cuando estamos haciendo una migración de código? Técnicamente, hay un gran conjunto de cambios para hacer que el código pase de su estado original a una nueva forma. ¿Cómo lo gestionamos?

¿Que el que?

Un par de definiciones antes de entrar en detalles aquí.

En primer lugar, repasemos la idea de revisar. Algunos equipos prefieren no hacer revisiones de código, considerando que el trabajo de una mafia o de un par es mejor que una revisión por pares asincrónica. Eso está bien, pero sugeriría que incluso una mafia o un par deberían tener algún mecanismo para verificar sus cambios antes de la confirmación final. No me refiero solo a la automatización de pruebas, que también deberían tener, me refiero a leer las diferencias para asegurarse de que no haya sorpresas.

La revisión por pares es, de alguna manera, menos poderosa que revisar algo usted mismo. Mi preferencia es revisar algo yo mismo, sabiendo que alguien más lo estará mirando. El hecho de que sea revisado por otra persona me hace ver mi propio código de manera diferente en la etapa de revisión de diferencias. Reviso mis propias diferencias incluso en proyectos en solitario.

La segunda definición es una migración de código. Supongamos que a veces hay un proyecto que se hizo en una versión diferente de la tecnología que usamos y estamos a punto de actualizarlo a la última versión. Supongamos que aquí no hay medias tintas; estamos levantando y cambiando de alguna forma o forma, y ​​la construcción anterior no puede evolucionar suavemente hacia el nuevo mundo.

Evitar una revisión de migración enorme

Dependiendo del tipo de migración , tenemos algunas opciones sobre cómo hacer que nuestros cambios sean revisables. La consideración clave es si una persona podría entender fácilmente la revisión. Esto significa que:

  • Una pequeña cantidad de cambio, que puede ser bastante profundo.
  • Solo cambios triviales, que son fáciles de entender sin mucha lectura
  • Adicional de repetitivo, que puede ser extenso, pero puede tratarse como un bloque repetitivo, evitando así el problema de la revisión inicial

Aquí algunas ideas de migración de código, optimizadas para la revisión:

  • Ignore la capacidad de construcción y realice una serie de pequeños cambios en el código en su conjunto hasta que cumpla con el nuevo estándar: cada pequeño cambio tiene como objetivo una mejora / corrección para el nuevo mundo
  • Construya el nuevo proyecto desde cero e importe el código antiguo una pieza a la vez, arreglando sobre la marcha
  • Realice una migración híbrida en la que el código antiguo se importe como una biblioteca a la nueva plataforma de alguna manera, y luego se pase a través de un módulo a la vez con cambios menores

Victorias incrementales

Para reducir el riesgo, aumentar el trabajo en equipo y facilitar la comprensión, trabajar en lotes pequeños es siempre el mejor objetivo.

Podemos perdonarnos a nosotros mismos un lote que tiene muchos cambios de línea que son, esencialmente, los mismos.

Sin embargo, fundamentalmente, el desafío de cualquier gran migración de código es averiguar cómo dividirlo en incrementos para que se pueda administrar fácilmente y comprender en cada paso del camino.

Publicar un comentario

0 Comentarios