ZURÜCK
Diese Folge sollte im Dezember vor der Weihnachtspause veröffentlicht werden, so dass es so aussieht, als wäre ich der Engpass, der an der Verzögerung schuld ist. Ich habe die Veröffentlichung von Woche zu Woche verschoben, da einige Aufgaben mit hoher Priorität im Weg waren, aber heute ist DER Tag.
In der letzten Folge habe ich angeregt, den Artikel über die Bedeutung von Humor am Arbeitsplatz zu kommentieren, aber inzwischen habe ich herausgefunden, dass er viel mehr Anerkennung verdient, so dass ich bald einen ganzen Blogbeitrag darüber schreiben werde (ish).
Dinge, die mich in den letzten Wochen beschäftigt haben:
a) Vor Weihnachten begann ich mit der ersten Folge von "Webinarreihe "Kugelsicher CTO (Bleiben Sie dran für die 2. Folge im Februar zum Thema SaaS CTOsDetails folgen bald auf meinem LinkedIn).
b) Abstimmung unseres Wachstumsplans für 2021 mit dem Ziel, über unser Ruby- und JS-Kerngeschäft hinauszugehen und ein Magento und Produkt Design-Kompetenz intern.
Genug der Eigenwerbung, ich lade Sie zur 5. Folge unserer #TheCodestReview-Serie ein.
Meine Themen Team auf diese Zeit vorbereitet hat:
Die Kommentare zur Frontend-Anwendung und konventionelle Commits werden diese Woche von unseren React-Ingenieuren geliefert, während Ruby 3.0.0 von unserem Ruby-Dream-Team stammt.
Um Zeit zu sparen, verwenden heute viele Entwickler bereits erstellte UI-Bibliotheken und wiederverwendbare Komponenten. Das ist eine gute Praxis und hilft uns, eine Menge Zeit zu sparen, aber wenn unsere Projekt größer wird - werden Sie verstehen, dass es nicht ausreicht, sich mit Code.
Es gibt zwei gute Muster aus der Backend-Entwicklung - Domain Driven Development (DDD) und Separation of Concerns (SoC). Wir können sie auch in der Front-End-Architektur verwenden.
In DDD versuchen wir, ähnliche Funktionen zu gruppieren und sie so weit wie möglich von anderen Gruppen (Modulen) zu entkoppeln.
Während wir bei SoC z.B. Logik, Views und Datenmodelle trennen (z.B. mit dem MVC- oder MVVM-Design-Pattern).
Es gibt viele gute Praktiken und Muster, die man anwenden kann, aber ich bevorzuge diesen Weg.
Wenn wir dieses Muster verwenden, erhalten wir dieses Bild:
Zu Beginn wird der Benutzer durch das App-Routing zum richtigen Modul weitergeleitet. Jedes Modul ist vollständig enthalten. Da der Benutzer jedoch erwartet, eine einzige Anwendung und nicht mehrere kleine Anwendungen zu verwenden, wird eine gewisse Kopplung bestehen. Diese Kopplung besteht bei bestimmten Funktionen oder Geschäftslogik.
Und wir haben diese Struktur:
app-Ordner - Anwendungsebene
assets - Ordner für Bilder, Schriftarten, Icons usw.
Komponenten - hier sollten Komponenten zur Wiederverwendung sein, die keine komplizierte Logik haben
config - hier wird der globale Status gespeichert
lib - Ordner für komplizierte Funktionen und Logikberechnungen
Module - hier sind unsere Module
pubsub - Platz für die Speicherung von Schemata zur Beschreibung von Datenstrukturen.
styles - für unseren css/scss-Code
Diese Struktur wird uns helfen, unsere wachsende Anwendung zu handhaben und weniger Fehler zu haben. Außerdem wird sie dazu beitragen, die Arbeit mit separaten Modulen komfortabler zu gestalten, sie zu testen und das Refactoring und Debugging zu erleichtern (aufgrund der separaten Module).
Wenn wir uns die Modularchitektur und ihre Verbindungen mit der API genauer ansehen, werden wir etwas Ähnliches erhalten:
Im Ordner "app" erstellen wir einen weiteren Ordner "api" mit Code für API-Aufrufe und Daten, die wir in "config/store" speichern. Hier speichern wir statische und unveränderliche Daten, die wir in der gesamten Anwendung verwenden.
Auch im Ordner 'pubsub/schema' werden wir spezifische Datentypen beschreiben für JavaScript Objekte.
Alle Module enthalten Daten, die wir verwenden müssen (Benutzer, Routen, Tabellen, Aktionen usw.). Jedes Modul ist mit der Anwendungsschicht verbunden und nimmt alle erforderlichen Daten auf.
Das Frontend ist die erste Anlaufstelle für unsere Benutzer. Da unsere Front-End-Projekte immer mehr Funktionen bieten, werden wir auch mehr Bugs einführen. Aber unsere Benutzer erwarten keine Bugs und schnelle neue Funktionen. Das ist unmöglich. Mit einer guten Architektur können wir jedoch versuchen, dies so gut wie möglich zu erreichen.
Stellen Sie sich vor, Sie stehen am Anfang eines Unternehmens, bei dem Sie gerade erst eingestellt wurden. Alle Leute sind nett zu Ihnen und alles scheint gut zu sein, bis zu dem Punkt, an dem Sie in eine Codebasis eingeführt werden, die noch aus der Zeit stammt, als JavaScript noch keine Sprache war und Netscape eine Seite für eine gefühlte Ewigkeit lud.
Die Vererbung von Code scheint ein großes Problem bei der Einführung neuer Entwickler in ein Projekt zu sein. Den Code zu lesen ist eine Sache, aber zu verstehen, wie die Anwendung entwickelt wurde, ist nicht ganz dasselbe. Oftmals erweisen sich Commits als nützlich und geben Aufschluss darüber, warum diese console.logs nicht von linter abgefangen wurden oder warum dieses hässliche // TODO für die Kinder des Entwicklers da ist, der die Annotation ursprünglich gemacht hat.
Beginnen wir damit, warum konventionelle Commits besser sind als nicht standardisierte Commit-Regeln.
Wenn wir neue Entwickler für ein Projekt einstellen, bei dem die meisten Commits aus Nachrichten bestehen, die in etwa so lauten: "Das sollte funktionieren" oder "Sleepy fix for footer ASAP", was geht Ihnen dann durch den Kopf?
Ich würde sagen, dass rote Flaggen, weil:
Da Ihr Team benutzerdefinierte Regeln für die Übergabe von Änderungen festlegen kann, gibt es weniger Spielraum für Fehler, da Ihre Übergabe solide sein muss. Es ist nicht mehr nur eine Möglichkeit, sich abzumelden. Es ist eine Signatur, die anderen Leuten mitteilt, dass Sie den Inhalt der Übertragung kannten. Ich brauche nicht zu erwähnen, dass, wenn die Arbeit, die Sie gemacht haben, nicht korrekt signiert ist, dies höchstwahrscheinlich zu einem Fehler führt und Sie eine Meldung erhalten
Es besteht die Möglichkeit, dass Ihr Team eine Regel einrichten möchte, die bestimmte Schlüsselwörter verbietet, so dass ASAP oder Schimpfwörter auf die schwarze Liste gesetzt werden können.
Was zu Beginn des Projekts wirklich hilfreich ist, ist die Vorstellung aller Beteiligten, wie Ihre Entwicklungsteam möchte, dass neue Entwickler ihre Änderungen festschreiben. Dann richten Sie ein Werkzeug ein, das ihnen hilft, mit dem Schritt zu halten, worauf Sie sich alle geeinigt haben.
Eines der Werkzeuge, mit denen ich arbeiten konnte, war commitlint und es machte konventionelle Commits zu meiner bevorzugten Praxis, wenn ich zu neuen Projekten komme, für die es keine Regeln gibt und das Team offen für die Idee ist, sie einzuführen.
Wenn Sie sich mit den Einstellungen beschäftigen und sie über Ihr Team verteilen, können Sie einfach ein npm-Paket erstellen und es in jedem Projekt mit mpn i -D versehen. Das wird sicherlich dazu beitragen, dass alle im Projekt immer auf der gleichen Seite stehen und bei Bedarf von Projekt zu Projekt gehen und verstehen, worum es bei den letzten Änderungen ging (und warum sie gemacht wurden).
Nachdem Sie nun alles eingerichtet und verstanden haben, warum es eine gute Idee sein könnte, CC zu verwenden, wäre der beste Teil die Programmierung um die Regeln herum, die Sie gerade angewendet haben! Wir verwenden eine standardisierte Art und Weise, wie wir committen, wir achten mehr darauf, worum es bei dem Commit wirklich ging, warum also nicht Hooks einrichten, die ein schnelles Testen im Staging ermöglichen, wenn ein Flag vorhanden ist? Wir wollen die Dienste nicht überlasten und die Kosten bei Bedarf senken, und es gibt einige Gründe dafür, auf einem produktionsähnlichen Server statt auf dem localhost zu testen.
Nehmen wir an, Sie arbeiten an einer PWA und benötigen SSL, um das volle Potenzial zu testen, und Sie haben ein SSL auf Ihrer Testplattform. Alles, was Sie jetzt brauchen, ist ein guter Commit. Etwas in der Art von feat(PWA): manifest icons workbox setup upload würde die ganze Maschinerie des Testens und Verschiebens von Zahnrädern in Gang setzen. Wir brauchen das nicht, wenn wir nur einige statische Daten wie manifest.json hochladen, also fügen wir ein Flag [TEST_SKIP] als Postfix zu unserem Commit hinzu. Das ermöglicht unserem CI, neue Assets einfach in die Testumgebung hochzuladen und das Testen zu überspringen. Sie können mehr darüber lesen hier
Nach einer Weile werden Sie weitere Vorteile erkennen können, wie z.B. die einfache Erstellung von CHANGELOG und die bessere Versionierung mit semantische Versionierung. Wenn das nicht ausreicht, um Sie davon zu überzeugen, Ihre Art und Weise, wie Sie Commit-Nachrichten schreiben, zu ändern, könnten Sie vielleicht Ihre Zehen in frisches, kaltes Wasser tauchen und versuchen, sie für eine Weile in Ihrem privaten Repository zu verwenden, um Ihre Meinung zu ändern.
Fröhliches konventionelles Begehen!
Das in der Community lang erwartete Ruby 3.0.0 Release hat zu Weihnachten das Tageslicht erblickt, so dass alle Ruby-Entwickler da draußen es unter dem Weihnachtsbaum finden können, sobald sie morgens aufwachen. Bei The Codest kultivieren wir die Kultur des Wissensaustauschs, indem wir wöchentliche Entwicklertreffen organisieren, bei denen unsere Ingenieure über Technologietrends und ihre neuen Entdeckungen diskutieren, die ihre Aufmerksamkeit verdienen. Unten finden Sie einen Link zu den Folien des Demo-Tages, an dem unser Senior Ruby Engineer einige wichtige Änderungen in Ruby 3.0.0 aus seiner subjektiven Sicht diskutiert hat:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Außerdem hat unser Ruby-Mentor mit seinem Pull-Request zur neuen Version beigetragen, der erfolgreich zusammengeführt wurde. Mehr zum Thema Privacy-Control-Methoden finden Sie weiter unten in dem kurzen Artikel unseres Head of Development.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Vielen Dank fürs Lesen, und wenn Sie so weit gekommen sind, weiß ich Ihre Zeit zu schätzen, und jedes Feedback ist auf LinkedIn oder per E-Mail mehr als willkommen.
Wir melden uns Ende Februar mit der nächsten Folge zurück, in der wir ein Interview mit CTO von Shopify führen, dem Mann hinter dem Ingenieurteam, das an der großartigen Ruby-Monolith-App arbeitet!
Man sieht sich.
Lesen Sie mehr:
TheCodestReview #4 - wöchentlicher Softwareentwicklungssaft
German 
English 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek