Evitar la ampliación del alcance¶
El "Scope creep" se produce cuando la lista de problemas resueltos o prestaciones implementadas por una única contribución crece significativamente más allá de lo que se pretendía cuando se inició el trabajo. Empiezas con una simple incidencia; descubres un problema relacionado estrechamente, y decides incluir esa reparación; luego una tercera… antes de que te des cuenta, tienes una solicitud de extracción que cierra 5 incidencias y añade 3 prestaciones nuevas, incluyendo docenas de archivos.
El desvío del alcance le ocurre a todo el mundo. Es un concepto demasiado familiar para los desarrolladores experimentados; todos lo hemos hecho varias veces y hemos sufrido las incidencias que conlleva.
Hay razones muy prácticas para evitar la ampliación del ámbito de aplicación. Cuanto mayor sea una contribución, más difícil será trabajar con ella. Se hace más difícil identificar los casos extremos o los problemas potenciales, lo que significa que la calidad general de la contribución puede disminuir. Las revisiones también se vuelven más difíciles cuando el revisor tiene que tratar con múltiples contextos potencialmente no relacionados. Una contribución más grande significa más comentarios de revisión, y como contribuyente, puede llegar a ser difícil seguir múltiples hilos de revisión. Incluso tu experiencia en GitHub se verá afectada: la interfaz de usuario de GitHub se ralentizará a medida que aumente el tamaño de un PR, lo que significa que navegar por los archivos a través de la interfaz de GitHub e intentar dejar comentarios de revisión será cada vez más difícil.
Cada vez que encuentres una razón para añadir algo a tu contribución que no forme parte explícita de la propuesta original o del informe de errores, deberías plantearte si estás entrando en un proceso de ampliación del alcance. ¿Pudo implementarse dos prestaciones distintas por separado? ¿Podría implementarse una prestación con una limitación o defecto conocidos, y arreglar ese defecto en una solicitud de extracción posterior? ¿Una parte de la corrección de un defecto es independiente de otra? Si parte de un cambio puede omitirse sin alterar la contribución original, probablemente debería hacerse.
El desarrollo de software es siempre un proceso de mejora incremental. Cada contribución individual dejaría la base de código en un mejor estado como resultado de ser fusionado, pero es totalmente aceptable dejar fallos o partes de prestaciones como trabajo para futuras mejoras. Eso puede significar separar una solicitud de extracción en varias partes que puedan revisarse de forma independiente, o realizar una bitácora de incidencia tal que otra persona pueda investigarlo y resolver el problema.
Limitar el alcance de cada contribución ayuda a todos los implicados, incluido usted. Tus revisores, e incluso tú mismo, lo agradecerán.