Eine Geschichte darüber, wie ein Team von Freiberuflern Full-Stack-JavaScript-Anwendungen schreibt

Der Autor des Materials, dessen Übersetzung wir heute veröffentlichen, sagt, dass das GitHub-Repository , an dem er gearbeitet hat, und mehrere andere Freiberufler aus verschiedenen Gründen in 3 Tagen etwa 8.200 Sterne erhalten haben. Dieses Repository belegte bei HackerNews und GitHub Trending den ersten Platz, und 20.000 Reddit-Benutzer stimmten dafür.



Dieses Repository spiegelt die Methodik zum Entwickeln von Full-Stack-Anwendungen wider, der dieser Artikel gewidmet ist.

Hintergrund

Ich wollte dieses Material für einige Zeit schreiben. Ich glaube, ich kann keinen besseren Moment als diesen finden, wenn unser Repository sehr beliebt ist.


Nr. 1 bei GitHub Trending

Ich arbeite in einem Team von Freiberuflern . Unsere Projekte verwenden React / React Native, NodeJS und GraphQL. Dieses Material richtet sich an diejenigen, die erfahren möchten, wie wir Anwendungen entwickeln. Darüber hinaus wird es für diejenigen nützlich sein, die in Zukunft unserem Team beitreten werden.

Jetzt werde ich über die Grundprinzipien sprechen, die wir bei der Entwicklung von Projekten verwenden.

Je einfacher, desto besser.

"Je einfacher desto besser" ist leichter gesagt als getan. Die meisten Entwickler sind sich bewusst, dass Einfachheit ein wichtiges Prinzip in der Softwareentwicklung ist. Dieses Prinzip ist jedoch nicht immer leicht zu befolgen. Wenn der Code einfach ist, erleichtert dies die Projektunterstützung und vereinfacht die Teamarbeit an diesem Projekt. Darüber hinaus hilft die Einhaltung dieses Prinzips bei der Arbeit mit Code, der beispielsweise vor sechs Monaten geschrieben wurde.

Hier sind die Fehler, auf die ich in Bezug auf dieses Prinzip gestoßen bin:

• Ungerechtfertigter Wunsch, das DRY-Prinzip zu erfüllen. Manchmal ist das Kopieren und Einfügen von Code ganz normal. Es ist nicht erforderlich, alle 2 Codefragmente zu abstrahieren, die einander etwas ähnlich sind. Ich selbst habe diesen Fehler gemacht. Alle haben es vielleicht begangen. DRY ist ein guter Programmieransatz, aber die Auswahl einer fehlgeschlagenen Abstraktion kann die Situation nur verschlechtern und die Codebasis komplizieren. Wenn Sie mehr über diese Ideen erfahren möchten, empfehle ich, die AHA-Programmierung von Kent A Dodds zu lesen.
• Verweigerung der Verwendung der verfügbaren Tools. Ein Beispiel für diesen Fehler ist die Verwendung von reduce anstelle von map oder filter . Natürlich kann die Verwendung von reduce das Verhalten der map reproduzieren. Dies führt jedoch wahrscheinlich zu einer Vergrößerung des Codes und zu der Tatsache, dass es für andere Menschen schwieriger sein wird, diesen Code zu verstehen, da „Einfachheit des Codes“ ein subjektives Konzept ist. Manchmal kann es notwendig sein, nur zu reduce . Wenn Sie die Verarbeitungsgeschwindigkeit des Datensatzes mit den in einer Kette kombinierten map und filter und mit reduce , stellt sich heraus, dass die zweite Option schneller funktioniert. Bei der Option mit reduce Sie den Wertesatz einmal und nicht zweimal betrachten. Vor uns liegt eine Debatte über Produktivität und Einfachheit. In den meisten Fällen würde ich die Einfachheit bevorzugen und versuchen, eine vorzeitige Codeoptimierung zu vermeiden, dh ich würde ein map / filter Paar wählen, anstatt es zu reduce . Und wenn sich herausstellen würde, dass die Konstruktion von map und filter zum Engpass des Systems wird, würde der zu reduce Code übersetzt.

Viele der unten diskutierten Ideen zielen darauf ab, die Codebasis so einfach wie möglich zu gestalten und in diesem Zustand zu halten.

Halten Sie ähnliche Objekte nahe beieinander

