Unlimited Wordpress themes, plugins, graphics & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Web Design
  2. Documentation
Webdesign

8 Best Practices für eine perfekte CSS-Dokumentation

Length:LongLanguages:

German (Deutsch) translation by Wilhelm Wolf (you can also view the original English article)

In der Welt von CSS, die Dokumentation ist zu wenig. Da die Dokumentation ist nicht sichtbar für den Endbenutzer, deren Wert oft übersehen wird, von den Kunden. Auch, wenn es Ihre erste Zeit zu dokumentieren-code, kann es schwierig sein zu bestimmen, was zu dokumentieren ist und wie man es am effektivsten.

Doch dokumentieren kann CSS bieten eine Menge für Ihr Projekt: von der Förderung einer besseren code-Praktiken zur Erleichterung der onboarding neuer team-Mitglieder. In diesem Artikel werde ich erklären, die Vorteile der Dokumentation von CSS und teilen, was mein team und ich an Bitovi betrachten, um die besten Praktiken, um die Dokumentation für Sie arbeiten–nicht Umgekehrt. Lassen Sie uns Tauchen Sie ein in.

1. Legen Sie die Grundregeln fest

Es ist schwer, um auf die Dokumentation auf den fahrenden Zug aufspringen, wenn es ist nicht klar, für Sie und Ihr team, was zu dokumentieren oder, wie Sie es wollen zu arbeiten. Der erste Schritt ist daher, zu vereinbaren, welche Konventionen Sie verwenden werden, und wie sollte man Sie umsetzen. Sie können dies tun, in ein live-Dokument, so dass jeder im team kann dazu beitragen. Auf diese Weise, so Ihr Ansatz, die Veränderungen oder wird umfangreicher, Sie können halten Sie es up-to-date. Einen gemeinsamen Google-Dokument, eine wiki-Seite mit Ihrem code-repo, oder (noch besser) eine Seite auf Ihrer "living style guide" sind alle großen Plätze für diese.

Lassen Sie uns jetzt schaut die tatsächlichen "Spielregeln", die Sie einschließen können.

2. Erklären Sie die Struktur der Code-Basis

Das Verständnis, wie Sie Ihren code organisiert ist, kann jeder zu springen direkt in die action vom ersten Tag an. Ein einfacher Weg, dies zu tun ist, erstellen Sie eine Karte Ihrer Datei-Struktur, wo man erklären kann, was in ihm ist, und was gehen sollte, wo. Dabei ist besonderes Augenmerk auf jene Orte, wo es sein könnte Mehrdeutigkeit. Zum Beispiel, angibt, dass die Datei “buttons.css" enthält die Stile für die Schaltflächen ist nicht sehr hilfreich, aber darauf hinweist, dass die "custom" - Verzeichnis ist, wo benutzerdefinierte Formatvorlagen für das Thema sind, kann sich eine Zeitersparnis.

Hier ein Beispiel:

Als Faustregel gilt, dokumentieren jene Orte, wo eine Klarstellung notwendig ist. Nicht jedes Verzeichnis und Datei benötigen Dokumentation (wie im obigen Beispiel "Schriften" ist selbsterklärend). Versetzen Sie sich in die Schuhe von jemand neues zu dem Projekt (oder erinnern Sie sich an jene Zeiten, in denen Sie waren, der person) und bieten die Unterstützung, die Sie wünschte, du würdest gegeben haben. Die Idee ist, dies zu tun in einer Weise, die nicht viel Zeit für Sie aber ist hilfreich genug, um vermeiden Sie sich wiederholende Fragen.

Ein weiteres wichtiges element zu betonen hier ist, wo neue Stile Hinzugefügt werden sollten, und alle Schritte, die befolgt werden sollten. Das obige Beispiel veranschaulicht dies, aber angesichts der Vererbung Natur von CSS, kann es sich lohnen, um es im detail.

Zum Beispiel in Projekten, in denen wir verwendeten Bootstrap als framework zugrunde, wir haben in der Regel drei stellen, wo die neuen Regeln sollten gehen, je nachdem, was der Entwickler erreichen will. So haben wir einen Leitfaden für die Dokumentation, die aus drei Szenarien:

Szenario #1

