Unser Rat mag erfahrenen Leuten offensichtlich erscheinen. Für Anfänger empfehlen wir jedoch dringend zu lesen. Nehmen Sie sich Zeit, um diese Ideen in Ihre Projekte umzusetzen, damit Sie später nicht noch mehr für endloses Refactoring ausgeben.
Ähnliche Ideen können in fast jedem Bereich der Entwicklung zum Ausdruck gebracht werden, aber wir werden am Beispiel von Projekten in React darüber sprechen.
Wenn Sie Projekte von Grund auf neu starten, überlegen Sie, wie Sie alles am besten organisieren können, damit es später aufgrund endloser Nacharbeiten nicht unerträglich schmerzhaft wird. In persönlichen Haustierprojekten können Sie alles umzäunen, was Sie wollen - und dann selbst damit leben. Bei der Teamarbeit müssen Sie jedoch so handeln, dass Kollegen das Wesentliche leichter verstehen und in Details eintauchen können. Jene. Erfinden Sie Entwicklungsansätze nicht neu - es ist besser, sich an etablierte, branchenweit anerkannte Praktiken zu halten.
Denken Sie über das Tippen nach
Unabhängig von den Freiheiten in Entwicklungssprachen ist die statische Typisierung bei großen Langzeitprojekten sehr nützlich. Wenn es aus irgendeinem Grund unmöglich ist, in einem solchen Projekt eine statische Typisierung zu verwenden, hilft sogar JSDoc erheblich dabei, die Qualität des Codes aufrechtzuerhalten.
Wir raten Ihnen jedoch nicht dringend davon ab, immer zu tippen. Es war nicht umsonst, dass oben eine Reservierung für große Projekte gemacht wurde, da das Tippen in erster Linie dem Team hilft. Die Organisation und Wartung (Änderung des gleichen Typs gemäß den Änderungen im Backend) erfordert jedoch bestimmte Ressourcen. In einem kleinen kurzfristigen Projekt, in dem 1-2 Personen arbeiten, ist diese Investition sinnlos. Aber sie sind notwendig, wenn das Team groß ist und erweitert wird.
Wenn die Verwendung der Eingabe gerechtfertigt ist, empfehlen wir, dass Sie Typen von Anfang an erstellen, da Sie sonst viel mehr Zeit für diese Arbeit aufwenden müssen. Auch wenn Sie keine API bereit haben und das Datenmodell nicht kennen, sollten Sie zumindest Stubs erstellen, damit der generische Typ nirgendwo angezeigt wird.
Während sich das Projekt entwickelt, muss die Eingabe eingehalten werden, auch wenn alle Fristen schon lange ausgebrannt sind. Dann werden Sie sich für diesen Perfektionismus bedanken.
Teilen Sie den Code in Blöcke und markieren Sie die Logik
Der Code sollte nicht zusammengefasst werden. Es lohnt sich, die Hierarchie in der Projektstruktur zu berücksichtigen - den Code in Module und Blöcke aufzuteilen und Komponenten in intelligent und dumm zu unterteilen. Es ist bequemer, eine solche Struktur beizubehalten und zu entwickeln, als in einem großen Haufen nach Partikeln dieser Logik zu suchen, insbesondere wenn diese Partikel miteinander verbunden sind. Vielleicht gilt dieser Rat nicht nur für das Frontend.
Die Nützlichkeit dieses Prinzips war in dem Projekt mit großen Formularen, über das wir kürzlich geschrieben haben, sehr deutlich sichtbar ( https://habr.com/ru/company/maxilect/blog/511322/ ). In diesem Projekt wurden Blockprüfungen und die Sichtbarkeit dieser Blöcke zunächst verknüpft. Als wir jedoch die gesamte Kommunikation der Felder an einem Ort sammelten, wurde es viel einfacher, die Änderungen in der Logik zu verfolgen. Und vor allem konnten wir den Code in einem neuen ähnlichen Projekt wiederverwenden.
Es gibt keinen einheitlichen Standard für die Struktur eines Projekts - hier müssen Sie sich auf Ihr Wissen verlassen. Es gibt zwei Ansätze, die für viele Projekte funktionieren können: Dateityp zuerst und Feature zuerst.
Um einen Ausgangspunkt für die Suche nach einer für Sie geeigneten Struktur zu finden, empfehlen wir Ihnen, sich auf die Dokumentation zu beziehen. Dort wird normalerweise die beste Vorgehensweise beschrieben. Beispielsweise bieten React und Redux in ihrer Dokumentation Standards für die Organisation der Logik und Dateistruktur eines Projekts. Mit etwas Erfahrung können Sie experimentieren und von den Standards abweichen, wenn Sie damit einige Einschränkungen für ein bestimmtes Projekt umgehen können. In den meisten Fällen ist dies jedoch nicht erforderlich. Und vergessen Sie natürlich nicht solche „Grundprinzipien“ wie SOLID. Schöner Artikel darüber, wie man diese Prinzipien in React anwendet:https://habr.com/ru/company/ruvds/blog/428079/ . Guter Artikel über saubere Architektur: https://habr.com/ru/post/499078/ .
Zur Organisation der Codebasis in React und verwandten Themen gibt es eine gute, wenn auch lange nicht aktualisierte Sammlung von Materialien: https://github.com/markerikson/react-redux-links/blob/master/project-structure.md .
Formulieren Sie eine Codierungskonvention
Der Architekt, der das Projekt zunächst auf der Grundlage des Entwicklungspfads der Anwendung plant, hat bestimmte Vorlagen im Auge. Es lohnt sich, sie explizit in Form eines Projektpasses auszudrücken und ihn durch die Regeln für das Schreiben von Code zu ergänzen, z. B. was in einem separaten Modul enthalten sein kann und was nicht (im Allgemeinen ist dies eine eher philosophische Frage). Ein solcher "Pass" hilft Entwicklern, im Voraus zu bestimmen, wie sie schreiben sollen, damit sie später nicht neu schreiben müssen. Dies kann die Überprüfungszeit verkürzen und zur Standardisierung von Codierungsansätzen beitragen. Dies ist besonders nützlich, wenn Sie an einem Projekt mit Remote-Mitarbeitern oder verteilten Teams arbeiten.
Halten Sie sich an das gewählte Paradigma
Wenn Sie sich zu Beginn für einen Ansatz entschieden haben, beispielsweise für das atomare Webdesign, sollten Sie ihn nicht aufgeben, sobald die Fristen abgelaufen sind. Die initiierte und aufgegebene Unterstützung für ein Paradigma ist manchmal fast schlimmer als seine völlige Abwesenheit. Wenn Sie dem Chaos ein wenig „freien Lauf lassen“, wird es äußerst schwierig sein, die Ordnung wiederherzustellen - Sie müssen Zeit damit verbringen, zum Paradigma zurückzukehren. Und Sie werden nicht schnell zu einem anderen „springen“ können, da sich im Projekt bereits ein formloses Durcheinander gebildet hat.
Die Ablehnung des Paradigmas aus Gründen des Timings oder anderer Faktoren ist wie ein Pferdewechsel an einer Kreuzung. Es ist schmerzhaft und nicht zu empfehlen. Wenn es jedoch keinen Ausweg gibt, müssen Sie den größten Teil Ihrer Anwendung mit Tests abdecken. Und hier geht es weiter mit dem nächsten Tipp ...
Denken Sie an Tests
Tests an einem Projekt müssen nicht nur sein. Sie müssen arbeiten. Und es ist notwendig, sie bereits in der ersten Phase in das Projekt einzubeziehen - sobald die Entwicklung beginnt. Andernfalls können Sie zu einem bestimmten Zeitpunkt etwas in der Anwendung ändern und dann die Veröffentlichungsfristen überschreiten, um die Leistung verschiedener Teile des Projekts wiederherzustellen, die nur durch manuelle Tests abgedeckt werden.
Lassen Sie die Tests zu Beginn klein sein und überprüfen Sie überhaupt nichts. Es ist jedoch viel besser, sie mit zunehmender Funktionalität zu entwickeln, als eine Woche später damit zu verbringen, diese „technischen Schulden“ zu begleichen. In Bezug auf die aufgewendete Zeit ist der erste Ansatz effektiver. Übrigens verstehen viele Leute das sehr gut, lassen die Tests aber trotzdem für später.
Ich möchte auch Integrations- und End-to-End-Tests erwähnen.
Integrationstests sollten jedes Mal ausgeführt werden, wenn Sie Fehler beheben oder neue Funktionen hinzufügen, um sicherzustellen, dass die Anpassungen keine Auswirkungen haben. Bei unseren Projekten versuchen wir, sie automatisch zu starten, wenn wir die Ergebnisse unserer Arbeit hochladen (wir haben dies über einen Hook implementiert). Tests haben nicht geklappt - Sie sollten keine Änderungen in das Projekt hochladen. Zuerst müssen Sie alles reparieren.
Integrationstests betreffen jedoch nur das Frontend. End-to-End-Tests sind langsamer und testen die Interaktion der Anwendung mit allen abhängigen Elementen. Diese Tests simulieren Benutzeraktionen. Hier verspotten wir nichts, sondern warten wirklich auf Backend-Antworten und überprüfen die Interaktionen innerhalb des gesamten Ökosystems des Projekts mit Cypress (wir können Puppeteer auch als Analog empfehlen).
Denken Sie vor dem Upgrade nach, aber geben Sie nicht auf
In der Frontend-Welt ändert sich alles sehr schnell - Framework-Versionen ersetzen sich gegenseitig, erfolgreichere Bibliotheken erscheinen. Es lohnt sich, sie auf dem neuesten Stand zu halten, aber nicht fanatisch.
Wie beim Tippen, über das wir oben gesprochen haben, kostet jedes Update Ressourcen (d. H. Indirekt Geld). Es gibt jedoch einige Dinge, die es unmöglich machen, Updates vollständig zu deaktivieren.
Erstens endet manchmal die Unterstützung selbst der erfolgreichsten Bibliotheken. In dieser Situation müssen Sie sich für vielversprechendere Analoga entscheiden.
Zweitens inspiriert die Arbeit mit dem alten Technologie-Stack Entwickler selten. Wenn Sie feststellen, dass das Team nicht auf einem staubigen Backbone gehalten werden kann oder Sie feststellen, dass ein veralteter Stack den Zustrom neuer Entwickler entscheidend beeinflusst, müssen Sie ein Update durchführen.
Erfrischungen sollten Teil der natürlichen Ordnung der Dinge sein. Bevor Sie jedoch eine Bibliothek ändern oder ein Framework aktualisieren, sollten Sie immer Nachforschungen anstellen.
Ist die neue Version für Sie geeignet? Wie organisiert man den Übergang im Allgemeinen? Und natürlich müssen Sie alles im Voraus planen.
Aktualisierungen sind äußerst schwierig, wenn keine Tests für das Projekt vorhanden sind. Selbst eine kleine Datumsbibliothek kann viele verschiedene Teile eines Projekts abdecken, und die Aktualisierung führt zu vollständigen Regressionstests. Mit dem Wachstum des Projekts wird es nicht möglich sein, es effizient durchzuführen, da nur manuelle Tests im Arsenal durchgeführt werden.
Geht es dir jetzt gut
Das Maß dafür, wie effizient Sie Ihr Projekt entwickeln, kann das Verhältnis der Zeit sein, die für die Entwicklung neuer Funktionen aufgewendet wird, zu der Zeit, die für Fehler aufgewendet wird. Je nach Ansatz kann dieser Indikator mehr oder weniger hoch sein, sodass wir uns nicht verpflichten werden, „Zielwerte“ festzulegen. Sie selbst können die Situation vor und nach Transformationen vergleichen.
Zusätzlich zu nicht numerischen Merkmalen wie „Entwicklerzufriedenheit aus dem Projekt“ gibt es einen Indikator wie die Zeit, zu der eine neue Person dem Projekt beitritt. Dies ist ein Merkmal dafür, wie gut ein Projekt durch Dokumentation, Tests und Codierungskonventionen klar beschrieben wird.
Und denken Sie daran, es ist besser, besseren Code zurückzulassen als vor Ihnen. Generieren Sie keine technischen Schulden, da dies die Entwicklung des Projekts später behindert.
Vielleicht hast du deine eigenen Tipps? Hinterlasse in den Kommentaren!
PS Wir veröffentlichen unsere Artikel auf mehreren Websites der Runet. Abonnieren Sie unseren Seiten VK , FB , Instagram oder Telegramm Kanal über alle unsere Publikationen und andere Nachrichten von Maxilect zu lernen.
PPS Das Titelbild des kürzlich abgehaltenen Playhouse-Wettbewerbs.