Dieses Prinzip, das „Colocation-Prinzip“, gilt für viele Teile der Anwendung. Dies ist die Struktur der Ordner, in denen der Client- und Servercode gespeichert ist. Dies ist die Speicherung des Projektcodes in einem Repository. Dies ist auch die Entscheidung darüber, welcher Code in einer bestimmten Datei enthalten ist.

▍ Repository

Es wird empfohlen, den Client- und Servercode im selben Repository zu belassen. Das ist einfach. Komplizieren Sie nicht, was nicht notwendig ist, um zu komplizieren. Mit diesem Ansatz ist es bequem, eine koordinierte Teamarbeit an einem Projekt zu organisieren. Ich habe an Projekten gearbeitet, in denen verschiedene Repositories zum Speichern von Materialien verwendet wurden. Dies ist keine Katastrophe, aber Mono-Repositories erleichtern das Leben erheblich.

▍ Projektstruktur des Client-Teils der Anwendung

Wir schreiben Full-Stack-Anwendungen. Das heißt, sowohl der Client-Code als auch der Server-Code. Die Ordnerstruktur eines typischen Client-Projekts bietet separate Verzeichnisse für Komponenten, Container, Aktionen, Reduzierungen und Routen.

Aktionen und Reduzierungen sind in Projekten vorhanden, die Redux verwenden. Ich bemühe mich, auf diese Bibliothek zu verzichten. Ich bin sicher, dass es qualitativ hochwertige Projekte gibt, die dieselbe Struktur verwenden. Einige meiner Projekte haben separate Ordner für Komponenten und Container. Ein Komponentenordner kann so etwas wie Dateien mit Code für Entitäten wie BlogPost und Profile BlogPost . Im Containerordner befinden sich Dateien, in denen der Containercode BlogPostContainer und BlogPostContainer . Der Container empfängt Daten vom Server und übergibt sie an die "dumme" untergeordnete Komponente, deren Aufgabe es ist, diese Daten auf dem Bildschirm anzuzeigen.

Dies ist eine Arbeitsstruktur. Es ist zumindest homogen, und das ist sehr wichtig. Dies führt dazu, dass der Entwickler, der sich der Arbeit an dem Projekt angeschlossen hat, schnell versteht, was darin passiert und welche Rolle die einzelnen Teile spielen. Der Nachteil dieses Ansatzes, aufgrund dessen ich kürzlich versucht habe, ihn nicht zu verwenden, besteht darin, dass er den Programmierer zwingt, sich ständig in der Codebasis zu bewegen. Beispielsweise haben die BlogPostContainer und BlogPostContainer nichts gemeinsam, aber ihre Dateien befinden sich nebeneinander und weit entfernt von den Dateien, in denen sie tatsächlich verwendet werden.

Seit einiger Zeit bemühe ich mich, Dateien, deren Inhalt freigegeben werden soll, in denselben Ordnern abzulegen. Dieser Ansatz zur Projektstrukturierung basiert auf der Gruppierung von Dateien nach ihren Fähigkeiten. Dank dieses Ansatzes können Sie Ihr Leben erheblich vereinfachen, wenn Sie beispielsweise die übergeordnete Komponente und ihre „dumme“ untergeordnete Komponente im selben Ordner ablegen.

Normalerweise verwenden wir den Ordner routes / screens und den Ordner components . Der Komponentenordner speichert normalerweise Code für Elemente wie Button oder Input . Dieser Code kann auf jeder Seite der Anwendung verwendet werden. Jeder Ordner im Ordner für Routen ist eine separate Anwendungsseite. Gleichzeitig befinden sich Dateien mit dem Komponentencode und dem Anwendungslogikcode für diese Route im selben Ordner. Der Code der Komponenten, die auf mehreren Seiten verwendet werden, fällt in den components .

Innerhalb des Routenordners können Sie zusätzliche Ordner erstellen, in denen der Code gruppiert ist, der für die Bildung verschiedener Teile der Seite verantwortlich ist. Dies ist in Fällen sinnvoll, in denen die Route durch eine große Menge Code dargestellt wird. Hier möchte ich den Leser jedoch warnen, dass es sich nicht lohnt, Strukturen aus Ordnern mit einem sehr hohen Verschachtelungsgrad zu erstellen. Dies erschwert die Bewegung des Projekts. Tief verschachtelte Ordnerstrukturen sind eines der Anzeichen für eine Überkomplikation eines Projekts. Es sollte beachtet werden, dass die Verwendung spezieller Tools wie Suchbefehle dem Programmierer bequeme Tools zum Arbeiten mit dem Projektcode und zum Finden dessen, was er benötigt, bietet. Die Dateistruktur des Projekts wirkt sich jedoch auch auf die Benutzerfreundlichkeit aus.