Wenn Sie überschreiben möchten, einen Stil definiert durch Bootstrap, dann:

  1. Finden Sie heraus, in welches stylesheet für die bootstrap-framework die Regel definiert ist.
  2. Gehen Sie auf "src/styles/bootstrap-custom".
  3. Suchen Sie für die gleichen stylesheet.
  4. Wenn es nicht vorhanden ist, erstellen Sie eine neue in das Verzeichnis mit dem gleichen Namen.
  5. Fügen Sie Ihre überschreiben und zeigen etwas von Bedeutung.
  6. Schließlich importieren Sie das neue stylesheet in “src/styles/Stil.weniger".

Szenario #2

Wenn Sie möchten fügen Sie eine neue style-definition, die nicht überschrieben werden Bootstrap-und das sollte immer und überall verfügbar in der Anwendung, dann:

  1. Gehen Sie auf "src/styles/custom".
  2. Finden Sie ein stylesheet, wo die neue Formatvorlage Hinzugefügt werden könnten (denken Sie: ist das ein Stil für die Definition einer Schaltfläche, oder ist es eine wiederverwendbare Stil wie ein mixin?) und legen Sie Sie, wo es am meisten Sinn macht.
  3. Wenn es nicht ein stylesheet, wo es Sinn macht, um diese neue-Stil, dann eine neue erstellen.
  4. Nennen Sie es nach unseren Namenskonventionen.
  5. Fügen Sie Ihren neuen Stil und zeigen Sie etwas von Bedeutung.
  6. Schließlich importieren Sie das neue stylesheet in “src/styles/Stil.weniger".

Szenario #3

Wenn Sie möchten fügen Sie eine neue style-definition für eine Komponente (das heißt, es wird nur verfügbar sein, die Komponente, wo die Komponente wird in der Anwendung verwendet wird), dann:

  1. Gehen Sie auf "src/components".
  2. Finden Sie die Komponente, die Sie möchten, um Stil.
  3. Finden Sie das stylesheet für die Komponente, die innerhalb der Komponente-Verzeichnis.
  4. Schließlich, fügen Sie den neuen Stil und zeigen Sie etwas von Bedeutung.

Dieser guide:

  • Gedient, um unsere Stile organisiert.
  • Gehalten werden die Formatvorlagen arbeiten nach der Vererbung hatten wir gegründet, weil überschreibt gemacht wurden, an den richtigen stellen.
  • Vermieden Entwickler zu kompliziert Regeln.
  • Verhindert Stile undicht, um nicht-intendierte Elemente.

3. Etablieren Sie Ihre Coding-Standards

Ihre coding-standards oder CSS-style-guide bezieht sich auf die Art und Weise Ihr team hat vereinbart, über das schreiben von CSS. Dies beinhaltet die best practices auf das schreiben von code, wie Formatierung, Namensgebung, syntax und Konventionen. Viele Unternehmen haben gemeinsam die Art und Weise Sie es tun (dieser Artikel von CSS-Tricks hat sich eine tolle Zusammenstellung: CSS-Style-Guides). Hier sind ein paar Möglichkeiten, die ich es hilfreich finden, teilen diese Art von Informationen:

Don ' TS vs. Do-Liste

Verwenden Sie dieses format, um darauf hin, die Dinge, die Sie vermeiden wollen, und bietet eine sinnvolle alternative. Dies beseitigt Unklarheiten und ermutigt die Menschen zu tun, eine bestimmte Sache. Zum Beispiel:

Don ' TS
Tun
Nicht mit Tabulatoren für die Einrückung.
Verwenden Sie vier (4) Leerzeichen für die Einrückung.
Verwenden Sie nicht under_scores oder "camelCase" zu Namen von Klassen oder IDs.
Verwenden Sie Bindestriche, um Wörter zu trennen.
Nicht verwenden, Klassen-und ID-Namen spiegeln die zugrunde liegenden markup-Struktur. .container-und span .klein-header-div sind schlechte Namen.

Denke, über CSS in Hinblick auf die Objekte und verwenden Sie einfache Substantive als Namen. .global-Alarm und .Abzeichen sind gute Namen.

Don ' T use IDs und übermäßig-spezifischen Selektoren zum Stil. Diese nur verwendet werden, wenn unbedingt notwendig (z.B. Formular-Steuerelemente oder Seite Anker).
Verwenden Sie Klassen zu erleichtern, Wiederverwendbarkeit und reduzieren Sie CSS-Selektor-Spezifität Konflikte.

