Une des chose que nous prêchons au sein de l’équipe ThinkR sont les bonnes pratiques de développement en R, pour la production. Bien sûr, cela s’applique également aux applications Shiny – et encore plus si nous touchons au package {golem}, qui promeut les bonnes pratiques pour du Shiny « de qualité production ».
Mais prenons un peu de recul et réfléchissons à ce qui fait le succès d’une application Shiny enproduction.
Elle existe
Table des matières
Cela semble être un concept évident, mais bien sûr, une application Shiny est réussie et prête à être envoyée en production si l’équipe de développement a pu passer de l’idée à la mise en œuvre réelle et à la livraison. C’est une définition du succès très « orientée dev », mais c’est une définition pragmatique : un projet qui n’existe pas ne peut pas être un succès.
Et lorsqu’il s’agit d’une application Shiny (ou de n’importe quelle application web), le fait qu’une application existe signifie que l’équipe a pu s’organiser de manière efficace, afin qu’ils puissent travailler ensemble pour faire de cette application un succès. Toute personne ayant déjà travaillé en équipe sur du code sait que ce n’est pas une tâche facile.
Travailler dans un cadre comme {golem} vous aide à atteindre cet objectif : travailler dans une structure formalisée vous aidera à garder une trace de ce qui se passe, et permet de saisir plus facilement ce qui est contenu dans un projet donné. Par exemple, si j’ouvre aujourd’hui un projet {golem} que je n’ai jamais vu auparavant, je pourrai immédiatement comprendre comment la base de code est organisée.
Les résultats y sont justes
Une fois que l’application existe, l’autre paramètre qui définit une application de production est qu’elle est précise. En d’autres termes, la visualisation est correcte, les algorithmes renvoient la réponse qu’ils sont censés donner, les informations sont celles dont on a besoin, etc.
Car oui, vous pouvez livrer une application qui fonctionne différemment de la façon dont elle est censée fonctionner, et dans ce cas, ça ne sera pas un succès. Comment éviter cela ? Tout d’abord, en appliquant la « séparation des préoccupations » :
- La logique métier doit être strictement séparée de la logique applicative : construisez le back-end et les fonctions non interactives séparément des éléments interactifs, travaillez dessus, validez-les, et ce n’est qu’une fois que tout a été testé de manière approfondie que vous pouvez commencer à intégrer les deux ensemble.
- Construisez une suite de tests solide et fiable, afin de pouvoir détecter tout bogue qui pourrait survenir au cours de votre projet.
Si vous utilisez {golem} et la philosophie générale qui l’accompagne, c’est quelque chose que vous appliquerez dès le début : séparez tout, construisez la logique commerciale et l’interface utilisateur, organisez tout dans des fichiers et, bien sûr, comme vous utiliserez la structure de package, reposez-vous sur les frameworks de test largement utilisés.
Elle est utilisable
Votre application existe, elle est juste, mais vous devez maintenant vous assurer qu’elle est utilisable – en d’autres termes, votre public doit visiter l’application et la trouver user-friendly. Et si ces personnes ne peuvent pas utiliser l’application parce qu’elle est trop difficile à naviguer, trop difficile à comprendre, parce qu’elle est trop lente ou parce qu’il n’y a pas de logique inhérente à la façon dont l’expérience utilisateur est conçue, alors il est inapproprié d’appeler l’application un succès.
Elle est immortelle
Bien sûr, personne ne s’attend à ce que votre application vive éternellement, mais c’est ce que vous devriez viser : la robustesse au fil des ans.
Planifier l’avenir est une composante très importante d’un projet Shiny App réussi. Une fois que l’application est sortie, elle est réussie si elle peut exister à long terme, avec tous les risques que cela implique : nouvelles versions de paquets qui pourraient potentiellement casser la base de code, appel soudain à l’implémentation de nouvelles fonctionnalités dans l’interface globale, changement de fonctionnalités clés de l’interface utilisateur ou du back-end, sans parler de la transmission de la codebase à quelqu’un qui n’a pas travaillé sur la première version, et qui est maintenant chargé de développer la version suivante . Et cela, encore une fois, est difficile à faire sans une planification efficace et une ingénierie performante.
Apprendre à construire une application Shiny pour la prod
Si vous souhaitez vous former aux applications Shiny pour la construction de bâtiments, nous organiserons une session de formation à distance en juillet.
Il s’agira d’une session de 10 demi-journées, entièrement à distance, sur notre plateforme d’apprentissage en ligne !
Et bonne nouvelle, vous pouvez obtenir la certification « Shiny Developer » à la fin de cette session.
L’inscription et de plus amples informations sont disponibles ici