Wenn Sie den Projektcode strukturieren, können Sie Dateien nicht nach der Route, sondern nach den von diesen Dateien implementierten Projektfunktionen gruppieren. In meinem Fall zeigt sich dieser Ansatz perfekt bei einseitigen Projekten, die viele Funktionen auf ihrer einzigen Seite implementieren. Es ist jedoch zu beachten, dass das Gruppieren von Projektmaterialien nach Routen einfacher ist. Dieser Ansatz erfordert keine besonderen mentalen Anstrengungen, um Entscheidungen darüber zu treffen, welche Entitäten nebeneinander platziert werden sollen, und um nach etwas zu suchen.

Wenn wir den Code weiter gruppieren, können wir entscheiden, dass der Code von Containern und Komponenten zu Recht in derselben Datei abgelegt wird. Und Sie können noch weiter gehen - fügen Sie den Code zweier Komponenten in eine Datei ein. Ich nehme an, Sie denken jetzt vielleicht, dass es wirklich Gotteslästerung ist, solche Dinge zu empfehlen. Aber in Wirklichkeit ist alles alles andere als schlecht. Tatsächlich ist dieser Ansatz völlig gerechtfertigt. Und wenn Sie React-Hooks oder generierten Code (oder beides) verwenden, würde ich diesen Ansatz empfehlen.

Tatsächlich ist die Frage, wie der Code in Dateien zerlegt werden soll, nicht von größter Bedeutung. Die eigentliche Frage ist, warum Sie die Komponenten möglicherweise in intelligent und dumm unterteilen müssen. Was sind die Vorteile dieser Trennung? Auf diese Frage gibt es mehrere Antworten:

1. Auf diese Weise erstellte Anwendungen sind einfacher zu testen.
2. Die Entwicklung solcher Anwendungen erleichtert die Verwendung von Tools wie dem Storybook.
3. Dumme Komponenten können mit vielen verschiedenen intelligenten Komponenten verwendet werden (und umgekehrt).
4. Intelligente Komponenten können auf verschiedenen Plattformen verwendet werden (z. B. auf den Plattformen React und React Native).

All dies sind echte Argumente für die Unterteilung der Komponenten in „intelligent“ und „dumm“, aber sie gelten nicht für alle Situationen. Beispielsweise verwenden wir beim Erstellen von Projekten häufig Apollo Client mit Hooks. Um solche Projekte zu testen, können Sie entweder Apollo-Antwort-Mocks oder Hook-Mocks erstellen. Gleiches gilt für das Storybook. Wenn wir über das Mischen und Teilen von „intelligenten“ und „dummen“ Komponenten sprechen, habe ich dies in der Praxis noch nie erlebt. In Bezug auf die plattformübergreifende Verwendung des Codes gab es ein Projekt, in dem ich etwas Ähnliches tun wollte, dies aber nie tat. Es sollte das Lerna- Mono-Repository sein . Anstelle dieses Ansatzes können Sie sich heutzutage für React Native Web entscheiden.

Infolgedessen können wir sagen, dass die Trennung von Komponenten in „intelligent“ und „albern“ eine bestimmte Bedeutung hat. Dies ist ein wichtiges wissenswertes Konzept. Oft müssen Sie sich jedoch keine großen Sorgen machen, insbesondere angesichts des jüngsten Auftretens von React-Hooks.

Die Stärke der Kombination der Funktionen von „intelligenten“ und „albernen“ Komponenten in einer Entität besteht darin, dass die Entwicklung beschleunigt und die Struktur des Codes vereinfacht wird.

Darüber hinaus kann eine Komponente bei Bedarf immer in zwei separate Komponenten unterteilt werden - „intelligent“ und „dumm“.

Stilisierung

Wir verwenden emotionale / gestaltete Komponenten für Styling-Anwendungen. Es besteht immer die Versuchung, Stile in eine separate Datei zu trennen. Ich habe einige Entwickler gesehen, die dies getan haben. Nachdem ich beide Ansätze ausprobiert hatte, konnte ich am Ende keinen Grund finden, die Stile in eine separate Datei zu verschieben. Wie bei vielen anderen Dingen, über die wir hier sprechen, kann ein Entwickler sein Leben erleichtern, indem er die Stile und Komponenten, auf die sie sich beziehen, in einer Datei kombiniert.

▍Projektstruktur des Serverteils der Anwendung

All dies gilt für die Strukturierung des serverseitigen Codes der Anwendung. Eine typische Struktur, die ich persönlich zu vermeiden versuche, könnte ungefähr so ​​aussehen:

 src │ app.js #     └───api #   Express      └───config #      └───jobs #    agenda.js └───loaders #     └───models #    └───services # - └───subscribers #      └───types #    (d.ts)  Typescript 

Normalerweise verwenden wir GraphQL in unseren Projekten. Daher verwenden sie Dateien, in denen Modelle, Dienste und Erkenner gespeichert sind. Anstatt sie an verschiedenen Stellen des Projekts zu verteilen, sammle ich sie in einem Ordner. In den meisten Fällen werden diese Dateien freigegeben, und es ist einfacher, mit ihnen zu arbeiten, wenn sie im selben Ordner gespeichert sind.

Überschreiben Sie Typdefinitionen nicht oft

In unseren Projekten verwenden wir viele Lösungen, die in irgendeiner Weise mit Datentypen zusammenhängen. Dies sind TypeScript, GraphQL, Datenbankschemata und manchmal MobX. Infolgedessen kann sich herausstellen, dass die Typen für dieselben Entitäten 3-4 Mal beschrieben werden. Solche Dinge sollten vermieden werden. Wir sollten uns bemühen, Werkzeuge zu verwenden, die automatisch Typbeschreibungen generieren.

Auf dem Server kann zu diesem Zweck eine Kombination aus TypeORM / Typegoose und TypeGraphQL verwendet werden. Dies reicht aus, um alle verwendeten Typen zu beschreiben. Mit TypeORM / Typegoose können Sie das Datenbankschema und die entsprechenden TypeScript-Typen beschreiben. TypeGraphQL hilft beim Erstellen der Typen von GraphQL und TypeScript.

Hier ist ein Beispiel für die Bestimmung der Typen von TypeORM (MongoDB) und TypeGraphQL in einer Datei:

 import { Field, ObjectType, ID } from 'type-graphql' import { Entity, ObjectIdColumn, ObjectID, Column, CreateDateColumn, UpdateDateColumn, } from 'typeorm' @ObjectType() @Entity() export default class Policy { @Field(type => ID) @ObjectIdColumn() _id: ObjectID @Field() @CreateDateColumn({ type: 'timestamp' }) createdAt: Date @Field({ nullable: true }) @UpdateDateColumn({ type: 'timestamp', nullable: true }) updatedAt?: Date @Field() @Column() name: string @Field() @Column() version: number } 

GraphQL Code Generator kann auch viele verschiedene Typen generieren. Wir verwenden dieses Tool, um TypeScript-Typen auf dem Client sowie React-Hooks zu erstellen, die auf den Server zugreifen.

Wenn Sie MobX verwenden, um den Status der Anwendung zu steuern, und dann mithilfe einiger Codezeilen automatisch generierte TS-Typen erhalten. Wenn Sie auch GraphQL verwenden, sollten Sie sich das neue Paket MST-GQL ansehen , das aus dem GQL-Schema einen Statusbaum generiert.

Wenn Sie diese Tools zusammen verwenden, können Sie keine großen Mengen an Code neu schreiben und häufige Fehler vermeiden.

Andere Lösungen wie Prisma , Hasura und AWS AppSync können ebenfalls dazu beitragen, doppelte Typdeklarationen zu vermeiden. Die Verwendung solcher Tools hat natürlich Vor- und Nachteile. In den von uns erstellten Projekten werden solche Tools nicht immer verwendet, da wir den Code auf unseren eigenen Servern von Organisationen bereitstellen müssen.

Verwenden Sie nach Möglichkeit die automatische Codegenerierung

Wenn Sie sich den Code ansehen, den Sie erstellen, ohne die oben genannten Tools zum automatischen Generieren von Code zu verwenden, stellt sich heraus, dass Programmierer ständig dasselbe schreiben müssen. Der wichtigste Rat, den ich dazu geben kann, ist, dass Sie Snippets für alles erstellen müssen, was Sie häufig verwenden. Wenn Sie häufig den Befehl console.log , erstellen Sie ein Snippet wie cl , das automatisch in console.log() . Wenn Sie dies nicht tun und mich bitten, Ihnen beim Debuggen von Code zu helfen, wird mich das sehr verärgern.