Best-Practices-Liste

Fassen Sie Ihre Richtlinien in best practices und beinhaltet Beispiele. Dadurch wird jeder leichter zu Lesen und zu verstehen. Zum Beispiel:

Best Practices Beispiel
Schreiben mehrerer Selektoren auf separaten Zeilen. .btn,
.btn-link {
}
Beinhalten ein Leerzeichen zwischen dem Selektor und der öffnenden Klammer. .Selektor {
}
Verwenden Sie die Kurzform für hex-Werte, wenn möglich. #fff vs #ffffff
Schreiben Sie hex-Werte in Kleinbuchstaben. #3d3d3d vs #3D3D3D
Schließen Sie die URLs in einfache Anführungszeichen gesetzt werden. In der Regel, einzelne Zitate sind vorzuziehen, doppelte Anführungszeichen, da Sie einfacher zu geben. url ('/Bild.png') vs url ("/Bild.png")
Nicht verwenden Einheiten für null (0) - Werte, außer für die Winkel (deg) und die Zeit (s oder ms).
margin-right: 0; vs margin-right: 0px;

Die Art und Weise der Entwickler schreibt den code können erheblich unterscheiden sich von den anderen. Dies ist, warum es wichtig ist für Ihr team und setzen coding-standards. Dadurch wird sichergestellt, dass code konsistent über ein Projekt, das macht es einfacher zu Lesen, zu schreiben und abgeben. Aber stellen Sie sicher, dass alles, was Sie in Ihrem coding-standards ist eine Praxis, Ihr team hat getroffen.

Ich arbeitete an einem Projekt, wo wir diese in unserem Leben-Stil-guide. Als Teil des code, haben wir uns dazu verpflichtet und gedrängt, diese best practices auf die repo. Dann, um sicherzustellen, dass jeder an Bord war, jeder im team hatte zu genehmigen, die pull-Anforderung, bevor wir fusionieren. Dies garantiert, dass jeder hatte, um Zeit zu überprüfen und zu diskutieren.

4. Vermeiden Sie Lange Stylesheets

Wenn Sie brechen Ihre Stile in kleinere und stärker fokussierte stylesheets ist es einfacher zu dokumentieren. Sie können auch Zeit sparen, indem nicht mit, um zu dokumentieren, was wird selbsterklärend.

Zum Beispiel, anstatt dass eine 800 line-stylesheet mit allen Variablen, die Sie verwenden können, in einem Thema, können Sie eine Datei für jede der Variablen-Typen. Dies wird sparen Sie Zeit, indem nicht mit, um einen Bildlauf nach oben und unten in der Datei versucht, etwas zu finden! Denke auch an die Zeit, die Sie sparen können, indem nicht mit, um den index zu aktualisieren, jedes mal, wenn Sie hinzufügen oder umbenennen einen neuen Abschnitt.

In einer langen Datei, ein long index...

Brechen Sie eine Datei, kein index erforderlich ist:

Ein weiteres Beispiel zu berücksichtigen, wenn die Arbeit in großen Anwendungen ist das modlet workflow. Es erklärt, warum die Arbeit mit kleineren Dateien organisiert von Komponenten ermöglicht die Prüfung und die Montage in Ihrer app einfach mehr.

5. Dokument Mit CSS ein Style Guide im Hinterkopf

Ein großer Teil der Dokumentation von CSS ordentlich zu tun hat mit schreiben gute CSS-und Umgekehrt. Dies bedeutet, dass auch wenn der Staat der CSS-code-Basis möglicherweise nicht die beste, die Durchsetzung von Unterlagen Regeln, die Sie bewegen können, hin zu einem besseren system.

Dies ist, wo das dokumentieren von CSS mit einem Stil, der guide in den Sinn kommt in den Ort. Die Idee dahinter ist, dass ein style guide kann Ihnen helfen, festzustellen, eine gute Struktur für die CSS da, um eine zu erstellen, müssen Sie unterscheiden zwischen:

  • die baseline-Stile definieren das Aussehen und Verhalten Ihrer Anwendung (einschließlich CSS-frameworks, die Sie verwenden)
  • die Anpassungen, die durchgeführt werden, um bestimmte Komponenten, und
  • die Anpassungen, die durchgeführt werden, um zu bestimmten Seiten.

