D'un traducteur: aujourd'hui, nous publions un article pour vous par le testeur de gamedev expérimenté Richard Taylor. L'article sera utile à la fois aux débutants et aux développeurs expérimentés - il y a certainement quelque chose à discuter ici.
J'ai créé de nombreux jeux. Habituellement, le stade final de développement est très douloureux. Après tout, c'est à la fin que nous rencontrons des bugs, et ce n'est qu'après que nous pouvons complètement apporter de la brillance au produit. La situation s'aggrave lorsque le développeur dispose d'un minimum de temps pour terminer le projet. Vous devez travailler rapidement, et les bugs dans ce cas sont des invités fréquents. Comment puis-je les gérer? C'est très simple: faire moins d'erreurs, c'est tout (c'est l'ironie de l'auteur - note du traducteur).
Skillbox recommande: Cours pratique de deux ans "Je suis un développeur Web PRO . "
Nous vous rappelons: pour tous les lecteurs de «Habr» - une remise de 10 000 roubles lors de l'inscription à un cours Skillbox en utilisant le code promo «Habr».
Réduisez le nombre de bugs
Étant donné que tous les bogues sont dans le code, est-ce probablement juste suffisant pour demander à l'équipe de développement de faire moins d'erreurs?
Si vous êtes drôle ici, je ne serai pas surpris. Et vraiment, parce que personne (enfin, ou presque) ne les fait de son plein gré. Alors, que pouvez-vous offrir à l'équipe pour faire moins d'erreurs dans le code afin qu'il n'y ait pas de bogues?
Nous commençons un nouveau projet. Étape 1 - Ne répétez pas les erreurs précédentes
Notre équipe a travaillé sur plusieurs projets AAA. Avant de commencer l'un d'entre eux, nous avons décidé de réfléchir sur le sujet "Comment faire le minimum d'erreurs". Aucun de nous ne voulait passer les deux derniers mois à travailler sur un projet à la recherche de bogues et d'effacer le code. L'une des tâches principales est la répartition des responsabilités et des responsabilités. Chaque type de travail a été assigné à un senior.
La première étape consiste à décider pourquoi tout cela est nécessaire. Le «pourquoi» du niveau supérieur s'explique simplement: nous voulons réduire le temps nécessaire pour éliminer les bugs, optimiser les coûts et améliorer la qualité globale du projet.
Il s'agit de libérer du temps pour effectuer des tâches intéressantes, celles qui vous permettent de vous réveiller joyeusement le matin et de prendre immédiatement en charge la mise en œuvre de la tâche. C'est ce qui a fait de nous tous des développeurs - l'occasion d'utiliser notre temps pour des trucs vraiment cool!
Soit dit en passant, même s'il y a une tâche claire pour créer moins de bogues, elle est si générale qu'elle peut simplement être dénuée de sens. Il s'agit d'une déclaration d'intention qui doit être clarifiée et décomposée en une série d'affectations claires adressées aux membres individuels de l'équipe.
Pour répondre à la question de savoir comment procéder, il est nécessaire de suivre les bases de la méthode scientifique: observation, hypothèse, test, répétition.
Observation
CatégorisationOuvrez la base de données de bogues de votre dernier projet et affichez-la. Il existe de nombreuses variétés de bogues, alors disons simplement: moins d'erreurs est tout simplement inutile.
Afin de mieux comprendre le problème, vous devez déterminer les détails. Tout d'abord, il est nécessaire de réduire le nombre de ces problèmes, dont la détection et la solution nécessitent une percée dans le temps.
AnalyseAprès avoir compilé une liste des bogues les plus chronophages, l'étape suivante consiste à essayer de trouver un terrain d'entente dans ces erreurs, ainsi que de comprendre la raison de leur apparition. Analysez et interprétez!
Cause du problèmeAu final, nous avons créé un certain nombre de modèles pour rechercher des bogues spécifiques, ce qui a permis de comprendre pourquoi leur recherche et leur élimination prennent autant de temps. Après cela, nous étions prêts à aller dans le code source pour trouver la cause première du problème.
En travaillant avec des spécialistes techniques, nous avons découvert plus de changements de correctifs. Ensuite, nous avons compilé de nouvelles listes de systèmes, fichiers et lignes de code associés aux principaux bogues. En fin de compte, nous avons fait une liste des modifications de code nécessaires qui pourraient être discutées avec l'équipe de développement.
Nous vous l'avons dit!Ensuite, nous avons eu une réunion avec les programmeurs afin de discuter de nos résultats. Il s'est avéré que les gars connaissaient la plupart des problèmes du code. Mais si oui, quel était l'intérêt d'avoir une réunion?
Réponse: nous avons réussi à établir un parallèle entre des endroits spécifiques du code et les pertes de temps associées à ces problèmes. Et cela, à son tour, a permis d'évaluer objectivement toute proposition de maintenance de code.
Ainsi, nous avons passé en revue les sections du code qui pourraient être qualifiées de mauvaises acceptables. Lorsque nous les avons évalués avec nos meilleures pratiques, il s'est avéré que nous avions besoin d'une refactorisation. Dans le même temps, l'équipe d'ingénierie l'avait abandonné auparavant car «il y a trop de travail» ou «c'est tout simplement impossible».
En fait, de nombreux problèmes étaient systémiques. De nombreux aspects «invisibles» ont conduit à une chaîne d'événements qui ont provoqué l'apparition d'une erreur. Soit dit en passant, les causes des problèmes étaient si systémiques que le projet a dû repartir de zéro.
En conséquence, nous avons accumulé suffisamment de résultats d'observations et d'analyses empiriques pour formuler des hypothèses. Toute l'équipe a participé à ce processus.
Hypothèses
Hypothèse 1. Des schémas de codage spécifiques sont susceptibles d'entraîner l'apparition de bogues dans un grand projet logiciel.
Hypothèse 2. Le temps nécessaire pour corriger les erreurs dans un projet peut être réduit en évitant les schémas de comportement définis dans la première hypothèse.
Décidons ce qu'est un gros projet. C'est environ 25 programmeurs, 12 mois de développement. Les déclarations suivantes sont vraies pour lui:
R. N'importe quel code vivra assez longtemps, donc le coût de la maintenance dépassera finalement le coût du développement lui-même.
B. La complexité de la connexion des systèmes de projet individuels est plus élevée que la complexité d'un système particulier.
Pourquoi est-ce si important? Dans les petits projets, vous pouvez faire face à presque tout, ici la structure du programme n'est pas si importante. Le code est à votre disposition.
Si le projet est grand, alors tout change. Vous pouvez travailler avec un code dont vous ne comprenez pas le but, vous ne savez peut-être même pas à quelle partie du projet appartient un site particulier.
Après notre discussion, nous avons obtenu cet énoncé des résultats: «Les données montrent que ces modèles de programmation spécifiques étaient un facteur commun associé à divers bogues / problèmes. Nous pensons qu'en évitant ces modèles, nous pouvons réduire le temps nécessaire pour corriger les erreurs et en même temps améliorer la qualité. »
Maintenant, nous commençons à la mise en œuvre pratique.
Test
Lors de la création d'un nouveau projet, vous devez éviter les modèles de bogues identifiés. Nous l'avons eu:
- Surcharge de l'opérateur et mauvaise dénomination.
- Caractéristiques auto, polymorphes et négligence de la sécurité du type.
- Augmentation de la complexité du code en injectant, par exemple, des dépendances et des rappels.
- Utilisation de mutex, sémaphores et similaires dans le code de haut niveau.
Et ensuite?
Et puis nous avons eu l'opportunité de démarrer un nouveau projet, le développement d'un nouveau jeu. Nous avons pu créer un moteur de jeu à partir de zéro et tout terminer à temps, avec une équipe de programmeurs relativement petite. Il y avait peu de bugs, mais le code s'est avéré bon. En même temps, il a fallu un peu de temps pour le réparer.
Tout cela est devenu possible car nous n'avons pas utilisé de schémas problématiques, comme s'ils n'existaient plus. Nous avons même reçu le mantra «complique l'apparence d'une erreur».
Toute l'équipe était satisfaite de ces résultats, c'est devenu plus intéressant de travailler, car là encore il est devenu possible de passer du temps sur ce que l'on aime.
Skillbox recommande: