Les revues de code fonctionnent-elles vraiment en véritable Agile?

J'ai donc commencé à travailler pour un grand corp., L'un de ceux avec 3 lettres dans le nom, et ils essaient de devenir Agile, mais ont des tonnes de processus, que je ne pense pas être Agile.

Celui qui m'a le plus enroulé sont les revues de code. Mon dernier emploi était avec une startup qui, je dirais, est l'équipe de développement la plus agile que j'ai vue, sur laquelle et / ou jamais entendu parler.

Quoi qu'il en soit, mon argument est que les revues de code sont une perte de temps dans le développement itératif ou Agile où l'UX / UI est extrême / intense (pensez à la perfection Apple / Steve Jobs). Peut-être que quelqu'un ici peut aider à comprendre avant de me virer?

Voici mon processus de développement et celui de ma dernière startup ... très Agile.

Nous effectuons les premières fonctionnalités pour trier les tâches / tâches de développement. Nous simulerions quelques versions et les présenterions aux utilisateurs, à l'équipe et au marketing pour obtenir des commentaires. Nous faisons ensuite une autre itération de maquette pour obtenir un tour des mêmes intervenants ci-dessus. Ensuite, nous divisons le travail et commençons. Nous avons des jalons et des dates à respecter, mais nous continuons de brancher. Nous n'avons aucun examen de code pendant tout cela. Plusieurs fois au cours des semaines de notre développement, nous tenons à nouveau des sessions avec les parties prenantes pour voir si elles conviennent toujours que les fonctionnalités / fonctions / UX / UI sont toujours adaptées et conformes à l'objectif.

À l'approche de la fin du cycle d'itération de 8 semaines, le contrôle qualité commence les tests, puis il passe aux utilisateurs alpha et enfin aux utilisateurs bêta. Mais pendant l'alpha et la bêta, les développeurs passent en revue les nouvelles fonctionnalités et les anciennes fonctionnalités en apportant des changements itératifs quotidiens ou horaires à l'interface utilisateur pour améliorer l'expérience utilisateur. Une fonctionnalité en cours de développement dans cette version pourrait donc être modifiée 3 fois de plus au cours des quatre dernières semaines pour l'améliorer et la perfectionner ou ajouter quelques petites fonctionnalités (par exemple, rendre le composant un peu plus lisse ou plus intelligent). Parfois, les changements peuvent être superficiels, ce qui signifie qu'aucune opération CRUD n'est changée ou modifiée, mais toutes les modifications de l'interface utilisateur uniquement.

Donc, avec ce type de processus de développement, extrême Agile, les revues de code ne seraient-elles pas une perte de temps? Ce qui signifie que si un autre développeur ou deux examinaient mon code, mais que ce code change encore 3 fois avant de sortir, à cause de toutes les améliorations UI / UX, ne perdons-nous pas notre temps les 3 premières fois, ils l'ont examiné code comme ce code / composant / UI a été mis au rebut?

Nous n'avons jamais eu beaucoup de problèmes de qualité avec ce processus et oui si un développeur quittait toutes les connaissances, mais nous avons toujours trouvé des développeurs intelligents pour les récupérer et les reprendre.

Et oui, nous avons beaucoup de testeurs car ils peuvent avoir à retester les choses 3 ou 4 fois. Aussi, s'il vous plaît, ne vous attardez pas à demander pourquoi tous les changements UI / UX ... c'est juste comment les choses se font ... été alors c'est pourquoi l'application gagne des tonnes de prix pour UI / UX et les utilisateurs tueront pour le app. Le processus de réflexion est de savoir si je peux améliorer encore quelque chose de 2% parce que j'ai une heure supplémentaire, alors faites-le. Les utilisateurs seront plus heureux, ce qui signifie plus de $ ou d'utilisateurs. Et oui, nos utilisateurs sont d'accord avec le fait que l'application change continuellement parce que c'est ainsi que cela a été fait depuis le premier jour, donc ils ne la voient pas comme mauvaise ou négative.

J'espère que ce message ne sera pas aussi pompeux, mais je ne vois pas comment les critiques de code ne sont pas du gaspillage. Peut-être que 2% de tout notre code dans le code examiné contient des bogues. Chaque version, nous pourrions trouver 3 bogues via la révision du code. Donc, cela finit par être 40 heures de révision de code par développeur et par version (4 x 40 = 160 heures) pour trouver 3 à 5 bogues? Les chances sont de 50% que ces 3 à 5 bogues auraient été détectés par le QA de toute façon. Ne serait-il pas préférable de consacrer ces 40 heures par développeur à ajouter une nouvelle fonctionnalité ou à améliorer celles existantes?

Il y a quelques choses que les revues de code peuvent faire pour vous, et certaines choses qu'elles ne peuvent pas. Les arguments en faveur des revues de code:

• Propriété collective
• Trouver des bugs (QC)
• Appliquer un style cohérent (QA)
• Le mentorat

De nombreux processus agiles les abordent de différentes manières:

• Propriété collective: tous les membres de l'équipe sont responsables du projet, ce qui signifie que tout le monde sera attentif au code à tout moment.
• Gratuit pour refactoriser: cela fait passer les revues de code au niveau supérieur et permet à tout membre de l'équipe d'effectuer une refactoring si nécessaire.
• Tests unitaires (QC): les tests unitaires sont plus efficaces et moins sujets aux erreurs humaines qu'à l'inspection visuelle. En fait, je n'ai pas encore trouvé de moyen plus efficace.
• Programmation en binôme (AQ): s'occupe du mentorat et fournit des conseils de refactorisation précoce lors de l'écriture du code. C'est également un sujet controversé, mais je trouve que cela aide tout en accélérant un nouveau développeur. C'est aussi le bon moment pour appliquer les normes de codage.

Essentiellement, il existe d'autres moyens de prendre en compte les gains potentiels que vous auriez normalement obtenus lors de l'examen par les pairs. Mon expérience personnelle avec les évaluations par les pairs est qu'ils sont des mécanismes très inefficaces et ne sont pas efficaces pour trouver des bogues ou des défauts de conception plus importants. Cependant, ils ont leur place dans certaines équipes, et sur les projets où l'agilité n'est pas réalisable (pour une raison quelconque), ils sont tout à fait nécessaires.

Les revues de code sont-elles uniquement destinées à trouver des bogues? Vous semblez penser que c'est vrai et moi non.

Je dirais que les révisions de code peuvent concerner davantage la propriété collective du code, garantir que les connaissances sont dans plusieurs têtes et préparer les autres à hériter du code, ce qui pourrait être pour de nouvelles fonctionnalités ainsi que pour des bogues. J'aime les révisions de code comme un moyen d'avoir un peu de contrôle et d'équilibre dans le système, car on ne sait jamais quand quelqu'un peut avoir une idée de l'endroit où quelque chose peut être réécrit pour maintenir les conventions.

La programmation par paires est la réponse XP aux revues de code. Essentiellement, chaque ligne de code est revue au fur et à mesure de son écriture. Ce sont des revues de code poussées à l'extrême.

Les révisions et les tests de code n'attrapent souvent pas les mêmes types de bogues, et les bogues détectés par la révision de code sont probablement plus faciles à corriger, car l'emplacement du bogue est connu.

Vous ne pouvez pas savoir si le code est exempt de bogues simplement parce qu'il passe les tests sans qu'aucun enregistrement ne soit enregistré. "Les tests ne peuvent que prouver la présence de bugs, pas son absence." (Dijkstra?)

La révision du code conserve également le style de code et est capable de trouver des endroits où le code n'est pas bon mais qui fonctionne pour l'instant. Il réduit les coûts de maintenance sur la route.

De plus, les exigences d'une grande entreprise et d'une startup sont différentes. Les startups échouent normalement et doivent se déplacer rapidement. Les grandes entreprises tirent beaucoup plus de valeur de faire les choses correctement plutôt que le plus rapidement possible. Vous préférez peut-être travailler dans des startups que dans de grandes entreprises, mais ce n'est pas une raison pour essayer d'imposer des stratégies de démarrage là où elles ne correspondent pas.

