Flux
Toutes les sources

Jérémy Decool

47 articles Flux RSS
Programmation Web
Utilisez le produit que vous construisez

Utilisez le produit que vous construisez

Il existe une pratique que j’apprécie particulièrement et qui reste pour moi le meilleur moyen de repérer les problèmes d’un produit, se nomme le “dog fooding”. Elle consiste à utiliser ses propres produits et services. C’est malheureusement une pratique que je vois trop peu utilisée. Et encore plus avec l’usage de l’IA où les développeurs font plus facilement confiance au code et aux tests générés. Les équipes de développement ont tendance à rester focus sur le code et à ne plus ouvrir…

Jérémy Decool
Se former fait partie du travail

Se former fait partie du travail

Dans la lignée de ma publication précédente sur les side projects, il existe une autre injonction qui poursuit les développeurs: la veille technique. Et non, elle ne devrait pas reposer sur le temps personnel. C’est pourtant une attente implicite dans beaucoup d’équipes. Le développeur “passionné”, c’est celui qui lit des articles le soir, qui suit les nouveautés le week-end, qui teste le dernier framework pendant ses congés. Celui qui ne le fait pas décroche, et ce sera à lui de rattraper le…

Jérémy Decool
Le mythe du side project obligatoire

Le mythe du side project obligatoire

Il y a un mythe fortement ancré dans la tête des développeurs, sur l’importance d’avoir des side projects. Cassons-le immédiatement. Non, il n’est pas obligatoire d’avoir un side project pour être un bon développeur. C’est une injonction que j’entends régulièrement: avoir un profil Github vide serait le signe d’un manque de passion ou d’implication. On voit même parfois passer des offres d’emploi où il est fortement recommandé d’avoir un side project. Bien entendu, quand l’envie est là, un side…

Jérémy Decool
L'IA déplace les frontières de chaque métier

L'IA déplace les frontières de chaque métier

J’aborde régulièrement l’IA sous l’angle du développeur et du bouleversement que cela représente dans notre métier. Mais nous ne sommes pas les seuls concernés. C’est l’ensemble des métiers du logiciel qui évolue. Puisque l’écriture du code occupe moins de place, les développeurs se recentrent sur le produit. Ils questionnent davantage les besoins, challengent les spécifications, proposent des alternatives fonctionnelles. Autrement dit, ils font dorénavant une partie du travail qui était…

Jérémy Decool
Filtrer une collection Doctrine

Filtrer une collection Doctrine

Quand on doit filtrer une collection Doctrine, le premier réflexe est d’utiliser la méthode filter(). Simple et pratique, le code est plus court et lisible qu’une boucle traditionnelle. #[ORM\Entity] class Project { #[ORM\OneToMany(targetEntity: Task::class)] private Collection $tasks; public function getPendingTasks(): Collection { return $this->tasks->filter( static fn (Task $task): bool => !$task->isDone(), ); } } Néanmoins cette méthode de filtrage peut ne pas être sans conséquences. Les…

Jérémy Decool
Penser problème avant de penser solution

Penser problème avant de penser solution

En tant que développeur, quand on démarre une tâche ou un projet, on pense facilement au framework que l’on va utiliser, à la base de données, aux patterns que l’on va pouvoir mettre en place. Et si c’était une erreur ? Car en réfléchissant de la sorte, on prend déjà des décisions avant même que le problème ne soit posé. On choisit une solution, une architecture, un outil, et ensuite on cherche la justification. N’est-ce pas penser à l’envers ? Penser problème avant de penser solution, c’est…

Jérémy Decool
Écrire du code avec l'IA, c'est la partie facile

Écrire du code avec l'IA, c'est la partie facile

On parle de plus en plus de dépendance à l’IA : du code produit “trop vite” et en trop grande quantité, que l’on ne comprend pas ou que l’on ne sait plus maintenir. Mais est-ce vraiment un problème d’IA ? Avant elle, on copiait déjà du code trouvé sur StackOverflow sans le comprendre. On reprenait déjà des projets dont plus personne ne connaissait les choix d’architecture. On livrait déjà des fonctionnalités sans test. Depuis des années, nous avons les mêmes problèmes, seuls le volume et la…

Jérémy Decool
L'IA n'a pas votre vécu

L'IA n'a pas votre vécu

J’ai évoqué dans une publication précédente, l’usage de l’IA par les leaders pour construire leurs arguments, et la perte d’authenticité que cela entraîne. J’ai exactement le même sentiment côté technique. De plus en plus, je vois des développeurs avancer des arguments qu’ils n’ont pas construits. Des réponses générées, structurées, bien tournées, mais qui ne sont pas les leurs. Et tout comme pour les leaders, cela désincarne les propos et leur fait perdre en crédibilité. La discussion s’engage…