Der Großteil der CSS-sollten aus der baseline-Stile, wie Sie überall in der Anwendung und wirken auf alle Elemente in Ihrem ursprünglichen Zustand. Benutzerdefinierte Stile stattfinden soll, wie Sie Komponenten hinzufügen, mit einem bestimmten Aussehen und Verhalten, oder in den Fällen, in denen das layout eines Elements oder einer Komponente in eine Seite es erfordert.

Eine großartige Möglichkeit, um zu erfassen, wie diese speziellen setup arbeiten können, in Ihrer Anwendung ist das erstellen eines style guide-XML-sitemap. Wenn man weiß, wie ein style guide sieht aus wie in Ihrer Anwendung können Sie die Elemente des Dokuments mit, dass in mind. Zum Beispiel, wenn Sie definiert haben, in Ihrem style-guide, wie buttons und Navigationen zu sehen, es ist klar, wo sollten Sie neue Stile und Dokumentation für Sie (in “Tasten.css" und "navs.css"). Aber was ist eine navigation, die aus Knöpfen?

Mit einem style guide kann Ihnen helfen, diese Entscheidung zu treffen, wie Sie können vergleichen, wie buttons und Navigationen look, aus einem display und einer markup-Perspektive. Betrachten wir dieses Beispiel:

In diesem Fall gibt es zwei mögliche Standorte für die CSS, welche die navigation aus Knöpfen:

  1. Wenn das markup orientiert sich an der Struktur der anderen Navigationen, mit einer Liste von links, oder ein mit links, die Aussehen wie buttons, fügen Sie dann der nav-Stile “navs.css".
  2. Wenn das markup, das Sie verwenden, ist fügen Sie dann die Stile an “ - Tasten.css". Man könnte sogar hinzufügen, es als eine separate stylesheet (like-Button “-Gruppe.css"). In diesem Fall der Begriff "navigation" nicht angemessen wäre mehr, da die HTML-buttons sind weniger leicht zugänglich als Navigations-Elemente.

6. Aufschlüsselung Stylesheets In Abschnitte

Sobald Sie gebrochen haben Sie Ihre stylesheets in überschaubare Dateien, dann können Sie diese übung durch den Abbau jeder Art in einzelne Abschnitte.

Um damit zu beginnen, jedem stylesheet, sollte zumindest einen Titel und (wenn sinnvoll) eine kurze Beschreibung. Der Titel könnte so einfach sein wie der name der Datei, aktiviert zu schauen, mehr wie ein Titel (BSP: "Tasten" für die stylesheet "Tasten.css" ist), oder könnte es der gleiche sein wie der name der Datei, wie diese:

Ich finde mit der Dateinamen-besonders nützlich beim Debuggen des Codes in den browser, und meist, wenn die Datei kompiliert wurde, mit anderen Dateien, wie bekomme ich eine Referenz auf die Datei, wo der Stil lebt.

Beachten Sie auch, dass die Kommentar-Stil, die ich verwendet, beginnt mit /** vs eben /*. Dies ist eine Konvention in der JSDoc-zu analysieren, Kommentare, sollten in der automatisch generierten Dokumentation. Ich empfehle, mit diesem Stil, wie viele Leben und style-guide-Generatoren verwenden die JSDoc-format, so dass, wenn Sie bereit sind, mit einem generator, der code wird sehr wenig zusätzliche Arbeit.

In jedem Fall, Sie können andere Stile zu bezeichnen, dass ein Abschnitt wie:

Zum Teil hängt dies davon ab, was Ihr team stimmt, ist der beste Weg, um einen Abschnitt abheben. Die einzige Voraussetzung ist die Verwendung von /* am Anfang und */ am Ende. Was wirklich zählt, ist, dass je nachdem, welcher Ansatz, den Sie verwenden, halten Sie es und verwenden Sie es in Ihrem CSS-code in einer konsistenten Art und Weise.

Wenn Sie denken, eine Beschreibung könnte hilfreich sein, in einem bestimmten stylesheet, dann fügen Sie es als Teil dieses ersten Kommentar. Zum Beispiel:

Dadurch verstärken die Idee, dass es ein Abschnitt. Versuchen Sie auch, um brechen die Beschreibung in mehrere Zeilen (Harry Roberts empfiehlt, bis zu 80 Zeichen), so dass es leichter zu Lesen, während Sie mehrere Dateien öffnen oder beim Lesen auf Github.