Es gibt viele Pakete mit Snippets, aber es ist einfach, eigene Snippets zu erstellen. Zum Beispiel mit dem Snippet-Generator .

Hier ist der Code, mit dem ich einige meiner Lieblingsausschnitte zu VS Code hinzufügen kann:

 { "Export default": {   "scope": "javascript,typescript,javascriptreact,typescriptreact",   "prefix": "eid",   "body": [     "export { default } from './${TM_DIRECTORY/.*[\\/](.*)$$/$1/}'",     "$2"   ],   "description": "Import and export default in a single line" }, "Filename": {   "prefix": "fn",   "body": ["${TM_FILENAME_BASE}"],   "description": "Print filename" }, "Import emotion styled": {   "prefix": "imes",   "body": ["import styled from '@emotion/styled'"],   "description": "Import Emotion js as styled" }, "Import emotion css only": {   "prefix": "imec",   "body": ["import { css } from '@emotion/styled'"],   "description": "Import Emotion css only" }, "Import emotion styled and css only": {   "prefix": "imesc",   "body": ["import styled, { css } from ''@emotion/styled'"],   "description": "Import Emotion js and css" }, "Styled component": {   "prefix": "sc",   "body": ["const ${1} = styled.${2}`", "  ${3}", "`"],   "description": "Import Emotion js and css" }, "TypeScript React Function Component": {   "prefix": "rfc",   "body": [     "import React from 'react'",     "",     "interface ${1:ComponentName}Props {",     "}",     "",     "const ${1:ComponentName}: React.FC<${1:ComponentName}Props> = props => {",     " return (",     " <div>",     " ${1:ComponentName}",     " </div>",     " )",     "}",     "",     "export default ${1:ComponentName}",     ""   ],   "description": "TypeScript React Function Component" } } 

Zusätzlich zu Snippets können Codegeneratoren helfen, Zeit zu sparen. Sie können sie selbst erstellen. Ich benutze dafür gerne Plop .

Angular verfügt über eigene Codegeneratoren. Mit den Befehlszeilentools können Sie eine neue Komponente erstellen, die aus 4 Dateien besteht und alles enthält, was Sie in der Komponente erwarten können. Es ist schade, dass React nicht über eine solche Standardfunktion verfügt, aber etwas Ähnliches kann unabhängig mit plop erstellt werden. Wenn jede neue Komponente, die Sie erstellen, in Form eines Ordners angezeigt werden soll, der eine Datei mit dem Komponentencode, eine Testdatei und eine Storybook-Datei enthält, hilft der Generator dabei, all dies mit einem Befehl zu erstellen. Dies erleichtert in vielen Fällen das Leben des Entwicklers erheblich. Wenn Sie beispielsweise dem Server eine neue Funktion hinzufügen, führen Sie einfach einen Befehl in der Befehlszeile aus. Danach werden automatisch Dateien der Entität, Dienste und Erkenner erstellt, die alle erforderlichen Grundstrukturen enthalten.

Eine weitere Stärke von Codegeneratoren besteht darin, dass sie zur Einheitlichkeit der Teamentwicklung beitragen. Wenn jeder den gleichen Plop-Generator verwendet, ist der Code für alle sehr einheitlich.

Automatische Code-Formatierung

Das Formatieren des Codes ist eine einfache Aufgabe, die jedoch leider nicht immer richtig gelöst wird. Verschwenden Sie keine Zeit damit, den Code manuell auszurichten oder Semikolons einzufügen. Verwenden Sie Prettier, um den Code beim Festschreiben automatisch zu formatieren.

Zusammenfassung

In diesem Artikel habe ich Ihnen einige Dinge erzählt, die wir im Laufe der Jahre der Arbeit, im Laufe der Jahre des Versuchs und Irrtums gelernt haben. Es gibt viele Ansätze zur Strukturierung der Codebasis von Projekten. Aber unter ihnen gibt es niemanden, der als der einzig richtige bezeichnet werden kann.

Das Wichtigste, was ich Ihnen vermitteln wollte, ist, dass der Programmierer sich um die Einfachheit der Organisation von Projekten, ihre Homogenität und die Verwendung einer verständlichen Struktur bemüht, mit der man leicht arbeiten kann. Dies vereinfacht Teamentwicklungsprojekte.

Liebe Leser! Was halten Sie von den in diesem Artikel beschriebenen Ideen für die Entwicklung von Full-Stack-JavaScript-Anwendungen?