IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

105PARTAGES

18  0 
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 ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la conduite des différentes équipes d'EA ?
Quel est votre avis sur les bancs de test et les tests unitaires ? En quoi les jugez-vous importants ?
Utilisez-vous les bancs de test et les tests unitaires ? Pensez-vous que les équipes de développement peuvent s'en passer ?

Voir aussi

« Agile est un cancer », pour Erik Meijer qui estime qu'il doit être banni une fois pour toutes

Agile : entre Scrum et Kanban, laquelle des deux méthodologies est-elle la meilleure ? Le point dans une étude comparative

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

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

Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de natponch
Membre du Club https://www.developpez.com
Le 18/12/2021 à 2:19
Pas directement en lien avec le contenu, mais j'apprécie beaucoup ce style d'articles sur Développez.com, qui parlent vraiment de sujets de développement logiciel.
Ça change des tesla, notes de mises à jour, crypto, etc..

A bon lecteur
11  0 
Avatar de Kikuts
Membre éprouvé https://www.developpez.com
Le 19/12/2021 à 23:37
Ca ne m'étonne pas du tout.

Plus l'entreprise et le projet/l'équipe sont gros, plus un changement prend du temps.

J'ai eu la chance de bosser chez Microsoft 2 ans. Je devais toujours tester à la main et je bossais sur des projets intégrés directement à Windows donc repo énoooooorme (bonjour le git pull... )
Je devais tester sur Xbox, Windows Phone, PC (différentes taille de fenêtre, tester la compatibilité avec les thèmes custom de Windows, le mode "contraste élevé", le narrateur...)

Bref, ça prenait des plombes et à la fin de la journée, je devais avoir une moyenne de 30 lignes modifiées par jour. Le code devait être relu par 1 dev senior et 2 autres, chaque espace de trop, chaque nom de propriété/méthode était analysé à la loupe, donc pas mal d'itération (mais j'avoue ne jamais avoir vu du code aussi homogène et aussi facile à comprendre malgré quasi 0 commentaire)
Ensuite, il faut pas mal de réunion pour que tous les acteurs d'un projet s'harmonisent et que les équipes de pays différents puissent travailler ensemble.

Donc pas du tout choqué par le témoignage. Il peut s'estimer heureux d'avoir bosser sur un projet qui lui a montrer combien les tests et un environnement performant pour tester sont importants.
10  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 20/12/2021 à 9:01
Nos micro services sont rétro compatible avec la version n-1 ce qui laisse le temps aux autres équipe de mettre à jours leurs partis si besoin, meme si on fait tous les 3 mois une grosse réunion entre équipes pour parler de la nouvelle architecture global et des changements.

il est possible de développer un jeu sous forme d'un noyau core et de modules, libres aux dev d'ajouter/modifiers des modules de manières indépendante.
D'un point de vue performance le micro service c'est quand même une catastrophe. Quand dans un jeu tu as par exemple 16ms pour tout calculer et faire ton rendu ou que tu bosses sur du temps réel , "t'encombrer" d'une communication interprocess te coute déjà pas mal de temps.

Plus qu'un problème d'architecture , je vois surtout un problème de process dans ce qu'il raconte.
Peut être que ce n'est pas au dév de faire ses tests sur les consoles. Il est sans doute plus judicieux de faire une première pass rapide sur l'environnement de dév pour vérifier que ca marche globalement et faire des tests fonctionnels par des équipes dédiées sur les plateformes réelles. Ce qui permet en plus de supprimer complètement le biais du développeur qui inconsciemment peut éviter les scénario à problèmes.

L'appli sur laquelle je bosse , est déployable sur 3 OS et 6 archi CPU différentes (x64 et variantes arm) , il est évident que je ne test pas tout à chaque ligne que je modifie. On à des pipeline qui compile et tests pour chaque archi et on revient dessus si on à effectivement un problème.
7  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 17/12/2021 à 18:28
bonjour à mon sens le problème ne vient pas seulement des tests unitaires il vient aussi de l'architecture du projet.
Il arrive bien souvent que dans un projet logiciel notamment en C++ c'est tout une imbrication de classes donc pour peu que l'on veuille modifier quelque chose dans une classe en particulier, c'est tout l'édifice qui vacille
Bref c'est comme dans un jeu de mikado si on retire une aiguille maladroitement c'est tout le tas qui s'écroule.

Pour le Unreal Engine ou ne serait-ce que Irrlicht le cas se pose également.

