Écoutez, je ne sais pas comment lancer cette infolettre. Elle aurait pu s'intituler un truc bizarre comme « la cabale secrète des développeurs ». Ça aurait pu l'être, parce que c'est vrai (un peu), mais c'est aussi un titre boiteux.
Un autre titre possible : « La seule chose (je pense) qui pourrait être l'une des choses les plus importantes qu'un développeurs puisse faire ». Celui-là achoppe sur la langue et s'écrase à l'atterrissage. Un autre : « une compétence cruciale que chaque développeur devrait maîtriser ». Mais il faut en convenir, c’est mauvais aussi.
Le problème c’est que ce dont je veux vous parler semble tellement ennuyeux (sauf si vous aimez les listes à puces), mais je pense vraiment que c'est important et que c'est l'une des compétences fondamentales que possèdent de nombreux développeurs efficaces.
Je parle de faire un plan. Un plan pour quelque chose que vous souhaitez mettre en œuvre. J'ai aussi déjà entendu dire que cela s'appelait un plan technique, ou un concept technique, mais, le plus souvent, cela s'appel un plan.
C'est quelque chose qu'on m'a demandé de faire depuis que j'ai commencé à programmer professionnellement et maintenant je le fais inconsciemment chaque fois que j'ai besoin de réfléchir à la façon de faire quelque chose, de répondre combien de temps cela prendrait probablement, s'il a des parties parallélisables, quand il est possible de faire une pause, quand que je pourrais livrer, et ainsi de suite.
Supposons que la tâche soit la suivante : permettre aux utilisateurs de télécharger des avatars sur leur page de profil et d'afficher ces avatars.
Le plan que j'écrirais dans le ticket (ou dans mes notes), ressemblerait à peu près à ceci :
Objectif : permettre aux utilisateurs de télécharger des avatars sur leur page de profil et d’afficher les avatars
Tâches:
- migration pour ajouter `avatar_url` à la table `users`, null par défaut
- modifier la définition du modèle `User` pour inclure également `avatar_url`
- ajouter la configuration du bucket AWS S3 à l'application, y compris l'environnement de test/staging
- créer un bucket (nom du bucket ? autorisations ? demander au produit/infra)
- ajouter la bibliothèque AWS afin que nous puissions faire la signature d'URL
- modifier la page d'édition du profil pour rendre l'URL de téléchargement pré-signée aux téléchargements (POST) directement sur S3
- utiliser la bibliothèque dans le contrôleur pour créer une URL pré-signée
- ajouter un itinéraire pour accepter avatar_url
- ajouter le contrôleur `UserAvatars` avec l'action `create` qui accepte `avatar_url`, qui est l'URL S3
- frontend : ajoutez un formulaire de téléchargement sur la page de profil qui publiera l'image téléchargée sur (en utilisant l’URL POST pré-signée directement vers S3)
- page de profil : rendre `<img>` si `user.avatar_url` n'est pas null
- interface : CORS ???Questions ouvertes:
- autorisations du bucket ?
- que faisons-nous lorsque l'utilisateur télécharge un avatar et qu'il en a déjà un ? Supprimons-nous ?
- que faire de l’ancien sur S3 lors d'un upload réussi ?
Il manque probablement quelque chose ou quelque chose ne va pas. Désolé, mais je viens de taper ceci en imaginant une hypothétique application sur lequel je n’ai jamais travaillé.
Vous avez l'idée cependant. C'est un plan approximatif sur la façon dont j'implémenterais cette fonctionnalité, de la migration de la base de données aux modifications coté client, à divers degrés de détail.
Est-il incomplet ? Oui. Ce plan va-t-il changer ? Oui, probablement, voir les questions ouvertes à la fin - ce sont des choses qui me sont venues à l'esprit en écrivant, indiquant que tout n'est pas clair dans cette demande de fonctionnalité.
Cela vaut-il encore la peine d'être écrit ? Cent mille millions de pour cent. Absolument. Parce que voici le problème : il ne s'agit pas seulement du plan lui-même, il s'agit de la réflexion que nous avons menée pour arriver au plan.
Les tâches ci-dessus, je n'ai pas eu à les écrire. J'aurais pu commencer à programmer. Mais le deuxième jour, après avoir trébuché sur les documents de la bibliothèque AWS S3 avec des égratignures sur le visage, je me suis rendu compte :
hé, que faisons-nous des avatars déjà téléchargés ? Est-ce qu'on les supprime ? Comment? Avons-nous suffisamment d'informations sur le backend pour le faire ? Ou avons-nous besoin de stocker plus d'informations ? Avons-nous également besoin de stocker le bucket et le nom de fichier dans la base de données ?
Le plan n'est pas seulement utile parce qu'il vous donne quelque chose que vous pouvez cocher pendant que vous faites votre travail, ou quelque chose que vous pouvez diviser et déléguer (hé, qu'en est-il de ces parties "frontend" - quelqu'un d'autre peut-il le faire ?), c'est utile parce qu'en l'écrivant, vous réfléchissez activement à ce que vous êtes censé faire. Signification : cela vous aide à mieux le faire.
La rédaction du plan vous aide à construire un modèle mental de tout le travail requis. Vous verrez si vous avez besoin de modifications de la base de données, uniquement des éléments frontend, si cela prend 1 semaine ou 1 mois. Le nombre de fois où j'ai écrit un plan comme celui-ci et que je me suis soudainement redressé en disant « attendez, ce n'est pas si facile » ? Beaucoup, beaucoup de fois.
Ne vous attardez pas sur la forme du plan ici. Tous les plans ne ressemblent pas à celui ci-dessus. Ils peuvent être de niveau supérieur et contenir moins de détails, ou ils peuvent être encore plus détaillés. Ils pourraient être plus longs et contenir non seulement la fonction de téléchargement d'avatar, mais toute la page de profil utilisateur et ses sous-fonctionnalités. Parfois, je ne l'écris même pas.
Ce qui est important, c'est que vous ayez un plan pour que, lorsque quelqu'un vous demande si vous savez ce que vous faites, vous le sachiez.
Et pourtant, je vois tellement de développeurs ne jamais créer de plans ou se débattre lorsqu'ils tentent de le faire. Pourquoi? Je ne suis pas sûr. Je ne peux que deviner. C'est peut-être parce qu'il est souvent facile de simplement commencer, parce qu'il y a généralement quelque chose sur lequel tout le monde est d'accord (dans le cas ci-dessus : tout le monde serait d'accord pour dire que nous devons stocker l'URL de l’avatar quelque part ), et devoir réfléchir au reste semble être un perte de temps? C'est peut-être parce que les gens ont du mal avec le modèle mental derrière le plan - ils ne peuvent pas réfléchir à la façon dont toutes les parties interagissent parce qu'ils ne peuvent pas "voir" aussi loin ? Je ne sais pas.
La bonne nouvelle : faire des plans vous aide à mieux faire des plans. Commencez simplement à le faire. La prochaine fois que vous devrez implémenter quelque chose, ouvrez un fichier todo.md et notez ces tâches. Lisez à nouveau la liste et ajoutez les choses que vous avez manquées lors du premier passage. Faites-le jusqu'à ce qu'il n'y ait plus de changements lorsque vous faites une révision du plan. Remettez ensuite cette liste à votre collègue et demandez-lui : cela te semble-t-il correct ? Peut-être qu'il peut vous aider et signaler quelque chose que vous avez manqué. Ensuite, regardez votre liste et demandez-vous : combien de temps cela prendra-t-il pour faire tout cela ? 3 jours? 4 ? Peut-être 5. Mais remarquez : ce n'est plus une supposition sauvage, vous savez maintenant à peu près combien de travail cela représente - à peu près. C'est déjà beaucoup plus de sens que de dire "je ne sais pas". Ensuite, regardez votre liste et prioriser les choses comme vous les implémenteriez. Si vous devez partager votre travail avec un collègue, ajoutez des noms à côté de chaque tâche.
Ensuite, prener un pas de recule et tapotez-vous sur l'épaule. Félicitations, vous avez maintenant un plan.
Merci d'avoir lu mon humble texte