Jérémy Decool
Les meilleures idées ne viennent pas devant l'écran

Les meilleures idées ne viennent pas devant l'écran

Je vais régulièrement courir. Pas pour la performance, juste pour m’aérer l’esprit et être un minimum mobile, plutôt que de camper devant mon écran. Paradoxalement, c’est à ce moment que j’ai les meilleures idées qui me viennent à l’esprit. Je pense que tous les développeurs ont connu cette situation où l’on n’arrive pas à résoudre un bug incompréhensible, ou celle où l’on tourne en rond sur une décision technique à prendre. Souvent, plus on s’acharne et moins on avance. On refait les mêmes…

Jérémy Decool
Ce n'est pas le titre qui définit le poste, c'est ce qu'on en fait

Ce n'est pas le titre qui définit le poste, c'est ce qu'on en fait

Il y a quelque temps, je faisais passer des entretiens pour un poste. J’ai pu rencontrer de nombreux profils: développeur, “lead dev” ou “architecte” et derrière ces titres des réalités bien différentes (même à titre équivalent). Certains pouvaient passer leurs journées à écrire du code, d’autres ne pouvaient faire que des revues. Parfois, ils ne codaient pas du tout et ils devaient gérer des plannings. Les intitulés de postes sont souvent équivalent, mais les métiers exercés n’ont parfois rien…

Jérémy Decool
Convaincre ne se délègue pas à l'IA

Convaincre ne se délègue pas à l'IA

Depuis quelques mois, je repère de plus en plus de documents et de présentations de leads et de directeurs rédigés à coups d’IA. Ce n’est pas forcément gênant, mais le problème, c’est quand ça se voit de trop. Il y a un style d’écriture qui trahit l’outil. Une certaine structure et des types de tournures qui se remarquent. Le texte est cohérent, mais il est désincarné. Selon le type de document, cela ne me dérange pas. Documenter une procédure, résumer une architecture, formaliser un…

Jérémy Decool
Attention au bruit documentaire généré par l'IA

Attention au bruit documentaire généré par l'IA

Avec l’IA, on parle beaucoup de la rapidité et de la vitesse de génération de code. Mais, tout comme le code, générer de la documentation n’a jamais été aussi simple et rapide. En quelques secondes, l’IA produit des pages entières décrivant un projet. Mais attention à cette abondance. Comme beaucoup, je suis convaincu de l’importance de documenter: choix d’architecture, standard d’équipe, historique et choix des décisions. La documentation est primordiale pour maintenir la connaissance au fil…

Jérémy Decool
Pousser une fois, publier partout: le remote Git multi-cibles

Pousser une fois, publier partout: le remote Git multi-cibles

Bien que cela commence à changer, Github reste aujourd’hui la forge de référence pour l’hébergement de projet autour de Git. Néanmoins, dans une démarche d’autonomie numérique, je ne souhaite pas dépendre uniquement de cette plateforme. Pour réduire cette dépendance, j’ai décidé de dupliquer et “mirrorer” l’ensemble de mes dépôts (publics et privés) sur Codeberg, une forge européenne et associative. On a l’habitude de voir un remote Git comme étant une simple association avec une URL (un remote…

Jérémy Decool
Courir après la fonctionnalité n'est pas un objectif

Courir après la fonctionnalité n'est pas un objectif

L’IA permet à de nombreux éditeurs logiciels de livrer de nouvelles fonctionnalités toujours plus rapidement. Elle a augmenté la vitesse de production logicielle. La tentation de toujours aller plus vite est alors grande. Les nouvelles fonctionnalités d’un logiciel étant souvent perçu comme un avantage concurrentiel. Plus il en propose, plus il semble riche et plus il paraît compétitif. Le problème, c’est que livrer des fonctionnalités rapidement et fréquemment est compliqué. Cela se fait…

Jérémy Decool
La Clean Architecture ne se résume pas à une arborescence de dossiers

La Clean Architecture ne se résume pas à une arborescence de dossiers

Pour beaucoup, la Clean Architecture se résume à un découpage du code en 3 couches: Domain, Application et Infrastructure (avec éventuellement une couche de présentation). Pourtant, si l’on regarde le livre de référence sur le sujet, “Clean Architecture” de Robert C. Martin, ce découpage ne représente qu’une dizaine de pages sur les 400 que compte le livre. L’organisation du projet est certainement la partie la plus visible de la Clean Architecture. C’est d’ailleurs ce qui en a fait son succès:…

Jérémy Decool