DEV Community: Rodolphe D.

Le projet qui fonctionnait… mais que je détestais modifier

Rodolphe D. — Thu, 28 May 2026 09:03:22 +0000

Il y a un moment que tous les développeurs finissent par vivre.

Celui où ton projet fonctionne parfaitement.

Les routes répondent.

La base de données est connectée.

Les features font exactement ce que tu as prévu.

Et pourtant… tu n’as aucune envie d’y retourner.

“Ça marche” n’est pas une victoire

Je me souviens très bien de ce projet.

Une API Node.js avec Express, PostgreSQL derrière, un peu de Sequelize pour faire propre.

Rien de compliqué.

Au début, tout était fluide.

Tu codes, ça marche, tu avances.

Tu as cette sensation agréable de progression rapide.

Et puis un jour, tu reviens dessus.

Juste pour ajouter une petite fonctionnalité.

Et là… quelque chose change.

Tu ouvres le projet.

Tu regardes une route.

Puis une autre.

Et sans trop comprendre pourquoi, tu sens une forme de blocage.

Pas technique.

Mental.

Le vrai problème n’était pas le code

Sur le moment, je me disais que ça allait.

“C’est normal, c’est un petit projet.”

Mais en réalité, le problème était déjà là.

Mes routes faisaient tout.

Un peu de logique métier ici.

Un appel base de données là.

Une gestion d’erreur bricolée dans un coin.

Rien n’était vraiment structuré.

Mais comme tout fonctionnait… je ne voyais pas le problème.

Jusqu’au jour où j’ai voulu modifier un truc simple

Je voulais juste ajouter une fonctionnalité.

Rien de fou.

Un champ en plus, une petite logique.

Et pourtant, j’ai commencé à hésiter.

“Si je change ça… qu’est-ce que je vais casser ?”

Et c’est là que j’ai compris un truc assez dérangeant.

Mon code fonctionnait… mais je ne lui faisais plus confiance.

Le moment un peu bizarre où tu réalises que tu subis ton propre code

C’est difficile à expliquer.

Tu n’as pas d’erreur.

Pas de bug bloquant.

Mais tu avances avec prudence.

Comme si chaque modification pouvait déclencher une réaction en chaîne.

Et ça, pour un développeur, c’est un signal très clair.

Quelque chose ne va pas dans la structure.

Le premier déclic : arrêter de tout mettre au même endroit

Je n’ai pas tout refactorisé d’un coup.

Personne ne fait ça proprement.

J’ai commencé petit.

Une seule chose : arrêter de mettre toute la logique dans les routes.

Avant, j’avais un truc comme ça :

router.post('/events', async (req, res) => {
  const event = await Event.create(req.body);
  res.json(event);
});

Et dès que ça grossit un peu, ça devient vite ingérable.
Validation, règles métier, permissions… tout finit empilé.

Le changement n’était pas spectaculaire

J’ai juste déplacé la logique.

Un service.

Un contrôleur.

Rien de magique.

// controller
const createEvent = async (req, res) => {
  const event = await eventService.createEvent(req.body);
  res.json(event);
};

// service
const createEvent = async (data) => {
  return Event.create(data);
};

Et honnêtement ?

À ce moment-là, je n’ai pas eu de révélation.

Pas de “wow”.

Juste un truc très simple :

“ok… c’est plus clair.”

Mais le vrai changement est venu après

Le vrai test, ce n’est pas quand tu refactorises.

C’est deux semaines après.

Quand tu reviens dans ton projet.

Et que tu comprends ce que tu as fait sans relire 15 fichiers.

Là, j’ai senti la différence.

Moins de stress.

Moins d’hésitation.

Moins de “je touche ou pas ?”

Ce que j’ai compris à ce moment-là

Ce n’est pas la complexité du code qui pose problème.

C’est le chaos invisible.

Quand tout est mélangé, ton cerveau doit tout retenir en même temps :

logique métier
requêtes SQL
gestion HTTP
erreurs
règles implicites

Et ça fatigue.

Sans que tu t’en rendes compte.

Et pourtant… ce projet fonctionnait parfaitement

C’est ça le piège.

Le code peut être “bon” techniquement.

Mais mauvais à vivre.

Et à un moment, en tant que développeur, tu fais la différence entre :

un projet qui marche
et un projet avec lequel tu peux travailler sereinement

La suite a changé ma façon de coder

Ce petit refactor m’a ouvert une porte.

Après ça, je ne regardais plus mes projets de la même façon.

Je ne cherchais plus juste à “faire fonctionner”.

Je commençais à me demander :

“est-ce que je vais comprendre ça dans 2 semaines ?”
“est-ce que quelqu’un d’autre peut lire ça facilement ?”
“est-ce que je suis en train de créer du chaos sans m’en rendre compte ?”

Et c’est là que tout commence vraiment

Pas quand tu sais coder une API.

