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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    juin 2016
    Messages
    2 733
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 2 733
    Points : 59 092
    Points
    59 092
    Par défaut 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.

    Nom : UnitTestMethod.jpg
Affichages : 32489
Taille : 34,5 Ko

    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
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    8 112
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 8 112
    Points : 19 665
    Points
    19 665
    Par défaut
    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.

  3. #3
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    7 009
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 7 009
    Points : 32 393
    Points
    32 393
    Billets dans le blog
    4
    Par défaut
    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.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  4. #4
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    décembre 2014
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : décembre 2014
    Messages : 14
    Points : 80
    Points
    80
    Par défaut
    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

  5. #5
    Membre expert
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    octobre 2019
    Messages
    882
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2019
    Messages : 882
    Points : 3 750
    Points
    3 750
    Par défaut
    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

  6. #6
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2017
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2017
    Messages : 3
    Points : 11
    Points
    11
    Par défaut
    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

  7. #7
    Membre expert
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    octobre 2019
    Messages
    882
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2019
    Messages : 882
    Points : 3 750
    Points
    3 750
    Par défaut
    Citation Envoyé par mattf06 Voir le message
    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.
    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
    Non, je suis sur un gros projet avec plusieurs équipes en safe agile, on doit etre une bonne 100aines de développeur en tous répartie dans des équipes < 10.
    En 1 journée je code des tonnes de chose dans mon coins que j'interphase au framework, de manière totalement transparente pour les autres équipes et dev. Mon travail impacte rarement celui des autres car tous est bien décomposé.
    Je fait pas du JV donc peut etre que c'est un autre monde qui bosse différemment et on a pas l'architecture la plus performante du monde, c'est pas le but recherché.

    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.
    Un module pouvant etre: un vue caméra, une map, un moteur physique, un moteur audio, une ia, une ihm, des assets...
    Si on arrive a faire suffisamment d'abstraction dans un jeu, un moteur 3D peut parfaitement utiliser plusieurs moteurs physiques ou audio par exemple.

  8. #8
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 763
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 763
    Points : 31 784
    Points
    31 784
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #9
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2006
    Messages : 436
    Points : 962
    Points
    962
    Par défaut
    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.
    "S'adapter, c'est vaincre" - Cellendhyll de Cortavar

  10. #10
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    août 2003
    Messages
    6 641
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 6 641
    Points : 19 932
    Points
    19 932
    Par défaut
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  11. #11
    Membre émérite
    Profil pro
    Inscrit en
    juin 2009
    Messages
    691
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 691
    Points : 2 278
    Points
    2 278
    Par défaut
    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.

  12. #12
    Membre régulier
    Profil pro
    Inscrit en
    février 2009
    Messages
    153
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2009
    Messages : 153
    Points : 106
    Points
    106
    Par défaut
    1. {
    2. echo "lol";
    3. }

  13. #13
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 926
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 8 926
    Points : 17 312
    Points
    17 312
    Par défaut
    Citation Envoyé par walfrat Voir le message
    Il est où le problème alors ?
    2 paragraphes plus loin :
    « 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.
    Le type trouve que le banc d'essai c'est génial, ça fait gagner énormément de temps, mais il y a encore des gens qui ne l'utilisent pas.
    Keith Flint 1969 - 2019

  14. #14
    Membre averti
    Avatar de VBurel
    Profil pro
    Développeur Indépendant
    Inscrit en
    août 2004
    Messages
    111
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Indépendant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2004
    Messages : 111
    Points : 309
    Points
    309
    Billets dans le blog
    1
    Par défaut 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 ! :-)

Discussions similaires

  1. Réponses: 5
    Dernier message: 14/09/2018, 16h23
  2. [XL-2010] Selection d'une feuille entière sauf la première ligne
    Par backx3 dans le forum Macros et VBA Excel
    Réponses: 4
    Dernier message: 01/12/2014, 16h20
  3. [Cygwin] Faut-il une licence com pour qq pkg de devel ?
    Par ijnuhbygv dans le forum Windows
    Réponses: 2
    Dernier message: 26/07/2012, 17h44
  4. Réponses: 0
    Dernier message: 18/01/2011, 19h28
  5. Réponses: 0
    Dernier message: 18/01/2011, 19h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo