Création de produits

1.1 « Les gens ne naissent plus, ils sont cultivés »

Bon, puisque tu es toujours là, continuons. « Et je vais te montrer à quel point le terrier du lapin est profond » ©

Laisse-moi te raconter comment se déroule le processus de développement d'un produit — nous allons parcourir toutes les étapes du niveau global le plus haut jusqu'au niveau le plus bas — l'écriture du code. Je pense que tu vas faire quelques découvertes intéressantes…

Les produits IT modernes ne sont plus écrits de fond en comble, ils sont créés. Ils sont assemblés à partir de bibliothèques, de frameworks, de programmes et de produits tiers, ou bien utilisent des services Internet payants ou gratuits à distance.

Un produit moderne est un véritable zoo de technologies, de services, de solutions et de processus. Une partie du travail est faite par les gens, une autre partie est automatisée, et les autres 90% sont carrément réalisés par des services cloud dans les data centers. Le monde a bien changé.

Mais la première chose à laquelle tu feras attention, ce sont les changements constants. Tu n'écris plus de programmes, tu y apportes des modifications.

1.2 Changements constants

Tu vas rejoindre une équipe de 20 personnes qui travaillent sur un produit depuis 5 ans. L'actuelle 7ème version est disponible pour les utilisateurs. Et ton objectif sera d'apporter des changements à ce produit. Des petits, pour ne pas effrayer les utilisateurs actifs actuels.

Et ce ne sera pas facile, car le produit fonctionne déjà. Il a des clients, et ils paient de l'argent. Par conséquent, il ne faut rien casser. Faire des modifications dans un produit qui fonctionne déjà est plusieurs fois plus difficile que dans un produit neuf. Pour cela, il y a des standards spéciaux, des protocoles de migration et des outils. Cela me rappelle une blague :

Deux vieux amis se rencontrent : l'un est devenu mécanicien, l'autre chirurgien... Chacun a sa vie, ses préoccupations, ses joies... Ils parlent de tout, et commencent à discuter des salaires. Le mécanicien dit : "Eh bien, je gagne 30 par mois et j'en suis très content, et toi combien ?". Le cardiologue dit : "Eh bien, environ 100 K par opération...". Alors le mécanicien s'intéresse : "C'est étrange, pourquoi une si grande différence ? Après tout, on fait la même chose - on change des pièces". Et le chirurgien lui répond : "Bon, allons à la voiture, démarre-la...". Le mécanicien démarre la voiture, le chirurgien ouvre le capot et dit au mécanicien : "Tu vois, le moteur tourne ? Change-le ! :)"

Même si un miracle se produit, et que ton équipe a passé une année entière à écrire un produit à partir de zéro et seulement après cela l'a publié, tu sais ce qui se passera ensuite ?

Si ton produit réussit, le propriétaire du produit voudra le développer. Sortir une nouvelle version, ajouter des fonctionnalités. Ou au moins mener quelques expérimentations. Et tu sais ce qui va suivre ? Des modifications.

1.3 Valeur du produit

Du point de vue du développement moderne, seule a de la valeur le code qui a été publié, et la fonctionnalité que les utilisateurs utilisent. Si tu as écrit du code, il est stocké quelque part, il fonctionne, mais personne ne l'utilise, sa valeur est proche de zéro. C'est pourquoi tout le code doit être mis en production le plus tôt possible.

Ton code doit passer par les étapes suivantes :

• Tu l'as écrit et tu t'es assuré qu'il fonctionne.
• Ton TeamLead l'a revu et l'a ajouté à la branche principale dans Git.
• Les tests durant la construction du programme ont montré que tu n'as rien cassé d'important.
• Les tests d'intégration ont montré que le produit fonctionne correctement.
• Un testeur a vérifié ce code et a donné le feu vert pour la release.
• Ensuite, il faut construire une nouvelle version du produit et la publier sur le serveur.
• La nouvelle version du produit doit être emballée dans des Docker Images et publiée.
• Il peut être nécessaire de lancer des scripts de migration et d'apporter des modifications à la base de données et/ou d'autres solutions tierces.
• Ensuite, il faut collecter les logs sur le serveur pour s'assurer que tout fonctionne correctement.
• En cas de situation imprévue, si tu as cassé quelque chose, il faut revenir en arrière pour restaurer l'état précédent de la base de données et ne pas perdre les actions effectuées par les utilisateurs pendant qu'ils travaillaient avec la version instable du produit.

Dans la plupart des entreprises, ces tâches sont maintenant résolues : de nouveaux processus ont été mis en place, des personnes spécifiques ont été embauchées, des protocoles de sécurité et des standards de contrôle qualité ont été introduits.

Plus l'entreprise est grande, moins il y a de temps qui passe entre l'écriture du code et le moment où il est mis en production et devient une valeur — commence à apporter de l'utilité aux gens.

Dans la plupart des entreprises, le code parcourt ce chemin en deux semaines. Cependant, il y a des entreprises qui font des releases chaque semaine ou même chaque jour. Les plus exceptionnellement rapides — plusieurs fois par jour.

Le code écrit ne vaut rien. Seul le code qui fonctionne en production apporte de la valeur.