Pas quand tu sais utiliser un ORM.

Mais quand tu commences à ressentir ton propre code.

Quand tu sais, instinctivement, qu’un projet va devenir lourd… avant même qu’il le devienne.

👉 Dans le prochain article, on parlera d’un truc encore plus vicieux :

les routes Express qui deviennent illisibles sans qu’on s’en rende compte.

Comment structurer une API simple avec Go pour plus de clarté

Rodolphe D. — Tue, 26 May 2026 08:15:00 +0000

Quand on apprend à construire des backends, on a souvent le même réflexe : ajouter des couches.

Frameworks, abstractions, middlewares, services…

Et petit à petit, on finit parfois par perdre de vue quelque chose de très simple :

ce que fait réellement une API.

🧠 Revenir à l’essentiel

Go m’a forcé à revenir à cette base.

Pas parce qu’il est “magique” ou “révolutionnaire”.

Mais parce qu’il est explicite.

Tout est plus direct :

une requête arrive
elle est traitée par une fonction
une réponse est renvoyée

Et c’est tout.

🔁 Le cycle réel d’une requête HTTP

Si on simplifie au maximum, une API fonctionne toujours de la même manière :

Une requête HTTP arrive sur le serveur
Elle est dirigée vers un handler
Le handler exécute une logique métier
Une réponse est renvoyée au format JSON

Ce schéma ne change jamais.

Ce qui change, c’est la manière dont on le rend complexe.

🧩 Le rôle du handler en Go

En Go, un handler est juste une fonction.

Pas une couche abstraite.

Pas un système caché.

Juste une fonction qui :

reçoit une requête
traite une logique
retourne une réponse

Ce découpage impose une discipline naturelle :

peu de magie
peu d’indirection
beaucoup de lisibilité

⚙️ Ce que ça change dans ta manière de coder

Quand tu commences à structurer tes backends en Go, tu observes un changement progressif :

tu penses en flux (request → process → response)
tu réduis les couches inutiles
tu rends les responsabilités plus claires

Et surtout, tu réalises quelque chose :

la complexité ne vient pas du langage, mais de la manière dont on structure les choses.

📌 Ce qu’il faut retenir

Go ne rend pas le backend “plus simple”.

Il le rend plus lisible.

Et cette lisibilité change tout :

tu comprends ce que tu fais
tu maintiens plus facilement
tu évites les sur-architectures inutiles

🧭 Conclusion

Si tu viens d’un écosystème comme Node.js, PHP ou Ruby, cette approche peut sembler un peu plus stricte au début.

Mais cette “rigidité” est souvent ce qui manque pour retrouver de la clarté.

Go n’ajoute pas de complexité.

Il en enlève.

Et parfois, c’est exactement ce dont on a besoin pour construire des systèmes plus sains.

Common backend mistakes I keep seeing from students

Rodolphe D. — Thu, 21 May 2026 17:30:57 +0000

TL;DR

Most beginner backend issues come down to 5 things:

messy APIs that don’t scale
weak SQL habits
security added too late
no code structure
bad error handling

Fix these early and you’ll already be ahead of most juniors.

When you start backend dev, the goal is simple: make it work.

And honestly, that’s fine at the beginning.

But after reviewing a lot of student projects, you start noticing the same patterns over and over again.

Here are the most common ones.

🧵 APIs that “work”, but don’t scale

Most beginners build APIs that return everything, everywhere, all the time.

You’ll see things like:

endpoints that dump full database objects
no pagination at all
multiple DB calls for simple requests

It’s not a problem… until traffic grows or data increases.

Then everything slows down, and nobody understands why.

🧵 SQL used without thinking

SQL is usually learned fast, then ignored in practice.

Common patterns:

SELECT * everywhere
no indexes
joins stacked without thinking about cost
“it works on my machine” queries

It’s fine for small projects, but it doesn’t scale.

🧵 Security added at the end (if at all)

A lot of projects treat security like a final step.

That leads to:

plain text passwords
no validation on inputs
weak or incorrect JWT handling
no rate limiting

Security should be part of the design, not a patch.

🧵 No real structure in the code

Everything ends up inside controllers.

At first it feels fast.

Then:

logic gets duplicated
nothing is reusable
testing becomes painful
adding features starts breaking things

That’s usually the moment people discover “clean architecture” exists.

🧵 Error handling that doesn’t help

This one is very common.

everything returns 500
no logs
useless error messages
no distinction between client and server errors

When something breaks in production, debugging becomes guesswork.

💬 Final thoughts

None of this is dramatic. Everyone goes through it.

The real issue is staying in that phase too long.

If you fix even half of these early, you’ll already be ahead of most junior backend devs.

🤝 Let’s build better backend habits together

I’m trying to collect real-world mistakes and patterns from devs at all levels.

If you’ve seen other common backend mistakes (or made some yourself 😅), drop them in the comments.