Nach dem hinzufügen einen Titel und eine Beschreibung haben, können Sie einen Schritt weiter gehen, durch den Abbau der Stile, die innerhalb des stylesheet in Abschnitte. Um dies zu tun darüber nachzudenken, wie logisch zu erklären, den Inhalt eines Stylesheets sinnvoll. Zum Beispiel die stylesheet “Tasten.css" wird in der Regel einen Abschnitt, wo die Standard-Stil, der eine Schaltfläche definiert, indem nur die Anwendung der Klasse .btn. Dann wird es zusätzliche Stile, die festlegen, in verschiedenen Farben, Größen und Konfigurationen angewendet werden können, in Verbindung, um weitere anpassen von Aussehen und Verhalten. Erstellen von Abschnitten für jeden dieser Stile wird es einfacher zu verstehen und herauszufinden, wo neue Klassen oder überschreibt erscheinen soll. Auch ist es weniger einschüchternd zu schauen, eine Datei, wenn der code vorgestellt, in snippets im Vergleich zu einer langen Datei, wo es ist schwer zu sagen, wo Stile beginnen und enden.

Betrachten wir dieses vergleichende Beispiel. Zuerst ein KLEINER code-block ohne Abschnitte:

Und die gleiche code-block mit Abschnitten:

7. Index die Inhalte Ihrer Stylesheets

Dies ist eine großartige Möglichkeit, um eine Momentaufnahme von dem, was in der stylesheet und ein muss in die Projekte, in denen, aus welchem Grund auch immer, lange stylesheets sind da, um zu bleiben (nicht ein fan von diesen Projekten, aber Sie kommen vor!).

Ein stylesheet-index-Regel sieht wie folgt aus:

Und obwohl ich Liebe es, wie ordentlich und nützlich Sie sein können, ich muss zugeben, Sie können einfach vergessen, und deshalb veraltet. Sie sind auch ein Schmerz zu aktualisieren, wenn Sie lang sind, und Sie sind mit zahlen (also vermeiden Sie diese!)

Eine alternative Möglichkeit der Verwendung von Indizes ist, lassen Sie einen style-guide-generator die Arbeit für Sie tun, indem Sie auf Ihrer stylesheets, finden die Abschnitte, die Sie definiert haben, und generieren Sie einen index für Sie. Ich werde erweitern Sie mehr zu diesem Thema am Ende dieses Artikels.

8. Finden Sie den Sweet Spot zu Dokumentieren

Hier ist, wo das Geheimnis der Dokumentation liegt. Es ist einfach zu weit und gehen in eine Dokumentation frenzy einmal, dann vergessen Sie es und am Ende mit nur einem Teil Ihrer Codebasis über-dokumentiert und der rest ist ohne Papiere. Wie bei allem im Leben, das Geheimnis ist die balance zu finden. Dokument jene Bereiche, in denen Aufmerksamkeit erforderlich ist, da gibt es unvorhergesehene Abhängigkeiten, zusätzliche Ressourcen oder wichtige Hinweise im Hinterkopf haben. Das ist zu sagen, dass nicht jedes bit der code dokumentiert werden sollte, aber es ist auf jeden Fall nützlich, um es zu brechen in Stücke und erklären, was diese Stücke werden, wenn nötig. Auf diese Weise, Dokumentation wird ein nützliches Werkzeug, das ist Teil Ihres Workflows-und nicht ein nachträglicher Einfall, dass Sie vermeiden, zu tun. Aber wie wollen Sie genau tun? Hier ein Beispiel:

Lassen Sie uns sagen, dass Sie gehen, um zu implementieren, die markup und CSS für die folgenden card-Komponente:

card base design

Blick auf die Entwürfe, die Sie identifizieren können, die folgenden Stil-Muster:

  • Die Karte base design
  • Die grid-Karten
  • Die Karten Liste
  • Die Karte dark version

Sie können dann brechen die CSS-Implementierung mit diesen mustern im Hinterkopf und verwenden Sie die Dokumentation, um Sie zu führen. So starten Sie mit, Ihre “Karten.css" - stylesheet kann ein einfaches intro wie folgt:

