Evitar la desviación del alcance¶
El "Scope creep" se produce cuando la lista de problemas resueltos o funcionalidades implementadas por una única contribución crece significativamente más allá de lo que se pretendía cuando se inició el trabajo. Empiezas con un simple problema, descubres otro estrechamente relacionado y decides incluir también esa solución, luego una tercera… antes de que te des cuenta, tienes un pull request que cierra 5 problemas y añade 3 nuevas funcionalidades, 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 los problemas 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. ¿Hay dos funciones distintas que podrían implementarse por separado? ¿Podría implementarse una función con una limitación o error conocidos, y arreglar ese error en un pull request posterior? ¿Una parte de la corrección de un error 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 debe dejar la base de código en un mejor estado como resultado de ser fusionado, pero es totalmente aceptable dejar errores o partes de características como trabajo para futuras mejoras. Eso puede significar dividir una solicitud de extracción en varias partes que puedan revisarse de forma independiente, o registrar un problema para que otra persona pueda investigarlo y resolverlo.
Limitar el alcance de cada contribución ayuda a todos los implicados, incluido usted. Tus revisores, e incluso tú mismo, lo agradecerán.