Éviter le glissement de périmètre¶
On parle de "Scope creep" lorsque la liste des problèmes résolus ou des fonctionnalités implémentées par une seule contribution s'allonge considérablement au-delà de ce qui était prévu au début du travail. Vous commencez par un simple problème ; vous découvrez un problème étroitement lié et décidez d'inclure également cette correction ; puis un troisième… avant même de vous en rendre compte, vous avez une demande d'extension qui clôt 5 problèmes et ajoute 3 nouvelles fonctionnalités, y compris des douzaines de fichiers.
Tout le monde est confronté à des problèmes d'envergure. C'est un concept qui n'est que trop familier aux développeurs chevronnés ; nous l'avons tous expérimenté à de multiples reprises et avons connu tous les problèmes qui en découlent.
Il existe des raisons très pratiques d'éviter l'élargissement du champ d'application. Plus une contribution est importante, plus il est difficile de travailler avec elle. Il devient plus difficile d'identifier les exceptions ou les problèmes potentiels, ce qui signifie que la qualité globale de la contribution peut être diminuée. Les révisions deviennent également plus difficiles lorsque l'examinateur doit traiter de multiples contextes, potentiellement sans rapport entre eux. Une contribution plus importante signifie plus de commentaires de révision, et en tant que contributeur, il peut devenir difficile de suivre plusieurs fils de révision. Même votre expérience GitHub en souffrira - l'interface utilisateur de GitHub ralentira au fur et à mesure que la taille d'un PR augmentera, ce qui signifie qu'il sera de plus en plus difficile de naviguer dans les fichiers à travers l'interface GitHub et de tenter de laisser des commentaires de révision.
Chaque fois que vous trouvez une raison d'ajouter quelque chose à votre contribution qui ne fait pas explicitement partie de la proposition originale ou du rapport de bogue, vous devez vous demander si vous ne vous dirigez pas vers un élargissement du champ d'application. Existe-t-il deux fonctionnalités distinctes qui pourraient être mises en œuvre séparément ? Une fonctionnalité peut-elle être implémentée avec une limitation ou un bogue connu, et ce bogue corrigé dans une demande de suivi ? Une partie de la correction d'un bogue est-elle indépendante d'une autre ? Si une partie d'un changement peut être laissée de côté sans altérer la contribution originale, elle devrait probablement l'être.
Le développement d'un logiciel est toujours un processus d'amélioration progressive. Chaque contribution individuelle doit laisser la base de code dans un meilleur état après avoir été fusionnée, mais il est tout à fait acceptable de laisser des bogues ou des parties de fonctionnalités comme travail pour une amélioration future. Cela peut signifier diviser une demande d'extraction en plusieurs parties qui peuvent être examinées indépendamment, ou enregistrer un problème afin que quelqu'un d'autre puisse l'examiner et le résoudre.
Limiter la portée de chaque contribution est bénéfique pour toutes les personnes impliquées, y compris vous. Vos évaluateurs, et vous-même, l'apprécierez.