Ma copine me rappelle le besoin de remplacer la sortie d’arrosoir à l’arrière de la maison, elle qui est désuète.
Notre PO arrive avec une demande visant à publier une nouvelle version de l’API. Nous devrons remonter des données dont la source provient d’un nouveau service.
Une affaire de rien changer cette petite section de plomberie selon les gens que je consulte pour évaluer les efforts.
L’équipe évalue les efforts.
Exposer une nouvelle version d’API, avec des données pigées en aval, c’est juste de la plomberie, voyons. 3 points, comme d’hab.
Quand j’ai des dispos, j’ouvre le mur pour mesurer l’ampleur du changement. Je remarque que la valve intérieure ainsi que le tuyau de cuivre qui l’alimente seront définitivement à changer.
J’ouvre le mur davantage ainsi que le plafond pour voir où tout ça se branche. Je remarque au passage une note de Bell dans le plafond…
Curieux, je vais explorer. Question de voir ce qui se cache derrière.
Belle surprise!
Le lendemain du planning, on ouvre le code…. Belle surprise! C’est un spaghetti de fils tous mêlés avec quelques commentaires juteux.
Il faut au minimum défaire les fils entre deux modules pour faire le changement plus facilement.
On va nettoyer les fils et retirer du chemin. On se fait un plan qui inclut aussi de remonter la valve intérieure à un niveau plus sécuritaire, qui en facilitera la fermeture, changements futurs, etc.
On décide stratégiquement où mettre la valve, je veux dire le feature flag, pour éviter de mêler les fils entre le code exercé dans la V1 et celui introduit dans la V2.
Je m’affaire au travail et perce le béton pour poser ma nouvelle valve extérieure aux standards d’aujourd’hui, etc.
On est prêt à intégrer notre nouvelle plomberie à la source d’eau!
En manipulant la valve d’entrée d’eau principale de la maison, je remarque qu’elle fuit dans mes mains quand je la manipule.
#@$@#??$#& de @#$#@##$#$@ de &$%&%$&&$
En allant exercer l’API en aval, on remarque qu’en plus des données de calculs, des informations personnelles et identifiables font partie de la structure de donnée exposée par celui-ci.
#@$@#??$#& de @#$#@##$#$@ de &$%&%$&&$
Nous allons faire venir un plombier assez rapidement pour changer la valve d’entrée d’eau, par sécurité. Lui devra préalablement faire fermer l’eau par les techniciens de la ville.
L’autre équipe doit faire le changement avant de progresser.
Pour ce faire, ils doivent attendre les recommandations l’équipe de sécurité avant de d’exposer leur service à nouveau.
Un appel de service à la ville plus tard, un plombier vient remplacer la valve intérieure.
Quelques tests et j’ai son GO! pour poursuivre mes travaux et enfin intégrer mes changements de valves au reste du système de ma maison.
Un appel de service plus tard, les recommandations sont effectuées. L’API est modifié et on a le GO! des’y connecter et s’affairer à y intégrer notre propre changement d’API.
Ouf…Quelle histoire!
Exposer une nouvelle version d’API, avec des données pigées en aval, c’est juste de la plomberie, voyons. 3 points. Comme d’hab!
N’est-ce pas….
Un petit rappel qu’il peut être judicieux, avant de fournir une évaluation des efforts, d’ouvrir le capot(votre IDE) et de regarder l’état actuel des choses(du code)avant de communiquer votre estimé sur le changement à venir.