1 pièce(s) jointe(s)
Chez Electronic Arts, il faut parfois une journée entière pour modifier trois lignes de code
Chez Electronic Arts, il faut parfois une journée entière pour modifier trois lignes de code
selon un ancien employé de l'éditeur du jeu FIFA
Pendant le développement d'une application, utilisez-vous des outils de débogage qui facilitent le test d'un changement ? Écrivez-vous des tests unitaires ? Adam Berg, un développeur C++ et ancien employé d'EA (Electronic Arts), estime qu'il s'agit de deux éléments importants qui permettent de respecter, voire de réduire le temps de développement des logiciels. Il a confié que, lors de son passage chez EA, il a travaillé dans une équipe qui n'a sans doute pas reçu le mémo sur les outils de débogage et les tests unitaires. Résultat, il faudrait parfois une journée entière pour changer 3 lignes de code et savoir que cela fonctionnait correctement.
Certaines équipes de développeurs d'EA seraient relativement lentes
Dans le développement logiciel Agile, une itération est un cycle de développement unique. Une itération peut également être définie comme le temps écoulé entre les sessions de planification d'une itération. Bien que l'adjectif itératif puisse être utilisé pour décrire tout processus répétitif, il est souvent appliqué à tout processus de planification et de développement heuristique où un résultat souhaité, comme une application logicielle, est créé en petites sections. Ces sections sont des itérations. Chaque itération est examinée et critiquée par l'équipe logicielle et les utilisateurs finaux potentiels.
Ainsi, dans un billet de blogue racontant son expérience au sein de quelques équipes du jeu FIFA, Adam a défini le temps d'itération comme le temps nécessaire pour qu'un changement dans le code fonctionne comme prévu. Dans ces équipes, Adam a travaillé sur les versions Wii, PS Vita et Nintendo 3DS du jeu et a rapporté que la première équipe dans laquelle il a travaillé était très lente à progresser. « J'ai souvent travaillé dans le domaine de la logique de compétition. Tester des changements dans ce domaine pouvait signifier progresser pendant plusieurs saisons en mode carrière afin de tester un changement », a-t-il écrit. Mais ce n'est pas tout.
Il a ajouté : « sans blague, il fallait une journée entière pour changer 3 lignes de code et savoir que cela fonctionnait correctement ». En effet, Adam a expliqué qu'avec l'équipe, la compilation d'une seule ligne de code peut prendre facilement plus de 10 secondes. Et en tant que développeur C++ relativement nouveau à l'époque, il a confié que le nombre d'erreurs de syntaxe qu'il faisait était élevé. « Chaque fois que j'apportais une modification au code, j'étais soumis à 15 secondes d'attente pour voir ce que j'avais fait de mal », a-t-il déclaré. Mais encore, la compilation n'était que la première étape.
Selon lui, il fallait maintenant regrouper l'application et la déployer sur la console avec laquelle il travaillait, ce qui peut prendre jusqu'à trente secondes. Maintenant, il doit démarrer le jeu, naviguer jusqu'à la zone de jeu spécifique sur laquelle il travaille, et enfin, il pourrait être en mesure de voir le changement qu'il a fait. Plus tard, Adam a quitté cette équipe et a travaillé dans une autre équipe d'EA qui se concentrait sur les consoles récentes. Cette équipe utilisait des "bancs de test" (testbeds). Il s'agit de paquets réduits qui tentent de réduire le temps d'itération en se concentrant sur une zone de code particulière.
Cela signifie qu'il était en mesure de tester de plus petits morceaux de code sans avoir à passer par plusieurs heures de jeu. Adam a déclaré qu'une fois qu'il a trouvé le banc de test du mode "Carrière", il n'a pratiquement plus jamais utilisé le jeu. Selon lui, ce banc d'essai se construisait en quelques secondes et comportait toutes sortes de fonctionnalités de débogage. Tout fonctionnait sur le PC, ce qui rendait les choses encore plus rapides. Lorsqu'il a découvert les bancs de test, Adam a déclaré qu'il était excité, cependant, beaucoup de membres de son équipe ne s'en souciaient pas du tout. Adam poursuit :
« J'étais excité ! Mais j'ai observé les personnes autour de moi et il était clair pour moi que beaucoup ne savaient pas comment utiliser cet outil. Ils préféraient suivre l'ancienne méthode qui consistait à démarrer le jeu complet et à naviguer manuellement dans l'interface utilisateur pour se rendre là où ils devaient se trouver pour tester un changement. Je suis rapidement devenu un champion du banc de test et j'ai souvent ajouté de nouvelles fonctionnalités qui ont facilité le développement de nouvelles choses ». Il a déclaré que ce banc de test a sauvé sa santé mentale.
Les tests unitaires sont-ils indispensables pour les équipes ?
« Il m'a également permis de corriger les problèmes réels à un rythme raisonnable (selon mes critères) », a écrit Adam. Une fois de plus, Adam a quitté cette équipe et a rejoint une troisième équipe qui utilisait les "tests unitaires", et qui se concentrait sur des zones encore plus petites du code. Tout ceci semble indiquer qu'il existe des silos chez EA où la méthodologie de développement peut être radicalement différente d'une équipe à l'autre. Selon le développeur, le paquet de tests ne contient essentiellement que le code de la zone spécifique du jeu sur laquelle son équipe travaille.
Rappelons qu'un test unitaire est une façon de tester une unité - le plus petit morceau de code qui peut être logiquement isolé dans un système. Dans la plupart des langages de programmation, il s'agit d'une fonction, d'une sous-routine, d'une méthode ou d'une propriété. La partie isolée de la définition est importante. Une unité peut être presque tout ce que vous voulez : une ligne de code, une méthode ou une classe. En général, cependant, plus c'est petit, mieux c'est. Des tests plus petits vous donnent une vue beaucoup plus granulaire de la performance de votre code.
Adam a déclaré qu'une construction propre prenait environ 10 secondes et que les constructions incrémentielles après cela ont probablement pris moins d'une seconde. « Il est difficile de souligner à quel point ce seuil est important. Avec moins d'une seconde pour compiler (et exécuter) les tests, je peux désormais me concentrer en permanence sur une tâche. Les erreurs de compilation et de logique sont inévitables. Mais lorsque je peux rapidement repérer l'erreur et recompiler, cela me permet d'entrer dans un état de fluidité. Pour la première fois, j'ai commencé à prendre plaisir à écrire du code au travail », a-t-il déclaré.
Par ailleurs, l'ancien employé d'EA a ajouté qu'il est devenu beaucoup plus facile pour lui de modifier le code de quelqu'un d'autre et de savoir qu'il n'avait pas tout cassé. « L'anxiété liée à la modification du code a disparu. J'ai ensuite réécrit la logique de la compétition pour l'accélérer et ajouter des tests unitaires. Il y avait toutes sortes de cas limites qui faisaient des tests unitaires la méthode parfaite pour s'assurer que toutes les bases étaient couvertes. Lorsque j'ai finalement quitté l'entreprise, je me sentais mieux en sachant que je laissais un système qui avait ses propres contrôles en place », a-t-il déclaré.
« Les heures passées à essayer de comprendre comment quelque chose est censé fonctionner sont codifiées dans une spécification de test », a-t-il ajouté. En somme, Adam a déclaré qu'il a partagé son expérience pour vous rappeler de "bien réfléchir" à votre processus de développement actuel tout en vous posant les questions suivantes : « y a-t-il un élément de votre pipeline qui prend plus de temps qu'il en faut ? Y a-t-il un moyen de créer des outils de débogage pour faciliter le test d'un changement ? Les tests unitaires apporteraient-ils des avantages, mais vous continuez à les éviter parce que vous pensez qu'ils représentent un coût initial important ? ».
Source : Adam Berg
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous de la conduite des différentes équipes d'EA ?
:fleche: Quel est votre avis sur les bancs de test et les tests unitaires ? En quoi les jugez-vous importants ?
:fleche: Utilisez-vous les bancs de test et les tests unitaires ? Pensez-vous que les équipes de développement peuvent s'en passer ?
Voir aussi
:fleche: « Agile est un cancer », pour Erik Meijer qui estime qu'il doit être banni une fois pour toutes
:fleche: Agile : entre Scrum et Kanban, laquelle des deux méthodologies est-elle la meilleure ? Le point dans une étude comparative
:fleche: La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas, selon Gene Bond, directeur exécutif chez iiSM.ORG
:fleche: Agile pourrait-il conduire les organisations vers une dette technique plus importante ? Oui, selon Don Clos, développeur logiciel, qui propose une analyse détaillée de la situation
:fleche: Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile
code source et méthodologie
JE dirais même plus! Parfois il faut une journée pour déterminer quelle ligne de code il faut changer.
ca dépend de la taille du projet et de comment les sources et leur architecture sont présents dans l'esprit du développeur.
Si vous pouvez utiliser un banc de test ou un test unitaire ou un stress test pour valider votre modification ou nouvelle fonction, c'est facile et clair, la problématique du développement ne se situe pas du tout ici.
La problématique apparait quand on doit modifier ou ajouter une fonction qui fait partie du workflow utilisateur souvent et qui est soumis à de multiples dépendances et contraintes (temps réel, multithread, machine d’état etc…).
Là c’est parfois très compliqué de modifier qqc, parce que bien souvent il faut faire un audit sur les dépendances et les risques de régressions. Parfois même il faut faire une étude de faisabilité. On peut travailler une semaine sur l’ajout d’une nouvelle fonctionnalité pour s’apercevoir enfin qu’elle ne pourra pas être opérationnelle dans le contexte courant, parce qu’il manque des éléments, parce que l’architecture n’est pas faite pour ca, parce que cela entraine l’ajout d’une cascade de fonctionnalités et changements qui n’étaient pas prévu au planning…
Bref, Le meilleur moment dans le développement d’un logiciel, c’est le premier mois ! :-)
