Weniger Dateien, mehr Zeilen im Vergleich zu mehr Dateien, weniger Codezeilen

Ah, die klassische Entwicklerdebatte: **„Weniger Dateien mit mehr Zeilen“ vs. „Mehr Dateien mit weniger Zeilen.“ Es ist, als würde man den Belag für eine Pizza auswählen – jeder hat seine Vorlieben und niemand ist jemals ganz zufrieden.

Beim Organisieren von Code für eine Pull-Anfrage (PR) bevorzugen einige die Einfachheit, die Dinge an einem Ort aufzubewahren, während andere es vorziehen, ihn in kleinere, fokussierte Dateien aufzuteilen.

Letztendlich geht es nicht nur um Sie – es geht darum, die Zukunft – Sie und Ihr Team – davor zu bewahren, später eine unordentliche Codebasis zu entwirren.

Lassen Sie uns in ein praktisches Szenario eintauchen. Stellen Sie sich vor, ein Entwickler hätte die Aufgabe, eine Liste von Widgets auf einer Dashboard-Seite zu rendern. Hier ist die erste Implementierung:

// 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 id="Dashboard">Dashboard</h1>
      <div classname="widget-container">
        {widgets.map((widget) => (
          <div classname="widget">
                  <h2 id="widget-title">{widget.title}</h2>
                  <p>{widget.description}</p>
                  <span onclick="{handleDelete}">?️</span>
                  <span onclick="{handleUpdate}">✎</span>
          </div>
        ))}
      </div>
    </div>
  );
}

Während einer Überprüfung schlägt jemand vor, die Logik zum Rendern einzelner Widgets in ihre eigenen Komponenten aufzuteilen. Der Entwickler überarbeitet den Code wie folgt:

// 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 id="Dashboard">Dashboard</h1>
      <div classname="widget-container">
        {widgets.map((widget) => (
          <widget key="{widget.id}" widget="{widget}" ondelete="{handleDelete}" onupdate="{handleUpdate}"></widget>
        ))}
      </div>
    </div>
  );
}

// Widget component for individual widget
function Widget({ widget, onDelete, onUpdate }) {
  return (
    <div classname="widget">
      <h2 id="widget-title">{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 id="widget-title">{widget.title}</h2>
      <p>{widget.description}</p>
      <button onclick="{()"> onDelete(widget.id)}>?️</button>
      <button onclick="{()"> onUpdate(widget.id, "New Title")}>✏️</button>
    </div>
  );
}

Erscheinte die anfängliche Implementierung nicht einfacher und unkomplizierter, insbesondere wenn zusätzliche Logik – wie die Handhabung von Analysen – eng mit dem Widget verknüpft ist, was zu mehr Requisiten und Kontextwechseln führt? ? Dies wirft eine wichtige Frage auf: Welchen Ansatz sollte die Dashboard-Komponente verfolgen? Sollte es die Inline-Implementierung beibehalten, die umgestaltete Struktur übernehmen oder sich für einen Hybridansatz entscheiden? ?

---

Wann sollten Komponenten in derselben Datei aufbewahrt werden?

1. Kleines Projekt oder einzelne Verantwortung:
   • Wenn die DashBoard-Komponente eng mit der Widget-Komponente verbunden ist und Ihr Projekt klein ist, verringert die Zusammenhaltung der beiden unnötige Komplexität.
2. Wiederverwendbarkeit ist unwahrscheinlich:
   • Wenn die Widget-Komponente nicht an anderer Stelle wiederverwendet wird, bringt eine Trennung kaum Vorteile.
3. Lesbarkeit:
   • Bei kleineren Komponenten erleichtert eine einzelne Datei das Verständnis der Beziehung zwischen Komponenten ohne Kontextwechsel.
4. Overhead vermeiden:
   • Inline-Komponenten eliminieren zusätzliche Import-/Exportanweisungen und reduzieren den Boilerplate-Code in einfachen Setups.

---

Wann sollten separate Dateien verwendet werden?

1. Wiederverwendbarkeit:
   • Wenn die Widget-Komponente möglicherweise an anderer Stelle verwendet wird, ist sie durch eine separate Datei leichter zugänglich und verwaltbar.
2. Lesbarkeit und Organisation des Codes:
   • Wenn Dateien größer werden, verbessert die Aufteilung in kleinere, logische Teile die Navigation und reduziert die kognitive Belastung, insbesondere bei größeren Projekten.
3. Tests und Wartung:
   • Isolierte Komponenten in separaten Dateien lassen sich leichter Unit-Tests durchführen, was zu einer besseren Testabdeckung und Wartbarkeit führt.
4. Trennung der Belange:
   • Nach dem Prinzip der Einzelverantwortung stellen separate Dateien sicher, dass jede Komponente einen klaren, eindeutigen Zweck hat – entscheidend für die langfristige Wartbarkeit.
5. Skalierbarkeit:
   • Durch die Aufteilung der Komponenten in separate Dateien bleibt die Codebasis auch dann überschaubar, wenn das Projekt wächst, sodass neue Funktionen nahtlos hinzugefügt werden können, ohne dass bestehende Funktionen beeinträchtigt werden

---

Die Entscheidung treffen

Für dieses DashBoard-Beispiel hängt Ihre Wahl vom Umfang des Projekts und der beabsichtigten Rolle der Komponente ab. Da es sich um ein kleines Beispiel handelt, bei dem das Widget nicht wiederverwendet wird, funktioniert eine einzelne Datei gut:

// 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 id="Dashboard">Dashboard</h1>
      <div classname="widget-container">
        {widgets.map((widget) => (
          <div classname="widget">
                  <h2 id="widget-title">{widget.title}</h2>
                  <p>{widget.description}</p>
                  <span onclick="{handleDelete}">?️</span>
                  <span onclick="{handleUpdate}">✎</span>
          </div>
        ))}
      </div>
    </div>
  );
}

Bei größeren oder wachsenden Projekten ist die Trennung von Widget im Hinblick auf Flexibilität und Wartbarkeit von Vorteil

Wichtige Erkenntnisse

Das Gleichgewicht zwischen „mehr Zeilen in einer einzelnen Datei“ und „mehr Dateien mit weniger Zeilen“ hängt vom Umfang Ihres Projekts, der Teamgröße und dem Wachstumspfad ab. Berücksichtigen Sie bei Ihrer Entscheidung Folgendes:

• Ist es wahrscheinlich, dass die Komponente wiederverwendet wird?
• Wie komplex ist die übergeordnete Datei?
• Folgt das Projekt Konventionen oder bestimmten Designmustern?
• Wird die Codebasis im Laufe der Zeit deutlich skalieren?

Wenn jemand während einer PR-Überprüfung vorschlägt, eine Komponente in eine separate Datei zu verschieben, prüfen Sie noch einmal, ob die Vorteile mit diesen Überlegungen übereinstimmen.

Das obige ist der detaillierte Inhalt vonWeniger Dateien, mehr Zeilen im Vergleich zu mehr Dateien, weniger Codezeilen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!