Bienvenue sur le podcast Artisan Developer, l'émission pour les
programmeurs qui veulent vivre une carrière épanouissante. Prêt à
passer au niveau supérieur ? C'est parti !
Si il y a bien un truc sur lequel on est tous d'accord en général quand on fait
du débe, c'est que personne n'aime les bugs. Personne n'aime se rendre compte
que l'application marche pas, personne n'aime avoir un client furieux au téléphone
parce que l'application est buggée. La question c'est pas tellement est-ce qu'on
aime les bugs ou pas ? La question c'est comment est-ce qu'on y réagit en fait ?
Parce que les bugs renvoient un besoin de sécurité, c'est normal.
Tu n'as pas envie que les choses soient défaillantes, tu as envie que de pouvoir
compter sur l'application que tu vends, tu as envie de compter sur l'application
que tu utilises. Et là, il y a plusieurs types de réactions.
Il y a ceux qui vont chercher à renforcer les choses, c'est à dire à
empêcher le bug d'arriver. Et il y a ceux qui vont plutôt privilégier une
stratégie de vitesse, c'est à dire accepter un certain niveau de risque mais
pour pouvoir compenser par la vitesse. Tu vois ce dilemme, tu vas pouvoir
l'avoir si tu as fait des jeux de rôle, tu vas vite comprendre.
En gros, est-ce que tu as envie d'aller au combat avec une armure de cuir clouté
ou une armure de plaque ? Une armure de cuir clouté, c'est quelque chose qui va
clairement privilégier à la mobilité, qui va être léger. Alors ça va t'apporter
beaucoup moins de bonus défensif qu'une armure de plaque parce que une armure
de plaque, il n'y a pas grand chose qui va la transpercer en fait.
Mais c'est sacrément lourd quoi, c'est tellement lourd que les mecs ne m'aiment
pas monter à cheval seul en fait avec une armure de plaque.
Dans Je ne sais plus trop quel film, on voit un roi anglais qui livre une bataille
aux français, il se débrouille pour les amener vers un terrain boueux et là
tu as son second qui a une espèce de stratégie assez fine d'amener les
français en plein de descente donc à plein de vitesse dans un terrain bien
boueux, ils misent tout sur la météo et sur le fait qu'ils pleuvent.
Et là ils y vont mais en armure légère, même limite, ils n'ont presque
pas d'armure en fait et devinent qu'ils gagnent.
Pas les français qui sont embourbés jusqu'aux genoux dans leur armure de
plaque, certains se noient même dans la boue en tombant de leurs chevaux,
mais ce sont bien les anglais qui gardent une très forte mobilité même dans la
boue qui sont capables de bouger, d'esquiver, de se déplacer.
Et là c'est vraiment, c'est vraiment un dilemme que tu as à voir.
Est-ce que tu vas privilégier une énorme équipe du QA qui va venir vérifier,
vérifier, vérifier ou est-ce que tu vas venir faire des recettes à répétition
des cas une virgule qui change dans ton application ou est-ce que tu vas
chercher à aller vite ?
Moi très clairement j'ai choisi mon camp.
Mon camp c'est tout simplement d'avoir un flux totalement automatisé, d'avoir
une très bonne couverture de code par mes tests qui me rassure et de pouvoir
aller vite.
C'est à dire que si jamais je découvre un bug dans l'application, ce qui arrive quand
pas tous les jours en plus, c'est pas grave.
Je sais qu'en 1,5h, une demi-heure, je peux le fixer, le problème.
Parce que finalement, tant qu'il n'y a pas de perte de données, c'est pas la mort.
Alors si il y a perte de données, oui ça devient carrément problématique.
Et encore parfois la donnée tu peux la régénérer.
Mais sinon, en dehors de ça, il ne faut pas déconner qu'il y a personne qui va
mourir. Donc là effectivement, sauf si tu fais le logiciel de la capsule Dragon,
sauf si tu envoies un truc sur un satellite ou tu fais flinguer un projet de
plusieurs années.
Mais en dehors de ça, je connais peu de développeurs qui travaillent dans ces conditions-là.
Moi, je préfère clairement pouvoir réagir vite dès qu'il y a un problème qui se lève.
Alors le seul bémol, c'est si tu envoies des systèmes qui sont critiques,
c'est-à-dire soit tu codes pour des systèmes critiques, soit des systèmes qui sont loin et que tu ne
peux plus récupérer si il y a une fausse manip quelque part.
Mais encore une fois, ça ne va pas concerner grand monde.
L'autre vrai bémol que j'ai vu, c'est sur les stores et notamment sur la Apple Store,
parce que ça demande plusieurs jours de réactivité.
Et là, j'avoue que c'est un peu pénible.
C'est franchement chiant, en fait, quand tu veux attendre, quand tu vas devoir attendre
plusieurs jours pour pouvoir faire passer ton bug fix, c'est relativement pénible.
Et c'est là qu'on a découvert un vrai intérêt au WebView.
Dans certains projets qu'on fait, on utilise les WebView pour accélérer le
développement sur des parties qui sont moins utilisées.
On peut les voir carrément sur le cœur de l'App, mais au moins dans une espèce de logique de prototype.
On fait ça de manière assez fine avec une navigation qui reste native et des composants
intérieurs WebView qui font qu'en fait, tu te casses le nez et puis tu as moins de vraiment de voir
avec un debugger ce qui est en train de se passer derrière.
Tu peux difficilement te rendre compte qu'en fait, tu es sur une WebView.
Et alors au début, on le faisait par souci d'économie, mais on s'est rendu compte qu'il y avait cet énorme
avantage qui était de pouvoir fixer les choses rapidement.
Et c'est ça que j'adore, moi, avec le Web.
C'est que tu peux aller vraiment très, très vite.
C'est probablement le système qui est le plus rapide à faire évoluer.
Tu fais une mise à jour ton serveur et là, d'un coup, tous tes utilisateurs, tous tes clients
reçoivent la mise à jour et tu peux faire ça en quelques secondes, en quelques minutes.
Et c'est quelque chose que j'adore.
Donc, moi, ce que je privilégié, c'est un certain niveau de sécurité assez significatif quand même.
Tu remarques que je ne te parle pas de balancer les choses en l'air
sans avoir un petit peu de défilé de sécurité.
Je te parle de faire les choses vraiment proprement en termes de code, en termes de test,
notamment test unitaire, test automatique.
Et après, accepter qu'il y ait une petite phase d'incertitude.
Oui, ça arrive des fois de laisser passer un bug.
Tu corriges dans l'heure, c'est réglé, on n'en prend le plus.
Parce qu'à côté de ça, si tu mets, si à chaque fois que tu as une évolution à faire, tu dois mettre des heures
ou des jours à passer par des cycles de, on va dire, de validation au sens très large.
Regarde le temps que tu perds.
Pour moi, c'est vraiment le cœur.
Alors, je ne sais pas si on va dire de l'agilité, du lignes ou tout simplement d'une gestion efficace,
des ressources et de l'énergie et du temps notamment.
C'est de pouvoir itérer rapidement.
Est-ce que tu es capable d'aller vite quand tu as des idées ?
Est-ce que tu es capable d'exposer au marché tes nouvelles idées rapidement ?
Pour moi, il est là l'enjeu.
Il n'est pas d'être sûr que tu as zéro bug.
Moi, dans mon travail de tous les jours, je ne sais pas, je dois avoir un ou deux bugs par projet par an,
un truc comme ça, un truc un peu méchant, un truc vraiment, je veux dire, un truc vraiment embêtant.
Je ne te parle pas d'un écart de pixels, d'une photo d'orthographe ou tout genre de choses.
Je te parle de quelque chose qui est vraiment embêtant pour le système.
Donc, la question, elle est là, est-ce que tu veux lâcher de ta vitesse pour gagner en sécurité de, je ne sais pas quoi,
ou est-ce que, en fait, finalement, le fait d'aller vite est intrinsèquement un gage de sécurité supplémentaire.
Voilà, tu as compris quel était mon point de vue, mais je suis curieux d'entendre le tien.
Qu'est-ce que tu en penses ?
Incriz-moi sur benoirobasartisandeveloper.fr.
Je suis vraiment curieux de savoir si cette avis est partagée ou si c'est au contraire, ça te fait bondir.
Et en tout état de cause, je t'invite à partager cet épisode, à organiser une écoute commune avec tes collègues,
parce que je pense que c'est un sujet qui se prête vraiment au débat, à l'échange,
et qui vous permettra peut-être de faire émerger des points d'amélioration, des points que vous voulez revoir, des points d'ajustement.
En tout cas, je suis curieux également de ce que ça aura donné.
La post-café écoute,
le format qui marche bien, tu proposes une écoute,
vous partagez l'écoute et après pendant un quart d'heure, vous échangez sur le thème abordé.
Voilà, je suis impatient d'écouter ton feedback ou de te lire. Je te souhaite une bonne journée, je te dis à bientôt.