Ce sont d'excellents outils mais pour peu que l'on veuille faire des modifications dans le code source ça devient compliqué
En tout cas merci à la modération de ce forum cette actualité m'est très instructive.
5  0 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 17/12/2021 à 19:34
Ce n'est pas une grande surprise, et oui il y a beaucoup d'améliorations possibles et la plupart des équipes et personnes en sont conscientes, mais...
- entre passer du temps sur fixer le jeu ou fixer les tests (dont on ne sait pas vraiment combien de temps ça prendra parce que peu les connaissent), les tests n'ont pas la priorité, au regret des testeurs (automatiques, pas ceux qui testent le jeu directement)
- certaines plateformes sont plus simples à utiliser que d'autres, les consoles sont typiquement moins simples qu'un PC
- la codebase évolue à chaque projet mais est rarement nettoyée entre les projets, ce qui fait que...
- les codebases/projets sont dorénavant énormes et les temps de compilation explosent par endroit parce que les personnes sont moins compétentes, ajoutent/suppriment pas des includes ou fichiers inutiles, utilisent pas ou mal les forward declaration, ...
- c'est pas facile de justifier que tu vas passer 2 semaines à faire un tel clean, surtout auprès du management, quand bien même tout le monde s'accorde à dire qu'il faut faire quelque chose et qu'une fois fait on est tous heureux de gagner quelques minutes de compile qui compensent largement quand multipliées par des centaines de personnes, de machines de build, etc
- selon l'étape du projet, on est plus ou moins regardant sur la batterie de tests pour valider un changement; on va pouvoir commit plus rapidement pendant la préprod que quand on est à quelques jours ou heures de la master candidate

Et hélas je ne pense pas que ça change réellement de sitôt. Ni que ce soit une particularité de EA.
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 18/12/2021 à 22:11
Quand j'étais gamin, les standards chez IBM, c'était 7 lignes de code par jour et par développeur. Sur un appli mature avec essentiellement de la maintenance, je ne suis pas surpris.
5  0 
Avatar de mattf06
Membre à l'essai https://www.developpez.com
Le 18/12/2021 à 10:40
Cela n'a rien d'étonnant ! Sur les gros projets avec des millions de lignes de code, la moindre modification d'un composant peu avoir des répercussions catastrophiques ! Surtout que maintenant, avec les jeux en ligne il y a tous les aspects cyber-sécurité à prendre en compte.
Un problème d'architecture ? pas forcément ! on n'architecture pas un jeu comme un serveur web, sinon bye bye les performances !
Un problème de langage ? Absolument pas ! Que ça soit du C++, Java ou C#, changer 3 lignes de code qui change le comportement d'une classe peu avoir un impact sur le reste du projet.

Toutes les grandes sociétés qui fond des gros projets ont des processus lourds et longs :
- analyse de la demande de modification : quoi faire ? impact ? etc...
- codage et test unitaire (cela implique souvent de réécrire le/les tests et d'en ajouter de nouveau et généralement cela est fait par d'autres équipes)
- revue du code pour approbation
- test d'intégration
- test de régressions
- documentation

Après j'imagine que l'ajout de ces 3 lignes de code, c'est plus que d'ajouter 3 lignes de log !!

Bref, tout ce cycle prend effectivement beaucoup, beaucoup de temps... surtout que les sociétés font très souvent appellent à du low-cost pour les tests... donc pb de time-zone, etc...

Welcome to the real life
4  0 
Avatar de VBurel
Membre actif https://www.developpez.com
Le 24/12/2021 à 8:50
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 ! :-)
4  0 
Avatar de calvaire
Membre expert https://www.developpez.com
Le 18/12/2021 à 9:22
j'ai connu une situation similaire dans une boite (c'était sur un énorme projet industriel) ou pour modifier 10 lignes de code fallait y passer des jours à tester le produit dans sa globalité (les tests automatiques étaient mal foutue et les composants du projet étaient mal séparé voir pas du tous...).

Architecte c'est un métier, désormais dans une autre boite, pour mes nouveaux projets je ne développe qu'avec des conteneurs/micro services indépendants, comme ca n'importe qui peut bosser sur de petites partie du projet globale sans impacter les autres.
Mais cela demande un bon architecte et des développeurs compétents.

pour un jeu 'est la meme chose, on peut facilement tester rapidement certains élèment de jeux sans le lancer. Pour tester à la main l'ia d'un jeu, un dev avait crée une map rapide avec des assets degeux mais qui se chargeait en moins de 10 secondes.
Parce que les tests automatique c'est important pour checker des scénarios mais rien ne remplacera un test à la main à la fin quand meme
3  0 
Avatar de walfrat
Membre chevronné https://www.developpez.com
Le 20/12/2021 à 11:21
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.
En bref les équipes qui travaillent sur des jeux plus récent ont amélioré le processus pour les développeurs.

Il est où le problème alors ? Il a une idée que ce à quoi ressemblait le développement des jeux à l'époque de la PS1 ? De la Nintendo ?

On sait tous que quand on travail sur des trucs plus ancien c'est moins bien foutus et forcément on a, généralement, pas les moyens de le remettre d’équerre avec des trucs plus récents.
2  0