Vos révisions de code n'indiquent-elles que des modifications d'interface utilisateur / UX? Je dirais que ce n'est pas une révision de code, c'est un test d'utilisabilité. Les révisions de code concernent beaucoup plus la révélation des problèmes que les utilisateurs / testeurs / entreprises / quoi que ce soit ne voient jamais, car ils sont dans le code. L'indice est juste là dans le nom.

Maintenant, je conviens avec vous qu'il y a une ligne à tracer quelque part. Examinez-vous 4 itérations du même changement d'interface utilisateur? Ou passez-vous par 4 itérations de cela, chacune rendant potentiellement le code moins maintenable? Je dirais essayer de mesurer les deux approches et trouver le bon équilibre pour votre équipe, mais n'abandonnez pas complètement les revues de code.

Même si une revue de code ne pose jamais de problème, elle présente un avantage que vous remarquez rarement tant qu'elle n'est pas là: chaque morceau de code est examiné par deux développeurs, de sorte que deux développeurs savent ce qu'était le changement et ce qu'il était censé réaliser . Donc, l'un d'eux tombe malade le lendemain et est absent pendant une semaine, l'autre peut reprendre tout travail urgent qu'il faisait.

J'ai tendance à convenir que la propriété collective de code et l'appariement avec TDD et CI sont les antidotes agiles aux sessions formelles de révision de code.

Même sous UP / Spiral, je n'étais pas un grand fan d'une étape spécifique du processus étant la «révision du code» car il me semble que les types de problèmes qu'il est susceptible de trouver se trouvent plus tard qu'ils ne pourraient l'être si la même énergie était plutôt investie dans une certaine avance collaboration et une automatisation simple.

J'ai ressenti cela parce qu'il y avait: - un examen partagé de la conception (généralement exprimé en UML au moins sur un tableau blanc) signifiait des problèmes de conception à grande échelle ou une mauvaise utilisation des API, etc. - FxCop, CheckStyle, FindBugs (ou similaire) fonctionnant avec des builds d'intégration continue automatisés pour saisir le nom, le style, la visibilité, la duplication de code, etc.

Nous avons pu échouer plus tôt et obtenir des commentaires plus rapidement qu'une habitude de révision de code en aval ne l'aurait produit.

Je ne dis pas que c'est une perte de temps de s'asseoir et de jeter un coup d'œil à votre base de code de temps en temps, mais faire de la révision du code une étape décisive pour appeler quelque chose de fait semble créer beaucoup de travail en cours qui aurait pu être évité avec une meilleure inspection / collaboration en amont.

L'un des principaux objectifs que j'attends des revues de code est d'augmenter la facilité de maintenance du code. Les révisions de code devraient aider tout le monde à écrire un code clair raisonnablement conforme aux bonnes normes de codage. La plupart des codes nécessitent beaucoup de maintenance, en particulier dans les grandes entreprises. La récupération du code maintenable doit commencer avant la publication du code et se poursuivre ensuite.

Les révisions de code en elles-mêmes ne devraient jamais entraîner de modifications de code. Si l'examen du code indique que des modifications sont nécessaires, la mise en œuvre de la modification entraînera une modification du code.

L'état du code peut changer à la suite de la révision, mais cela ne devrait généralement pas être pertinent pour les problèmes que vous mentionnez.

Si la révision du code entraîne plusieurs modifications de code, quelque chose est cassé dans votre processus de développement. Compte tenu du nombre de testeurs que vous avez, il peut être jeté par-dessus le mur et laissez les testeurs trouver la mentalité du problème.

Les choses devraient aller aux testeurs à l'état terminé. Autant de tests que possible devraient être automatisés, afin que les testeurs ne retestent pas la même chose à chaque fois.

L'interface utilisateur / UX nécessite un certain temps de test, mais le fait d'avoir des experts en conception / développement sur le front-end devrait réduire cela. Il nécessite également un visage devant l'écran. Cependant, dans toutes les applications avec lesquelles j'ai travaillé, il s'agissait d'une portion relativement petite du code.

Le coût de mise en œuvre des modifications (y compris les corrections de bogues) augmente généralement pour chaque étape qu'il traverse. Trouver des bogues en développement est généralement moins cher que de les corriger après les avoir trouvés.