Frontend Fundamentals

Das Frontend-Kapitel von Toss hat eine Website veröffentlicht, die vorstellt, welche Maßstäbe dort für guten Frontend-Code gelten.

• Erklärungen auf Basis von TypeScript, das Frontend-Entwickler hauptsächlich verwenden
• Best Practices aus vier Perspektiven: Lesbarkeit, Vorhersagbarkeit, Kohäsion und Kopplung
• Beispiele für den Einsatz von Bibliotheken, die im realen Frontend häufig verwendet werden

4 Kriterien

1. Lesbarkeit
   Lesbarkeit (Readability) bezeichnet, wie leicht sich Code lesen lässt. Damit Code leicht geändert werden kann, muss man zunächst verstehen können, was er tut.

2. Vorhersagbarkeit
   Vorhersagbarkeit (Predictability) beschreibt, wie gut Kolleginnen und Kollegen in der Zusammenarbeit das Verhalten von Funktionen oder Komponenten einschätzen können. Code mit hoher Vorhersagbarkeit folgt konsistenten Regeln, und allein anhand von Namen, Parametern und Rückgabewerten von Funktionen oder Komponenten lässt sich erkennen, was sie tun.

3. Kohäsion
   Kohäsion (Cohesion) bedeutet, dass Code, der geändert werden muss, auch immer gemeinsam geändert wird. Bei Code mit hoher Kohäsion führt eine Änderung an einem Teil nicht unbeabsichtigt zu Fehlern an anderer Stelle. Der Grund ist, dass die Struktur sicherstellt, dass Teile, die gemeinsam geändert werden müssen, auch tatsächlich gemeinsam geändert werden.

4. Kopplung
   Kopplung (Coupling) bezeichnet den Wirkungsbereich einer Codeänderung. Code, bei dem sich beim Ändern nur ein kleiner Wirkungsbereich ergibt und sich der Umfang der Änderung gut vorhersagen lässt, ist leicht zu ändern.

[savvykang]

Ich frage mich, warum Dateien als kleinste Verwaltungseinheit für Komponenten und Hooks verwendet werden. Ich vermute, dass es an unzureichender IDE-Unterstützung oder mangelndem Tree Shaking liegt, bin mir aber nicht sicher und frage deshalb nach.

Wenn ich Code lese und auf Dateien stoße, die nur eine einzige Funktion enthalten, oder auf index.ts-Dateien, in denen nur import- und export-Anweisungen stehen, steigt die Zahl der Dinge, die ich mir merken muss. Im Vergleich zu einem Ansatz, bei dem Hooks und Komponenten in einer einzelnen Datei gemischt sind, wirkt das auf mich wie ein Layout, das die kognitive Belastung stärker als nötig erhöht. Gibt es dennoch Vorteile oder Gründe, warum man ein solches Layout verwendet?

[firea32]

Die Grundannahme von „guter Entwicklung“, von der man an solchen Stellen meist spricht, ist, dass viele Entwickler daran arbeiten.
Dass es mehr Dinge gibt, die man sich merken muss = bedeutet, dass man selbst die Verantwortung für das gesamte Projekt trägt, aber
in einer Umgebung mit vielen Entwicklern entwickelt jeder nur den Teil, für den er zuständig ist.
Wenn ein Problem auftritt, muss man sich nur diesen Teil ansehen; es ist nicht nötig, alle damit zusammenhängenden Bereiche zu durchleuchten.
In gewisser Weise würde ich sagen, dass man sich statt für extreme Optimierung für Produktivität entschieden hat.

[savvykang]

Wie Sie gesagt haben, ist der Inhalt des Haupttexts in einem Umfeld, in dem sich die Aufgabenverteilung fein aufgliedern lässt, eine passende Wahl. Ich denke, der Beitrag wäre noch vollständiger, wenn die Trade-offs bei der Aufteilung des Codes und die Kriterien für diese Entscheidung erläutert würden.

[beenzinozino]

In meinem Fall sind die Gründe, warum ich bei der Frontend-Entwicklung Dateien als kleinste Verwaltungseinheit für Komponenten oder Hooks verwende, die folgenden.

1. Einfacheres Testen.

Das heißt: Es ist leicht, einem Modul genau einen Unit-Test zuzuordnen.

Ich denke, dass die Frontend-Entwicklung weitgehend von einem Paradigma geprägt ist, das auf reinen Funktionen basiert. Wenn sich jedoch mehrere Funktionen in einer einzigen Datei befinden, ist eine 1:1-Zuordnung beim Schreiben von Unit-Tests schwierig.

Wenn zum Beispiel in einer Datei namens remark-plugin.js mehrere Utility-Funktionen enthalten sind, wie sollte man dann die Tests schreiben? Ist es wirklich eine gute Wahl, nur eine Datei remark-plugin.test.js zu erstellen und darin gesammelt Tests für mehrere Utility-Funktionen zu schreiben?

Wenn man in so einer Situation ein Verzeichnis namens remark-plugins anlegt, die Utility-Funktionen darin einzeln aufteilt und getrennt testet, hat das aus meiner Sicht Vorteile: Später lassen sich die Aufgaben der einzelnen Funktionen klarer definieren, und auch das Nachverfolgen von GitHub-Commits wird deutlich sauberer.

2. Strukturierung von Verzeichnissen

Modul-Bundler wie commonjs in der Server-Entwicklung oder webpack auf der Client-Seite legen häufig eine Datei index.js als Einstiegspunkt eines bestimmten Verzeichnisses fest. Das ist auch eine Konvention, die schon seit Langem oft verwendet wird, weshalb man sie zum Teil einfach übernimmt.

Aber meiner Meinung nach ist der wichtigste Grund folgender: Im Paradigma reiner Funktionen der funktionalen Programmierung sollte man nicht von externem Zustand abhängen. Wenn sich viele Funktionen in einer Datei ballen, steigt aus meiner Sicht die Wahrscheinlichkeit, dass man versehentlich auf externen Zustand verweist. (Es könnte hilfreich sein, darüber nachzudenken, warum in ES6 der Modul-Scope eingeführt wurde.)

3. Einfachere Nachverfolgung von Commits.

Persönlich finde ich, dass sich die Commit-Historie viel einfacher nachverfolgen lässt, wenn Funktionen auf einzelne Dateien aufgeteilt sind, statt mehrere Utility-Funktionen in einer Datei zu vermischen.

Wenn in irgendeinem Modul eine Funktion hinzugefügt oder ein Bug behoben wurde, kann man sich auf genau dieses eine Modul konzentrieren, ohne andere Module mit betrachten zu müssen.

---

Beim Schreiben ist der Text etwas lang geworden und dadurch ein wenig ungeordnet. (Beim Thema Tree Shaking halte ich mich lieber zurück, weil mein Verständnis davon noch nicht besonders tief ist ...) Natürlich muss das, was ich sage, nicht unbedingt die richtige Antwort sein, deshalb würde ich mich freuen, wenn Sie es einfach als Anhaltspunkt betrachten!

[thkimdev]

Das ist gut.

[illiil1lii]

Es war wirklich so geschrieben, dass es sich sehr flüssig lesen ließ. Empfehlenswert.

[tsboard]

Vielen Dank fürs Teilen! Ich sollte es auch gründlich lesen.

[bbulbum]

Es ist zwar auf FE beschränkt geschrieben, aber ich denke, es sind einfach gute Gedanken, die sich auf Software im Allgemeinen anwenden lassen. Vielen Dank, dass Sie diese wertvollen Einsichten geteilt haben.