Le métier de développeur est devenu à la fois très spécialisé et si vaste qu’il est facile de s’y perdre. Dernièrement, l'intelligence artificielle a fait l'objet d'une attention particulière dans les médias, alimentant même des prédictions inquiétantes de certains chercheurs. Certains ont évoqué un possible avenir où le développement de logiciels pourrait disparaître en tant que métier.

Cependant, réduire le rôle des développeurs à celui de simples "machines à coder" serait méconnaître la profondeur et la complexité de cette profession.

Nous ne sommes pas des machines à écrire du code, et notre expertise ne se limite pas à cela. Il est essentiel de rester à l'affût des pratiques émergentes ; cette démarche est couramment appelée veille technologique. Explorons les grands principes et courants de pensée actuels. Que prônent-ils, pourquoi sont-ils importants,
et quelle est leur philosophie ?

Ces principes, que l’on nomme intentionnellement « dogmes », regroupent à la fois des bonnes pratiques en développement web et des techniques visant à faciliter le travail du développeur. C’est parti !

Analyse en huit axes :

1 - Le Clean Code : Vers une meilleure lisibilité du code

En 2008, Robert C. Martin, surnommé Uncle Bob, publiait Clean Code, un ouvrage désormais incontournable. Cet ouvrage propose une série de principes et de conseils visant à rendre le code plus lisible et donc plus facile à maintenir. En structurant son code avec soin, le développeur favorise sa pérennité, sa clarté et sa réutilisation, éléments clés pour tout projet à long terme.

2 - L'Architecture Hexagonale et de la Clean Architecture : Une approche structurelle

L’architecture logicielle est une composante essentielle du métier. Pour garantir la viabilité d’une solution, il faut d’abord poser des fondations solides. Tout comme pour la construction d’une maison, où l’on commencerait par les fondations avant de s’attaquer aux murs et au toit, un logiciel doit être structuré avec soin dès le départ.
Voici deux approches :
  • Architecture Hexagonale 
L’architecture hexagonale isole la partie métier depuis l’extérieur de l’application. Cela signifie que toute logique applicative ne doit jamais dépendre directement d’un système externe, telle qu’une base de données par exemple. Cette isolation permet de créer une haute résistance au changement, car les modifications extérieures n’impacteront jamais la logique de l’application.
  • Clean Architecture 
La clean architecture a été concrétisée dans le livre « Clean Architecture : A Craftsman Guide to Software Structure and Design » paru en 2017 et signé une fois encore par Robert C. Martin. Cette architecture est très utilisée dans le cas de projets complexes et conséquents. Elle est généralement représentée sous forme de cercles concentriques, avec les entités au centre, les use cases autour, et les controllers plus haut, représentant les interactions externes.

3 - Les microservices : Une approche modulaire

Commençons par comparer cette architecture à son extrême opposé : le monolithe. Un monolithe est une application composée d’un seul gros bloc regroupant toutes les fonctionnalités inhérentes au programme. Son exact opposé, l’architecture en microservices, se décompose en plusieurs projets. Chaque microservice a une seule responsabilité bien définie, ce qui simplifie le code et les dépendances internes, facilite la maintenance et permet une meilleure résilience en cas de panne.

4 - L’Agile et le Software Craftsmanship : L'amélioration continue

Inspiré du livre The PragmaticProgrammer:FromJourneyman to Master d'Andy Hunt et Dave Thomas, ce mouvement valorise la maîtrise du métier. En 2008, Robert C. Martin a proposé une cinquième valeur au manifeste Agile : « Craftsmanship over execution » (« L’artisanat plutôt que l’exécution »), qui a donné naissance au manifeste du Software Craftsmanship. Il prône l'amélioration continue et l'implication active
dans l’évolution des pratiques.

5 - Le Domain Driven Design (DDD) : Adapter le code au domaine métier

Un des défis majeurs pour les développeurs est de bien comprendre le métier du client afin de répondre précisément à ses besoins. Le Domain Driven Design (DDD) impose l’utilisation du vocabulaire métier spécifique. Plus le code reflète le domaine, plus il sera facile d’identifier et de corriger les bugs, tout en facilitant les discussions avec le client. Les concepts clés incluent l'UbiquitousLanguage, l'EventStorming, la modélisation des Aggregats, Entities, et Value Objects.

6 - Le Test Driven Development (TDD) : Prioriser les tests

Le Test Driven Development (TDD) place les tests au centre du processus de développement. Il s’articule en trois phases :
  • Le développeur rédige un test définissant l’objectif à atteindre.

  • Ensuite, il écrit le code minimal nécessaire pour passer ce test.

  • Enfin, il refactorise le code si besoin.
Ce cycle garantit un code de meilleure qualité et plus maintenable.

7 - Le Behavior Driven Development (BDD) : Axé sur le comportement

Le Behavior Driven Development (BDD) est une évolution du TDD. Il vise à minimiser les erreurs comportementales et à renforcer la compréhension des attentes. Une technique de BDD consiste à réunir simultanément un expert métier, un développeur et un challenger pour définir les besoins et les attentes.

8 - Le Pair Programming et le Mob Programming : La force de la collaboration

Le pair programming (programmation en binôme) et le mob programming (programmation en groupe) permettent de résoudre des impasses, intégrer de nouveaux membres, et partager des connaissances. Le pilote écrit le code, tandis que le co-pilote guide le pilote en fournissant des indications sur la manière de résoudre le problème. Les rôles sont régulièrement échangés pour maximiser les perspectives et l'apprentissage mutuel.

Ces pratiques ne cessent d’évoluer, tout comme le métier de développeur lui-même. Les projets sont de plus en plus complexes et requièrent une connaissance approfondie des outils et des méthodes. En s’appuyant sur ces grands principes, les développeurs peuvent non seulement relever les défis techniques de demain, mais aussi enrichir leur expertise pour continuer à innover dans un domaine en constante mutation.

Par Florian Pouchelet, Ingénieur Conception & Développement chez SQLI