| Conférencier |
Transcription |
| Aurora Tiffany-Davis |
Bonjour, je m'appelle Aurora Tiffany-Davis. Je suis développeuse logicielle au sein de l'équipe JMP Live. J'aimerais aujourd'hui vous parler de notre façon de développer des logiciels. |
| |
Tout d'abord, j'aimerais que vous imaginiez à quoi ressemble la création de logiciels. Si vous n'êtes pas développeur, l'image que vous avez en tête est probablement influencée par la télévision et les films que vous avez vus. |
| |
Vous imaginez peut-être quelqu'un qui travaille seul, quelqu'un qui est vraiment intelligent, peut-être même un génie et dont le processus est vraiment simple. |
| |
Ils réfléchissent à un problème, écrivent du code, puis s'assurent que ça fonctionne. Et c'est probablement le cas, car après tout, ce sont des génies. |
| |
Si nous étions tous des génies de JMP Live, ce processus simple fonctionnerait pour nous. Mais ce n'est pas le cas et nous vivons dans le monde réel. Il nous faut donc un peu plus que cela. |
| |
Tout d’abord, nous ne travaillons pas seuls, nous travaillons de manière très collaborative et notre processus comporte des étapes pour essayer de garantir que nous produisons non seulement des logiciels, mais des logiciels de qualité. |
| |
Je tiens à souligner qu'il n'existe pas de méthode unique pour développer des logiciels. Cela peut varier d'une entreprise à l'autre, voire au sein d'une même entreprise, mais je vais vous expliquer notre processus. |
| |
en vous disant ce que je ferais si je devais développer une nouvelle fonctionnalité dans JMP Live. |
| |
Tout d’abord, avant de m’asseoir pour écrire du code, je dois avoir besoin de le faire. |
| |
Il doit y avoir un véritable utilisateur avec un véritable problème, quelque chose qu'il a identifié dans JMP Lives et qui ne fonctionne pas... qui ne fonctionne pas comme il le pense, |
| |
ce qui est une belle façon de dire qu'ils ont trouvé un bug ou une fonctionnalité qu'ils ont demandée. |
| |
Nous suivons ces demandes dans un système interne. La première chose que je ferais serait donc d'y accéder, de trouver un problème prioritaire correspondant à mes compétences et de commencer à travailler dessus. |
| |
Ensuite, je dois mieux comprendre les besoins. Je vais discuter avec les utilisateurs pour déterminer quel type d'utilisateur souhaite utiliser cette fonctionnalité. Comment vont-ils l'utiliser ? |
| |
Ensuite, j'exécuterai JMP Live sur ma machine et je verrai où cette fonctionnalité pourrait s'intégrer dans JMP Live tel qu'il existe aujourd'hui. |
| |
Ou je pourrais ouvrir le code et voir où le nouveau code pourrait s'intégrer dans notre base de code existante. |
| |
Une fois que je pense avoir une bonne compréhension des besoins, je commence à travailler sur la conception. Là encore, je discute avec les gens. Je discute avec les membres de l'équipe et je leur demande : « Avez-vous déjà travaillé sur une fonctionnalité similaire ? Avez-vous déjà travaillé sur cette partie du code ? » |
| |
Et je parlerai aux experts en expérience utilisateur que nous avons chez JMP. |
| |
Je vais essayer de ne pas réinventer la roue. Donc, s'il y a un aspect de la fonctionnalité qui est très courant et qui n'est pas spécifique à JMP Live, par exemple, la journalisation d'informations dans un fichier. |
| |
C'est un problème résolu ; des milliers de personnes ont déjà rencontré ce problème. Il existe peut-être une bonne solution open source. |
| |
Et si c'est le cas, je pourrais l'utiliser après l'avoir soigneusement examiné pour m'assurer qu'il est sûr à utiliser. |
| |
Il reste encore beaucoup de chemin à parcourir, beaucoup de code spécifique à JMP Live à écrire. Je vais donc écrire des articles, des diagrammes et |
| |
Je décris ce que je propose et je m'assure que tous les membres de l'équipe sont d'accord avec l'orientation que je prends pour la conception. Ensuite, je m'installe et je code. |
| |
Pour cela, j'utiliserai un environnement de développement intégré, qui est un outil d'écriture de code doté de nombreuses fonctionnalités pour vous aider à être plus efficace dans votre travail. |
| |
J'ai maintenant écrit du code. Avant de le valider, je veux identifier les problèmes qui y sont présents. Je suis humain, donc les chances d'avoir écrit un code 100 % parfait du premier coup sont plutôt minces. |
| |
Je vais commencer par rechercher des problèmes très évidents et pour cela, j'utilise l'analyse statique. |
| |
L'analyse statique examine mon code non pas en cours d'exécution, mais comme s'il était simplement écrit sur une page. Une analogie serait le correcteur orthographique de Microsoft Word. |
| |
Le correcteur orthographique ne peut pas vous garantir que vous avez écrit un roman captivant, mais il peut vous indiquer si vous avez oublié une virgule. L'analyse statique le fait pour le code. |
| |
Une fois que j'ai identifié et corrigé des problèmes aussi évidents, je passe à la recherche de problèmes moins évidents. Pour cela, nous utilisons une suite de tests automatisés. |
| |
Cette méthode diffère de l'analyse statique car elle exécute réellement le code. Elle exécute une partie du code avec une entrée spécifique et attend une sortie spécifique. Nous avons écrit une large gamme de tests pour notre code. |
| |
Et je vais m'asseoir et écrire des tests pour la fonctionnalité sur laquelle je travaille. |
| |
C'est très utile, car écrire les tests m'oblige à clarifier ma réflexion sur le fonctionnement exact du code. De plus, cela me protège contre toute éventuelle défaillance accidentelle de la fonctionnalité. C'est un excellent moyen de détecter les problèmes en amont. |
| |
Passons maintenant aux tests manuels. Je vais exécuter JMP Live sur ma machine, tester la nouvelle fonctionnalité et m'assurer qu'elle fonctionne comme prévu. |
| |
Je pourrais même fouiller dans la base de données qui se trouve derrière JMP Live et qui garde une trace des enregistrements, des publications, des groupes, des utilisateurs et des commentaires pour m'assurer que tous ces enregistrements sont écrits de la manière dont je pense qu'ils devraient l'être. |
| |
Maintenant, je suis prudemment optimiste quant à la qualité de mon code et la prochaine étape est la révision par les pairs. J'aimerais que mes pairs m'aident à examiner le code et à identifier tout ce que j'aurais pu oublier. |
| |
J'ai peut-être manqué quelque chose parce que je suis aveuglé par quelque chose ou parce qu'un autre membre de mon équipe possède des connaissances que je ne connais pas. Cette étape est souvent très utile pour le réviseur, car il peut ainsi découvrir de nouvelles techniques. |
| |
Une fois le code soumis à un examen par les pairs, nous sommes prêts à le valider ou à le vérifier dans un référentiel de code source. |
| |
Nous avons un système de construction continue sur nos serveurs qui veille à ce que nous enregistrions le code. Et lorsque nous le faisons, il fait un tas de choses avec ce code. |
| |
Par exemple, il faut s'assurer que les bons fichiers sont au bon endroit, qu'ils portent les bons noms, etc. Il faut également relancer l'analyse de la pile et l'ensemble de la suite de tests automatisés. |
| |
C'est utile, car après tout, nous ne sommes que des êtres humains. Quelqu'un a peut-être oublié de faire cette action plus tôt dans le processus, ou quelque chose a peut-être changé depuis la dernière fois. |
| |
Une fois le code terminé, il est accessible aux personnes extérieures à l'équipe de développement. Les premiers à s'en rendre compte sont les professionnels du test chez JMP. |
| |
Ils vont passer en revue nos tests automatisés et pourraient les compléter. Ils pourraient également exécuter des tests manuels. |
| |
Ils peuvent étudier le fonctionnement du logiciel sur différents systèmes d'exploitation, navigateurs, etc. Ils imaginent des actions insensées que l'utilisateur pourrait entreprendre et observent ce qui se passe et la réaction du logiciel. |
| |
Ils jouent un rôle crucial dans notre processus. Ils font preuve d'une grande créativité pour identifier les problèmes de notre produit. |
| |
Une fois le processus validé, le logiciel est disponible pour notre prochaine version. Je vais maintenant vous présenter le produit et le processus dans son ensemble. |
| |
Et cela représente beaucoup d'étapes. C'est beaucoup de choses. Est-ce qu'on fait vraiment tout ça pour tout notre code ? |
| |
Croyez-le ou non, ce processus est très évolutif. Pour un bug évident et très simple, nous allons donc le suivre très rapidement. |
| |
Mais pour une nouvelle fonctionnalité très complexe à chaque étape de ce processus, nous allons ralentir, prendre notre temps et faire très attention pour nous assurer que nous le faisons vraiment correctement. |
| |
Tout ce qui prend du temps coûte de l'argent à une entreprise. Alors pourquoi JMP est-il prêt à investir autant dans la qualité de ses logiciels ? |
| |
L'une des raisons est très simple : nous sommes fiers de notre travail et nous souhaitons produire un produit de qualité. |
| |
La deuxième raison est un peu moins idéaliste. Nous savons que si notre produit présente des problèmes et que nous ne les décelons pas, nos clients en rencontreront, ce qui nuit à notre activité. Nous souhaitons donc minimiser ce risque. |
| |
Je dois souligner que même si JMP investit du temps et de l’argent dans la qualité des logiciels, |
| |
Nous n'investissons pas autant d'argent qu'une organisation comme la NASA, par exemple. Nous ne pouvons donc pas promettre la perfection. Comme pour tout logiciel disponible sur le marché, |
| |
Il se peut que vous trouviez quelque chose dans JMP Live qui ne fonctionne pas comme vous le souhaiteriez. Si vous trouvez une suggestion, |
| |
nous aimerions vous inviter à vous rendre sur www.jmp.com/support et à nous faire savoir s'il y a quelque chose qui, selon vous, devrait fonctionner différemment ou des fonctionnalités que vous aimeriez à l'avenir. |
| |
Ce genre de retours concrets de la part d'utilisateurs réels est extrêmement précieux pour nous et nous les apprécions vraiment. C'est tout pour vous aujourd'hui, mais j'espère sincèrement que vous apprécierez la suite de Discovery. Merci. |
