Chapitre 5.1
Le code

Quand on travaille avec des développeurs, on entend parler de "code" en permanence. Ils "codent", ils "poussent du code", ils font des "revues de code". Mais concrètement, c'est quoi, le code ? À quoi ça ressemble ?

Du texte, tout simplement

Le code source, c'est simplement du texte, écrit dans des fichiers que l'on peut ouvrir avec un éditeur basique. Il est composé de mots, de symboles et de chiffres, écrits ligne par ligne.

C'est un ensemble d'instructions écrites dans un langage que la machine peut interpréter.

function calculerPrixPanier(panier) {
    let total = 0

    for (let article of panier) {
        total = total + article.prix
    }

    return total
}

Ici, on parcourt une liste d'articles et on additionne leurs prix.

Programmer, c'est écrire des instructions précises, étape par étape, pour que l'ordinateur fasse exactement ce qu'on veut.

Les langages de programmation

Les ordinateurs ne comprennent qu'une seule chose : des suites de 0 et de 1 (le binaire). Écrire directement en binaire serait aussi pratique que de rédiger un contrat en morse. Les langages de programmation servent d'intermédiaire : ils permettent aux humains d'écrire des instructions lisibles, qui sont ensuite traduites automatiquement en binaire pour la machine.

Il existe des centaines de langages de programmation, avec chacun ses forces et ses domaines de prédilection :

• JavaScript et PHP : les principaux langages du web.
• Python : très populaire pour l'analyse de données et l'intelligence artificielle. Réputé pour sa simplicité de lecture.
• Java : le langage historique des grandes entreprises. Fiable, rigoureux, très répandu dans les banques et les assurances.
• C : le langage des systèmes. Il fait tourner les systèmes d'exploitation, les logiciels embarqués, les objets connectés.
• Rust, Go, Kotlin, Swift, Ruby, Cobol... : la liste est interminable.

Le choix d'un langage dépend du projet, de l'équipe et de l'écosystème existant. Il y a quelques décennies, chaque langage avait une utilité bien distincte. Aujourd'hui, les frontières sont beaucoup plus floues et la plupart permettent de faire à peu près les mêmes choses.

Le choix se fait selon :

• Le projet. Est-ce qu'on favorise les performances pour un système critique ? Est-ce qu'on veut un langage souple qui permet de sortir un produit rapidement ?
• L'écosystème. Si je travaille sur un projet d'IA, je vais privilégier un langage largement utilisé dans ce domaine, et disposant de nombreux outils et composants.
• Le marché. Il y a des phénomènes de mode plus ou moins long dans les technologies. Le projet pourrait parfaitement être réalisé en Ruby, mais à une époque où tout le monde veut faire du JavaScript, le recrutement serait plus difficile.

Ça, c'est la théorie. En pratique, bon nombre de projets et d'entreprises sont tout simplement démarrés dans le langage principal que pratique le fondateur.

Un développeur junior apprend généralement les bases de plusieurs langages. Ça lui permet de toucher un peu à tout et de voir les différents paradigmes de programmation. Les bases de conception et les bonnes pratiques sont très proches d'un langage à l'autre. Un développeur qui les maîtrise n'aura aucun mal à apprendre un nouveau langage et à être, en quelques semaines seulement, aussi performant qu'avec le langage qu'il côtoie depuis des années.

Du code au produit

Les fichiers de code sont organisés dans un ou plusieurs "projets". On peut voir un projet comme l'un des logiciels composant l'écosystème de l'entreprise. Par exemple, les projets "back office du service client", "site web" ou "gestionnaire des commandes". L'ensemble forme ce qu'on appelle la "codebase". Un projet peut contenir des dizaines, des centaines, voire des milliers de fichiers. Chaque fichier a un rôle : afficher une page, gérer les paiements, envoyer des emails, stocker des données...

Pour qu'un utilisateur puisse s'en servir, ce code doit être transformé et déployé sur une machine (serveur, téléphone...). C'est ce qu'on appelle la "mise en production".

Le travail des développeurs

Contrairement à ce qu'on pourrait imaginer, un développeur ne passe pas huit heures par jour à taper frénétiquement du code. L'écriture de code ne représente en réalité qu'une fraction du travail.

Ces dernières années, l'avènement des IA génératives a dressé une claire frontière entre les simples "pisseurs de code" et les vrais développeurs. N'importe qui peut maintenant demander à une IA d'écrire du code rapidement. Pour l'instant, il faut cependant toujours des compétences solides pour les guider pas à pas et concevoir des systèmes maintenables et évolutifs sur le long terme.

Et ces compétences ne sont pas forcément techniques ! Le travail de développeur, c'est, comme son nom l'indique, de développer une solution. Ça inclut la compréhension du métier pour traduire les besoins et formuler des propositions pertinentes. Certains développeurs se spécialisent d'ailleurs sur des domaines métiers et peuvent devenir de vraies références dans leur domaine.

Quelques tâches d'un développeur quand il ne code pas :

• Comprendre le besoin : discuter avec l'équipe produit, lire les spécifications, poser des questions pour s'assurer de bien comprendre ce qu'il faut construire, proposer des alternatives.
• Concevoir la solution : réfléchir à la meilleure façon d'implémenter une fonctionnalité. Où placer le code ? Comment l'organiser pour qu'il reste maintenable ?
• Débugger : chercher pourquoi quelque chose ne fonctionne pas. Aider le service client sur des cas bizarres.
• Tester : même si on met en place un maximum de tests automatiques, c'est toujours mieux de s'assurer manuellement que tout fonctionne.
• Conseiller : participer à des réunions de cadrage pour aider à mieux cerner un sujet, à prendre des décisions.
• Relire le code des autres : comme nous le verrons dans le chapitre suivant, la revue de code est une pratique courante dans les équipes.
• Apprendre : les technologies évoluent vite. Un développeur passe du temps à se former, lire de la documentation, tester de nouveaux outils.

De toute façon, un développeur ne pourrait physiquement pas coder toute la journée. Résoudre un problème technique est souvent un puzzle intellectuel. Il y a rarement une seule bonne solution, et deux développeurs résoudront le même problème de façons différentes. Certaines tâches triviales ne demandent pas trop d'énergie, mais la plupart du temps, l'effort cognitif est important. Nous fonctionnons plutôt par sessions de concentration intense de deux heures maximum. Certaines méthodes, comme Pomodoro, préconisent des sessions de 25 minutes, suivies de pauses régulières.

Pourquoi c'est difficile

Écrire du code qui fonctionne, c'est facile.
Écrire du code qui fonctionne, qui est lisible par les collègues, qui gère correctement les erreurs, qui tient la charge quand des milliers d'utilisateurs l'utilisent en même temps, et qui reste maintenable dans deux ans, c'est une autre histoire.

La complexité d'un logiciel ne vient pas de chaque morceau de code pris individuellement. Elle vient de l'interaction entre des milliers de morceaux, écrits par des dizaines de personnes, sur des mois ou des années. C'est comme un immeuble : poser une brique est simple, construire 30 étages qui ne s'effondrent pas demande de l'ingénierie.

C'est pour ça que les équipes de développement investissent autant dans leurs outils et leurs processus : versionnage du code, tests automatisés, revues de code, pipelines de déploiement... Tout ça existe pour maîtriser cette complexité.