Moins de fichiers, plus de lignes contre plus de fichiers, moins de lignes de code

Ah, le débat classique des développeurs : ** « Moins de fichiers avec plus de lignes » contre « Plus de fichiers avec moins de lignes ». C’est comme choisir les garnitures d’une pizza : chacun a ses préférences et personne n’est jamais pleinement satisfait.

Lors de l'organisation du code pour une pull request (PR), certains préfèrent la simplicité de conserver les éléments au même endroit, tandis que d'autres préfèrent le diviser en fichiers plus petits et ciblés.

En fin de compte, il ne s'agit pas seulement de vous, il s'agit de sauver l'avenir, vous et votre équipe, du démêlage d'une base de code désordonnée plus tard.

Plongeons-nous dans un scénario pratique. Imaginez qu'un développeur soit chargé d'afficher une liste de widgets sur une page de tableau de bord. Voici la mise en œuvre initiale :

// Dashboard.js
export default function Dashboard() {
 const widgets = getWidgets();

  // Handles widget deletion
  const handleDelete = (id) => {};

  // Handles widget title update
  const handleUpdate = (id, newTitle) => {};

  return (
    <div>
      <h1>Dashboard</h1>
      <div className="widget-container">
        {widgets.map((widget) => (
          <div className="widget">
                  <h2>{widget.title}</h2>
                  <p>{widget.description}</p>
                  <span onClick={handleDelete}>?️</span>
                  <span onClick={handleUpdate}>✎</span>
          </div>
        ))}
      </div>
    </div>
  );
}

Lors d'une révision, quelqu'un suggère de séparer la logique de rendu des widgets individuels en leurs propres composants. Le développeur refactorise le code comme suit :

// Dashboard.js
export default function Dashboard() {
  const widgets = getWidgets();

  // Handles widget deletion
  const handleDelete = (id) => {};

  // Handles widget title update
  const handleUpdate = (id, newTitle) => {};

  return (
    <div>
      <h1>Dashboard</h1>
      <div className="widget-container">
        {widgets.map((widget) => (
          <Widget
            key={widget.id}
            widget={widget}
            onDelete={handleDelete}
            onUpdate={handleUpdate}
          />
        ))}
      </div>
    </div>
  );
}

// Widget component for individual widget
function Widget({ widget, onDelete, onUpdate }) {
  return (
    <div className="widget">
      <h2>{widget.title}</h2>
      <p>{widget.description}</p>
      <button onClick={() => onDelete(widget.id)}>?️</button>
      <button onClick={() => onUpdate(widget.id, "New Title")}>✏️</button>
    </div>
  );
}

// Can be even further moved to a separate file
// Widget.js
export default function Widget({ widget, onDelete, onUpdate }) {
  return (
    <div className="widget">
      <h2>{widget.title}</h2>
      <p>{widget.description}</p>
      <button onClick={() => onDelete(widget.id)}>?️</button>
      <button onClick={() => onUpdate(widget.id, "New Title")}>✏️</button>
    </div>
  );
}

La mise en œuvre initiale ne semblait-elle pas plus simple et plus directe, en particulier lorsque une logique supplémentaire, telle que la gestion des analyses, est étroitement liée au widget, ce qui entraîne une augmentation des accessoires et un changement de contexte ? ? Cela soulève une question importante : quelle approche le composant Dashboard doit-il adopter ? Doit-il conserver l’implémentation en ligne, adopter la structure refactorisée ou opter pour une approche hybride ? ?

---

Quand conserver les composants dans le même fichier

1. Petit projet ou responsabilité unique :
   • Si le composant DashBoard est étroitement couplé au composant Widget et que votre projet est petit, les garder ensemble réduit la complexité inutile.
2. La réutilisation est peu probable :
   • Lorsque le composant Widget ne sera pas réutilisé ailleurs, le séparer n'apporte que peu d'avantages.
3. Lisibilité :
   • Pour les composants plus petits, un seul fichier facilite la compréhension de la relation entre les composants sans changement de contexte.
4. Éviter les frais généraux :
   • Les composants en ligne éliminent les instructions d'importation/exportation supplémentaires, réduisant ainsi le code passe-partout dans les configurations simples.

---

Quand utiliser des fichiers séparés

1. Réutilisabilité :
   • Si le composant Widget peut être utilisé ailleurs, un fichier distinct le rend plus accessible et plus gérable.
2. Lisibilité et organisation du code :
   • À mesure que les fichiers grossissent, les diviser en morceaux logiques plus petits améliore la navigation et réduit la charge cognitive, en particulier dans les projets plus volumineux.
3. Tests et maintenance :
   • Les composants isolés dans des fichiers séparés sont plus faciles à tester unitairement, ce qui conduit à une meilleure couverture et maintenabilité des tests.
4. Séparation des préoccupations :
   • Suite au principe de responsabilité unique, des fichiers séparés garantissent que chaque composant a un objectif clair et distinct, crucial pour la maintenabilité à long terme.
5. Évolutivité :
   • La division des composants en fichiers séparés garantit que la base de code reste gérable à mesure que le projet se développe, permettant ainsi l'ajout transparent de nouvelles fonctionnalités sans perturber les fonctionnalités existantes

---

Prendre la décision

Pour cet exemple de DashBoard, votre choix dépend de l'échelle du projet et du rôle prévu du composant. Comme il s'agit d'un petit exemple où le widget ne sera pas réutilisé, un seul fichier fonctionne bien :

// Dashboard.js
export default function Dashboard() {
 const widgets = getWidgets();

  // Handles widget deletion
  const handleDelete = (id) => {};

  // Handles widget title update
  const handleUpdate = (id, newTitle) => {};

  return (
    <div>
      <h1>Dashboard</h1>
      <div className="widget-container">
        {widgets.map((widget) => (
          <div className="widget">
                  <h2>{widget.title}</h2>
                  <p>{widget.description}</p>
                  <span onClick={handleDelete}>?️</span>
                  <span onClick={handleUpdate}>✎</span>
          </div>
        ))}
      </div>
    </div>
  );
}

Pour les projets plus importants ou en croissance, séparer le Widget sera bénéfique en termes de flexibilité et de maintenabilité

Points clés à retenir

L'équilibre entre « plus de lignes dans un seul fichier » et « plus de fichiers avec moins de lignes » dépend de la portée de votre projet, de la taille de l'équipe et de la trajectoire de croissance. Tenez compte des éléments suivants au moment de décider :

• Le composant est-il susceptible d'être réutilisé ?
• Quelle est la complexité du fichier parent ?
• Le projet suit-il des conventions ou des modèles de conception spécifiques ?
• La base de code évoluera-t-elle considérablement au fil du temps ?

Si quelqu'un suggère de déplacer un composant vers un fichier séparé lors d'un examen PR, vérifiez si les avantages correspondent à ces considérations.

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!