Sie können mehr nützliche Informationen in der Einleitung, aber da Sie gerade erst die ersten Schritte etwas einfacher kann helfen, legen Sie in der Dokumentation Skelett.

Dann fügen wir die Abschnitte, in denen Sie arbeiten werden Ihre Arten, in:

Mit diesen Abschnitten im Verstand, können Sie visualisieren, wie der code strukturiert werden sol l. Sie wissen, dass Sie sollten die grundlegenden Definitionen der Karte flexibel und unabhängig genug sind, können Sie leicht die Karte funktioniert in einem raster, Liste oder dunklen Versionen.

Dann, wie Sie den code schreiben, können Sie mehr spezifische mit Ihren Kommentaren:

Das halte ich für das grundlegende Niveau der Dokumentation sollten Sie auch, denn es dient als Leitfaden, um layout den code, und schnell informiert, wie die Dinge organisiert sind, für die nächste person, die arbeitet es.

Die nächste Stufe ist das hinzufügen von Kommentaren zu einer bestimmten Regel, und das kann verwendet werden, um zu erklären, was diese Regel tut, weil es nicht auf einen Blick ersichtlich. Zum Beispiel:

Die Schönheit dieses Ansatzes ist, dass die Dokumentation ist dort zu unterstützen und zu informieren, die Umsetzung, wie Sie gehen, im Vergleich zu etwas, das zu einem späteren Zeitpunkt Hinzugefügt.

Hier sind ein paar weitere Beispiele für die Bootstrap Rahmen, die zeigen, dass, wenn die Kommentare sinnvoll sind, und Wann lohnt es sich, gehen mehr ins detail.

Beispiel #1

Dieser Kommentar stellt klar, warum diese Stile existieren und was Sie tun. Es ist auch kurz und auf den Punkt, die Kommunikation der Idee, in einer lockeren Sprache.

Beispiel #2

Dies ist ein großartiges Beispiel für die Dokumentation, die geht mehr in die Tiefe, erklärt die Logik hinter eine Umsetzung der Entscheidung und die Bereitstellung von links zu weiterführenden Informationen.

Nehmen es einen Schritt Weiter

Mit diesen best practices im Verstand, ist der nächste Schritt zum integrieren des living style guide als Teil Ihrer Dokumentation. Ein living Styleguide ist ein Dokument, das zeigt die Kommentare, die Sie haben enthalten in Ihrem code aufgebaut wie eine website, so dass Sie navigieren können, die Dokumentation getrennt von der source-code.

Was macht living style guides mächtig ist, dass die eigentliche Dokumentation lebt mit dem code und kann leicht aktualisiert werden, wie Ihr code änderungen, so dass es synchron bleibt und relevant sind. Der zusätzliche Vorteil ist, dass Sie können diese Dokumentation zur Verfügung, um andere Menschen in Ihrem team, die vielleicht nicht die direkte Interaktion mit dem code (wie Designern, Produkt-Managern oder QA-Ingenieure). Diese team-Mitglieder würden auch finden es hilfreich zu wissen, wie die UI-Gestaltung bis.

In einem lebendigen Stil-guide, können Sie interaktive Demonstrationen Ihres Codes und Sie können weiter zu organisieren Sie Ihre Dokumentation unabhängig von der code-Struktur.

Fazit

Dokumentieren von CSS beginnt mit klaren Regeln und eine gut strukturierte code-Basis. Wenn Sie fertig sind als Teil des Workflows dienen, sondern auch als Leitfaden zur Strukturierung von code und halten Sie Sie organisiert, wie es wächst. Dies hat den zusätzlichen Vorteil, dass es klar ist, wo die Dinge sind und wo neuer code Hinzugefügt werden sollte, Lockerung des onboarding neuer Mitglieder während des fast-tracking-Entwicklung.

Nützliche Ressourcen

Zur Erinnerung: 8 Best Practices

  1. Legen Sie die Grundregeln
  2. Finden Sie den sweet spot zu dokumentieren
  3. Index die Inhalte Ihrer stylesheets
  4. Aufschlüsselung stylesheets in Abschnitte
  5. Dokument mit CSS ein style guide im Hinterkopf
  6. Vermeiden Sie lange stylesheets
  7. Etablieren Sie Ihre coding-standards
  8. Erklären Sie die Struktur der code-Basis
Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.