Faites-le fonctionner, faites-le bien, faites-le vite

Nous sommes tous passés par là. Vous ouvrez votre IDE, vous fixez le curseur clignotant, et vous commencez à stresser.

"Est-ce que cette boucle for ne va pas être trop lente ?" "Devrais-je utiliser une classe ou une fonction fléchée ici ?" "Est-ce que cette architecture sera scalable pour 1 million d'utilisateurs ?"

Résultat ? Vous n'avez encore rien écrit que vous êtes déjà bloqué. C'est ce qu'on appelle la "paralysie de l'analyse".

Pour sortir de ce piège, il existe un mantra légendaire dans le développement logiciel, popularisé par Kent Beck : Make it work, Make it right, Make it fast.

En JavaScript, où la flexibilité est reine, ce principe est votre meilleur allié. Décortiquons-le ensemble.

1. Make it work (Fais en sorte que ça marche)

C'est la phase du "brouillon". Votre seul et unique but ici est de résoudre le problème fonctionnel. Oubliez l'élégance. Oubliez la performance. Oubliez le "Clean Code".

Si vous devez copier-coller un bout de code de StackOverflow pour vérifier une hypothèse, faites-le. Si vous devez écrire une fonction de 50 lignes avec des if imbriqués, allez-y.

L'exemple JS : Disons que vous devez filtrer une liste d'utilisateurs pour trouver ceux qui sont majeurs et formater leur nom.

// Phase 1 : C'est moche, mais ça marche.
function processUsers(users) {
  let results = [];
  for (let i = 0; i < users.length; i++) {
    if (users[i].age >= 18) {
      let fullName = users[i].firstName + " " + users[i].lastName;
      results.push(fullName.toUpperCase());
    }
  }
  return results;
}

Ce code est impératif, verbeux, et utilise une boucle classique. Mais il remplit le contrat. Le test passe au vert. ✅

Le conseil : Ne jugez pas votre code durant cette phase. Si la fonctionnalité est là, vous avez réussi l'étape 1.

2. Make it right (Fais-le bien)

Maintenant que vous avez l'esprit tranquille (le code fonctionne), c'est le moment de mettre votre casquette d'architecte. C'est ici qu'intervient le Refactoring.

L'objectif est de rendre le code lisible, maintenable et testable pour le "vous" du futur (qui vous détestera si vous laissez le code de l'étape 1).

Les actions à mener :

• Utiliser les fonctionnalités modernes de JS (ES6+).

• Améliorer le nommage des variables.

• Découper les fonctions trop longues.

L'exemple JS (Refactorisé) :

// Phase 2 : C'est propre, lisible et moderne.
const formatUserName = (user) => `${user.firstName} ${user.lastName}`.toUpperCase();

const getAdultUserNames = (users) => {
  return users
    .filter(user => user.age >= 18)
    .map(formatUserName);
};

On utilise filter et map pour une approche déclarative. On a extrait la logique de formatage. Le code raconte une histoire.

3. Make it fast (Fais-le vite)

C'est l'étape la plus dangereuse, et souvent la plus inutile. Donald Knuth disait : "L'optimisation prématurée est la racine de tous les maux".

Dans 90% des cas en développement Web, l'étape 2 suffit. Les moteurs JavaScript modernes (V8, SpiderMonkey) sont incroyablement rapides. Cependant, si vous traitez des milliers de données ou si vous constatez des ralentissements (lag) dans l'interface, alors—et seulement alors—vous optimisez.

L'exemple JS (Optimisé) : Imaginons que nous ayons 1 million d'utilisateurs. Chainer .filter() et .map() crée deux tableaux intermédiaires en mémoire. Pour la performance pure, on pourrait revenir à une approche plus bas niveau ou utiliser un reduce unique.

// Phase 3 : Optimisation mémoire (seulement si nécessaire !)
const getAdultUserNamesOptimized = (users) => {
  return users.reduce((acc, user) => {
    if (user.age >= 18) {
      acc.push(`${user.firstName} ${user.lastName}`.toUpperCase());
    }
    return acc;
  }, []);
};

On a sacrifié un tout petit peu de lisibilité pour gagner en performance (une seule itération sur le tableau au lieu de deux).

Pourquoi l'ordre est vital ?

Essayer de faire du "Fast" avant du "Work" vous mènera à passer 3 jours à configurer Webpack ou à optimiser un algorithme pour une fonctionnalité que le client finira par annuler.

Essayer de faire du "Right" avant du "Work" vous conduira à la sur-ingénierie (over-engineering). Vous créerez des classes abstraites pour des problèmes que vous n'avez pas encore.

En résumé :

1. Make it work : Soyez un bricoleur.

2. Make it right : Soyez un artisan.

3. Make it fast : Soyez un ingénieur de Formule 1 (mais seulement quand la course le demande).

Alors la prochaine fois que vous ouvrez votre éditeur de code, détendez-vous. Faites juste en sorte que ça marche. Le reste suivra.