Code, der in ein Museum gehört, nicht in ein Repository

„Warum wir schönen Code nicht feiern sollten“

Wir haben es alle gesehen – Code, der in seiner Struktur so kompliziert und makellos ist, dass er in ein Museum und nicht in ein Repository gehört. Es ist die Art von Code, auf die man einen Moment lang voller Ehrfurcht starrt … bis einem klar wird, dass man ihn debuggen muss. Dann fragen Sie sich, wie der Rest von uns Normalsterblichen, warum jemand beschlossen hat, JavaScript zu schreiben, als ob er den nächsten großen amerikanischen Roman schreiben würde.

Lassen Sie uns eines klarstellen: Schöner Code ist nur dann schön, wenn er nützlich ist. Wenn Ihr Team einen Doktortitel benötigt. in Esoteric Syntax, um herauszufinden, wie eine Funktion funktioniert. Herzlichen Glückwunsch – Sie haben ein Meisterwerk geschaffen, das niemand jemals pflegen wird.

Hier erfahren Sie, warum Sie dem Drang, übermäßig cleveren Code zu erstellen, widerstehen sollten und was Sie stattdessen tun sollten. Schnall dich an; Beispiele kommen.

Der Reiz übertechnischer Eleganz

Lassen Sie uns zunächst untersuchen, warum Entwickler diese Art von Code schreiben.

• Es fühlt sich gut an. Das Schreiben von cleverem Code löst einen intellektuellen Juckreiz aus. Es ist ein Flex, ein „Schau, was ich tun kann“-Moment.
• Es beeindruckt (einige) Menschen. Bis dieselben Leute damit beauftragt werden, es aufrechtzuerhalten. Dann frustriert es sie einfach.
• Es zeigt Meisterschaft. Zumindest soll es so sein. Aber bei echter Meisterschaft geht es nicht darum, Komplexität zu schaffen; Es geht darum, Probleme einfach zu lösen.

Beispiel 1: Die Factory-Funktion „WTF“

Hier ist ein Juwel, über das ich kürzlich gestolpert bin:

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

Schön? Sicher. Aber viel Glück für den Junior-Entwickler, der herausfinden muss, was hier vor sich geht. Drei Funktionsebenen zum Multiplizieren von drei Zahlen? Herzlichen Glückwunsch, Sie haben das Rechnen zu einem olympischen Wettkampf gemacht.

Tu das nicht. Hier ist die gleiche Funktionalität, die für Menschen geschrieben wurde:

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

Lesbar. Einfach. Bewahrt die geistige Gesundheit aller.

Beispiel 2: Die Shakespeare-Versprechenskette

Lassen Sie uns nun über Versprechensketten sprechen, die aussehen, als wären sie von Shakespeare geschrieben worden:

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));

Dieser Code funktioniert. Aber es ist auch ein Verbrechen gegen jeden, der es aufrechterhalten muss. Warum ist jeder Schritt der Datentransformation wie eine russische Puppe in den nächsten eingebettet?

Lassen Sie uns umgestalten:

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);

Durch die Aufteilung der Logik in Schritte wird der Code lesbar. Es macht immer noch das Gleiche, aber jetzt ist klar, was in jeder Phase passiert.

Warum einfach besser ist

Wenn es um Software geht, denken Sie an diese goldene Regel: Ihr Code ist kein persönliches Tagebuch. Es ist ein Kommunikationsmittel. Wenn Ihr Team es nicht lesen kann, kann es nicht damit arbeiten. Und wenn sie damit nicht arbeiten können, kann das Unternehmen nicht vorankommen.

Hier ist der Grund, warum Einfachheit siegt:

1 Schnelleres Onboarding: Nachwuchsentwickler sollten keinen Rosetta Stone benötigen, um Ihren Code zu verstehen.
2 Einfacheres Debuggen: Wenn Fehler auftreten (und das werden sie), erleichtert eine klare Logik deren Lokalisierung.
3 glücklichere Teams: Niemand mag es, sich dumm zu fühlen. Übermäßig cleverer Code verunsichert Ihre Teamkollegen.

The Takeaway

Schreiben Sie Code, als würden Sie ihn Ihrem zukünftigen Ich nach einer harten Nacht erklären. Seien Sie freundlich zum nächsten Entwickler, der Ihre Arbeit lesen muss – denn die Chancen stehen gut, dass Sie dieser Entwickler sind.

Bei schönem Code geht es nicht darum, wie schick er aussieht; Es geht darum, wie effektiv es Probleme löst. Alles andere ist reine Eitelkeitsübung.

Das obige ist der detaillierte Inhalt vonCode, der in ein Museum gehört, nicht in ein Repository. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!