Let’s build a list that actually helps juniors improve.

Once upon a time there was web development

Rodolphe D. — Fri, 10 Jan 2020 13:25:42 +0000

Hello everyone, it's okay, I finally decided to write a post...
I'm a bit anxious because usually I still think I have nothing interesting to say. But I'm forced to admit that some of the people I work with on a daily basis are happy to hear my adventures.( So i come from France excuse my English)
So I'm going to talk subjectively here about certain subjects.
To begin with, we'll talk about learning.
Learning something new can be exciting, but it can also be difficult. We expected that we would spend some time each day or each week learning something about a specific topic. We all aspire to some mastery of the subject we choose. If you're like me, you'll feel frustrated when your study time doesn't allow you to learn as much as the day before, but that's natural and it's part of the process. Learning is not linear.

Learning by repetition

Some things we learn simply by doing them over and over again. I'd be willing to bet you can add 2 and 3 in your head without even thinking about it. But why is that? It's because you've done it so much in your life that you don't even have to think about it. That's kind of the way you have to code. If you go on long enough, through repetition, you'll begin to be able to do things easily that you've had to make a concerted effort to do before. If you don't, you probably won't be able to pinpoint the exact time when it made sense to you. One way or another, over the course of rehearsals, it does.

Cliff Climbing

On the other hand, some ideas are more abstract. There will probably be a time in your learning when you notice that things will become much more difficult. These situations tend to occur when concepts come into play. You've learned the basics, but now you have to put them together to design a solution to a problem. In my experience, it's a bit like standing at the bottom of a cliff. This is where I felt the most frustration in my learning process.
But there is good news. It can be overcome, and you can climb that cliff! I have personally experienced situations where I simply couldn't grasp a concept. I may have heard twenty explanations and seen twenty examples on the same subject. For some unknown reason, perhaps it is the twenty-first explanation and the twenty-first example that enlightens me. In most cases, there is nothing very different between this example and those I have already seen. I have sat in my office and said, "Oh, when it finally hits me and the concept crystallizes like never before. The good thing about those moments is that once you understand the idea, it's hard to forget it.
When you understand a concept, your learning is not so much a curve as a vertical jump.

The thing we should unlearn

Humans are not born believing that they can never get smarter. This is something we learn in our lifetime, and it is something we should all unlearn. If you've ever seen a child tackle a puzzle, you'll have an idea of what I mean. A child will get bored with an easy problem, but will deal with a difficult one. On the other hand, an adult is likely to raise his or her hands in frustration and walk away from the problem. The instinct we are born with is that we can get the solution with enough time, effort and resources.
Alfred Binet, the inventor of the first practical IQ test, believed that intelligence was changeable. In his book, we can find this quote: "Some modern philosophers assert that the intelligence of an individual is a fixed quantity, a quantity that cannot be increased. We must protest and react against this brutal pessimism... With practice, training, and above all method, we can increase our attention, memory, judgment and literally become more intelligent than before."
You may be working on a piece of code or an idea that you haven't fully grasped yet. You might be thinking to yourself, "I'm not smart enough to do this". I always think that when I'm stuck. I take comfort in knowing that my inability to solve the problem is probably not permanent. It's something that can change with time, effort and resources.

Memorizing is mostly wasteful

People have repeatedly asked me what I think are the most important things to remember when learning to program. My answer: practically nothing. Anything that might be important enough to be memorized will naturally occur by repetition, as mentioned above. If you don't use a particular thing in your programs often enough to learn it by repetition, it's not worth the effort to memorize it either.
Coming back to my mathematical example, you have probably memorized 2 + 3. I'm assuming you didn't memorize 29,083,983 + 3,497,267. And why is that? It's because you get the idea behind the addition. You know how addition works as a concept, so you can use it on any number you are given. This is an example of wasted memorization.
Programmers, in general, do not rely on memorizing every construction, every parameter, every object, method and class. Instead, we use our resources combined with the concepts we have learned to produce the result. That's why documentation is so valuable, and you'll hear programmers talk about it a lot. I bet very few people memorize all the recipes in a cookbook. If we want to cook something else, we read the cookbook. It's the same idea. If a programmer had to memorize everything in one language, we wouldn't have programmers.

Keep moving forward

Don't stop learning. Even if you've been stuck on a problem or project for weeks, don't stop learning. You may need to go back and review some of your basics. You may need another source to change your pace. Try reading an explanation on Medium or search for something on YouTube. Maybe even do some generic Googling. You might even try to learn something else about the language/platform/IDE and get back to where you were stuck. Keep pushing against that wall. Eventually, you'll have a breakthrough, and it will probably be something you won't easily forget. It's worth the time and effort, even if you don't get immediate results.
Programming can be hard to learn, but it can also be incredibly fun and more creative than non-programmers understand. If you are interested and dedicated enough, you will see progress. The next step may be your breaking point, but you'll never know if you don't take that step.