Un code qui appartient à un musée, pas à un référentiel

"Pourquoi nous ne devrions pas célébrer le beau code"

Nous l’avons tous vu : un code si complexe et si intact dans sa structure qu’il appartient à un musée, pas à un dépôt. C’est le genre de code que vous regardez avec admiration pendant un moment… jusqu’à ce que vous réalisiez que vous devez le déboguer. Ensuite, comme le reste d’entre nous, simples mortels, vous vous demandez pourquoi quelqu’un a décidé d’écrire du JavaScript comme s’il écrivait le prochain grand roman américain.

Soyons clairs : un beau code n’est beau que s’il est utile. Si votre équipe a besoin d'un doctorat. dans la syntaxe ésotérique pour comprendre le fonctionnement d'une fonctionnalité, félicitations : vous avez créé un chef-d'œuvre que personne ne conservera jamais.

Voici pourquoi vous devriez résister à l’envie de créer du code trop intelligent et que faire à la place. Attachez votre ceinture ; des exemples arrivent.

L'attrait de l'élégance sur-conçue

Tout d'abord, examinons pourquoi les développeurs écrivent ce type de code.

• Ça fait du bien. Écrire du code intelligent gratte une démangeaison intellectuelle. C’est un moment de flexion, un moment « regarde ce que je peux faire ».
• Ça impressionne (certains) gens. Jusqu'à ce que ces mêmes personnes soient chargées de l'entretenir. Ensuite, cela les frustre.
• Cela montre de la maîtrise. Ou du moins c’est censé le faire. Mais la véritable maîtrise ne consiste pas à créer de la complexité ; il s'agit de résoudre des problèmes simplement.

Exemple 1 : La fonction d'usine « WTF »

Voici un joyau sur lequel je suis tombé récemment :

const createMultiplier = (x) => (y) => (z) => x * y * z;
const multiply = createMultiplier(2)(3);
console.log(multiply(4)); // Outputs 24

Beau ? Bien sûr. Mais bonne chance au développeur junior qui doit comprendre ce qui se passe ici. Trois couches de fonctions pour multiplier trois nombres ? Félicitations, vous avez fait de l'arithmétique un événement olympique.

Ne fais pas ça. Voici la même fonctionnalité écrite pour les humains :

function multiplyThreeNumbers(x, y, z) {
  return x * y * z;
}
console.log(multiplyThreeNumbers(2, 3, 4)); // Outputs 24

Lisible. Simple. Maintient la santé mentale de chacun.

Exemple 2 : La chaîne de promesses shakespearienne

Parlons maintenant des chaînes de promesses qui semblent avoir été écrites par Shakespeare :

fetch(url)
  .then((response) => response.json())
  .then((data) =>
    data.map((item) =>
      item.isActive
        ? { ...item, status: "active" }
        : { ...item, status: "inactive" }
    )
  )
  .then((updatedData) =>
    updatedData.reduce(
      (acc, curr) =>
        curr.status === "active"
          ? { ...acc, active: [...acc.active, curr] }
          : { ...acc, inactive: [...acc.inactive, curr] },
      { active: [], inactive: [] }
    )
  )
  .then((finalResult) => console.log(finalResult))
  .catch((error) => console.error(error));

Ce code fonctionne. Mais c’est aussi un crime contre quiconque doit l’entretenir. Pourquoi chaque étape de la transformation des données est-elle imbriquée dans la suivante comme une poupée russe ?

Refactorisons :

async function processData(url) {
  try {
    const response = await fetch(url);
    const data = await response.json();

    const updatedData = data.map((item) => ({
      ...item,
      status: item.isActive ? "active" : "inactive",
    }));

    const finalResult = updatedData.reduce(
      (acc, curr) => {
        if (curr.status === "active") {
          acc.active.push(curr);
        } else {
          acc.inactive.push(curr);
        }
        return acc;
      },
      { active: [], inactive: [] }
    );

    console.log(finalResult);
  } catch (error) {
    console.error(error);
  }
}
processData(url);

Diviser la logique en étapes rend le code lisible. Cela fait toujours la même chose, mais maintenant ce qui se passe à chaque étape est clair.

Pourquoi la simplicité est meilleure

En matière de logiciel, rappelez-vous cette règle d'or : votre code n'est pas un journal personnel. C’est un outil de communication. Si votre équipe ne peut pas le lire, elle ne peut pas l’utiliser. Et s’ils ne peuvent pas travailler avec, l’entreprise ne peut pas avancer.

Voici pourquoi la simplicité l'emporte :

1 Intégration plus rapide : les développeurs juniors ne devraient pas avoir besoin d'une pierre de Rosette pour comprendre votre code.
2 Débogage plus facile : lorsque des bogues surviennent (et ils le feront), une logique claire les rend plus faciles à identifier.
3 équipes plus heureuses : Personne n’aime se sentir stupide. Un code trop intelligent aliène vos coéquipiers.

Les plats à emporter

Écrivez le code comme si vous l'expliquiez à votre futur après une dure nuit de sommeil. Soyez gentil avec le prochain développeur qui devra lire votre travail, car il y a de fortes chances que ce développeur soit vous.

Un beau code ne dépend pas de son apparence sophistiquée ; il s’agit de l’efficacité avec laquelle il résout les problèmes. Rien de moins n’est qu’un exercice de vanité.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!