Ah, développeurs. Les créatures mythiques qui tapent rapidement, boivent du café comme s'il s'agissait d'un sport olympique, et qui parviennent, d'une manière ou d'une autre, à « réparer les ordinateurs » pour leurs amis et leur famille. Mais que font-ils vraiment toute la journée ? Laissez-moi vous peindre un tableau — spoiler : c'est bien plus compliqué (et plus amusant) que simplement « taper du code ».
Examinons cela en détail à l'aide d'un organigramme que j'ai joint. (Oui, des organigrammes, parce que s'il y a une chose que les développeurs aiment, c'est organiser le chaos de manière visuelle.)
La demande commence généralement par quelque chose d'inoffensif comme, « Pouvez-vous simplement changer la couleur de ce bouton ? » ou « Nous avons besoin de cette fonctionnalité en direct d'ici demain — ce ne devrait pas être difficile. » Les personnes non techniques imaginent les développeurs comme des sorciers tapant sur des boutons : abracadabra ! Nouvelle fonctionnalité déployée !
La réalité ? Ce « petit » changement déclenche une réaction en chaîne plus longue que votre liste de séries Netflix.
D'abord, les développeurs doivent déterminer où se trouve cette fonctionnalité dans le codebase. Imaginez essayer de trouver une seule chaussette dans une maison avec 500 tiroirs. C'est ce que la lecture du code d'une autre personne ressent. Oh, et la chaussette est en feu.
Après avoir fouillé dans le code, ils configurent un environnement de développement local. Cela semble élégant, n'est-ce pas ? C'est en fait leur terrain de jeu privé pour les tests où les erreurs ne cassent pas le site de l'entreprise. Sauf que ce « terrain de jeu » prend des heures à configurer parce que les outils décident parfois de cesser de fonctionner. (« Pourquoi Docker est-il en colère aujourd'hui ? » « Oh, sans raison, il vous déteste simplement. »)
Les développeurs écrivent ensuite du code. Puis ils réalisent qu'ils ont cassé quelque chose d'autre. Ensuite, ils corrigent ce qu'ils ont cassé, ce qui accidentellement casse quelque chose d'autre. Enfin, après quatre tours de jurons et un peu de pleurs (silencieux, pendant que l'on sirote du café), le code fonctionne ! Un peu. Peut-être.
Le code passe par le contrôle de version (Git) — un outil pour éviter que tout le monde ne marche sur les pieds les uns des autres. Sauf que fusionner les changements dans Git est comme essayer de négocier un traité de paix entre des enfants qui veulent tous la même chose. La résolution des conflits est un véritable superpouvoir pour les développeurs.
Avant que le code ne voie le jour, les développeurs le testent. Ils cliquent sur chaque bouton, remplissent chaque formulaire et effectuent des rituels pour invoquer les dieux du contrôle qualité. Ensuite, quelqu'un du contrôle qualité (Assurance Qualité) vient et trouve des bugs dans des endroits que les développeurs n'avaient même pas imaginés. (« Attendez, le bouton ne fonctionne pas si vous êtes connecté en tant qu'utilisateur gaucher utilisant Internet Explorer 11 ?? »)
Enfin, le code est prêt pour le déploiement en direct. Les personnes non techniques imaginent les développeurs appuyant sur un gros bouton vert « GO ». Non. C'est plus comme marcher sur une minefield en jonglant. Quelque chose toujours va mal. Le serveur s'effondre. La base de données oublie qu'elle existe. La fonctionnalité disparaît mystérieusement comme un mauvais tour de magie. Les développeurs réparent tout en temps réel pendant de s'évanouir.
Quand la fonctionnalité est en direct, les retours commencent : « Pourquoi le bouton n'est-il pas bleu au lieu d'être vert ? » « Pouvez-vous le déplacer de 3 pixels à gauche ? » Cue cri interne. Les développeurs mettent à jour silencieusement l'organigramme et retournent à l'Étape 1.
Alors la prochaine fois que vous entendez, « C'est juste un petit changement », rappelez-vous ceci : derrière chaque clic, défilement et glissement, se cache une épopée impliquant des batailles de code, du café et une pincée de chaos. Les développeurs font plus que « taper des choses sur un ordinateur » - ils sont des résolveurs de problèmes, des magiciens, des thérapeutes (pour leur code) et occasionnellement, des travailleurs miracles.
Alors peut-être achetez un café à votre ami développeur aujourd'hui. Il l'a bien mérité.
Robert Mejlerö est un CTO fractionnaire et fondateur de CTO as a Service (ctotmc.com)
Nous aidons les entreprises avec leur technologie, en fournissant des services de CTO et de gestion de produits. Fidèles à nos services de CTO, nous travaillons avec des startups et des entreprises établies dans les pays nordiques, en Suisse et aux États-Unis.
Nous sommes une société suisse (LLC) basée en 
Suisse.