6 jours pour modifier une ligne de code (2015)

• L’usine est utilisée à moins de 10 %.
• La politique de l’entreprise limite la création d’un backlog de plus de 3 mois.
• Modifier la politique à 4 mois résout le problème.
• Changer la configuration d’un logiciel legacy nécessite de modifier une ligne de code.
• Le processus de mise en œuvre du changement comprend la soumission d’un ticket, le remplissage des sections requises et l’obtention de l’approbation d’un directeur.
• Le changement est urgent pour éviter des licenciements.
• Le programmeur modifie le code avec succès, mais des variables codées en dur et d’autres erreurs provoquent des problèmes.
• Le code nécessite une revue par les pairs et des tests, puis seulement peut passer en production.
• L’accès à l’environnement de test nécessaire est retardé en raison de problèmes d’autorisation et de disponibilité.
• L’enregistrement du paramètre doit être renommé et disposer d’une piste d’audit.
• Le programmeur effectue les changements nécessaires et soumet à nouveau le code pour revue.
• Les tests exigent un plan de test approprié, avec des cas de test choisis par l’utilisateur et les résultats attendus.
• Après 6 jours, le programme est approuvé pour passer en production.

[GN⁺]

Avis Hacker News

• Le principal problème est de refuser quand les reviewers demandent des modifications qui affectent d'autres parties de la base de code.
• Les pull requests ciblées et l'opposition au scope creep sont des leçons importantes.
• Le processus de code review peut être rempli de remarques tatillonnes et de commentaires mineurs.
• L'équipe sécurité peut ne pas répondre rapidement aux demandes d'autorisation.
• Le titre de l'article peut être trompeur, et il y a eu des améliorations supplémentaires pendant ces 6 jours.
• Un changement d'une seule ligne peut entraîner des conséquences inattendues.
• Le processus de code review peut devenir un rôle de gatekeeper et retarder l'avancement.
• Autoriser les commentaires sans bloquer les commits peut mener à un développement plus efficace.
• Passer d'une équipe qui pratique des code reviews formelles à une équipe qui n'en fait pas peut être rafraîchissant et donner plus d'autonomie.
• Il existe une différence entre la façon de gérer des ouvriers d'usine et des développeurs logiciels.
• Retenir des changements au nom d'un idéal d'équipe en évolution est dysfonctionnel.
• Le problème vient du processus de l'entreprise, pas de la code review elle-même.