.jpg?width=1000&height=500&name=Design%20ohne%20Titel%20(11).jpg)
JavaScript oder TypeScript Projekte werden immer größer, egal ob im Frontend oder im Backend. Doch nicht nur die Codebasen werden größer, auch die Teams werden tendenziell größer. Umso wichtiger sind gemeinsame Standards – sie sollen die Qualität sicherstellen, aber auch eine gemeinsame Arbeitsbasis schaffen, d. h. durch gemeinsame Standards ist es einfacher für Teammitglieder sich in unterschiedlichen Codestellen zurechtzufinden.
Wie man diese gemeinsamen Standards aufstellt und deren Einhaltung sicherstellt, zeigt dieser Blogbeitrag.
Coding Guidelines
Für jedes Team ist es sinnvoll, gemeinsame Coding Guidelines aufzustellen. Die größte Akzeptanz finden Coding-Guidelines, wenn sie vom Team selbst erarbeitet werden. Die Regeln sollten dabei nicht statisch sein, sie können sich durchaus im Verlauf der Entwicklung ändern. Beim Aufstellen der Regeln sollte sich das Team die Frage stellen: „Was hilft uns?“.
Beispielsweise gibt es in meinem Team die Regel an jede Entität einen Kommentar zu schreiben – der Gedanke dahinter ist, dass diese Kommentare den Teammitglieder helfen, zu verstehen, was die Funktion der Entitäten ist und wie sie zusammenhängen.
Wenn man solche Regeln aufstellt, ist es wichtig, dass man realistisch bleibt: Wir alle kennen Kommentare, die die Funktion einer Methode beschreibt und dann guckt man in den Code und stellt fest, dass der Kommentar veraltet ist und die Methode mittlerweile eine ganz andere Funktionalität bereitstellt. Natürlich gilt, am besten ist Code, der selbsterklärend ist und nicht kommentiert werden muss.
Das Team sollte nicht den Eindruck bekommen, dass es sich selbst geißelt, es muss selbst Sinn in den Guidelines sehen, denn es muss selbst diese Regeln umsetzen und deren Einhaltung, wie z. B. durch die Durchführung von Code Reviews, sicherstellen.
Code Reviews
Code Reviews sind hilfreich, um die Codequalität zu erhöhen, denn vier Augen sehen mehr als zwei und gleichzeitig helfen sie auch beim Wissenstransfer. Wer Code liest und sich darüber austauscht, ist auch informiert.
Man kann diesen Gedanken auch noch weiterdenken und vor der Umsetzung eines Features gemeinsam darüber sprechen, wie es umgesetzt werden könnte. Auch hier gilt – ein Team hat mehrere Handlungsalternativen im Kopf als eine Person. Diese Implementierungsalternativen kann man gemeinsam bewerten, daraus eine Entscheidung ableiten und diese dann implementieren. Durch diesen Prozess sind dann alle im Team über die Änderung informiert, auch wenn sie nicht an der Implementierung beteiligt waren. Solch ein Prozess führt zu einem gewissen Overhead und es muss im Team jedes Mitglied gleichberechtigt sein.
Standards sollten Automatismen sein
Damit Standards in großen Projekten etabliert werden können, sollten sie begriffen werden wie Automatismen: Vor dem Merge jeder Änderung erfolgt ein Code Review, wichtige Features werden vor der Entwicklung im Team besprochen. Noch besser ist es jedoch, wenn Standards automatisiert eingehalten werden. Hier können Tools uns helfen. Das fängt bei der Unterstützung in der Entwicklungsumgebung an und sollte auf dem CI Server bei der automatisierten Kontrolle der Qualitätsziele enden.
.editorconfig
Editorconfig ist ein Standard für die Konfiguration von Codeeditoren. Der Standard ist herstellerunabhängig und wird von diversen Editoren wie VS Code, Webstorm etc. unterstützt. In der Datei .editorconfig können Standards wie Einrückung per Leerzeichen oder Tab, Größe der Einrückung und vieles mehr angegeben werden.
Weitere Informationen gibt es unter https://editorconfig.org.
TypeScript
TypeScript ist eine Obermenge von JavaScript, die diese um statische Typisierung erweitert. Statische Typisierung hilft Fehler bereits zur Entwicklungszeit zu entdecken und gleichzeitig sind die Typen eine Art Dokumentation, die uns aufzeigt, was wir wo zuweisen können. TypeScript kann auch nach und nach in bestehende Projekte eingebunden werden. Es kann sowohl im Editor als auch im CI Build zur Aufdeckung von Typfehlern verwendet werden.
Weitere Informationen gibt es unter https://www.typescriptlang.org.
ESLint
ESLint ist ein Tool, welches statische Codeanalyse für JavaScript und TypeScript bietet. Es prüft ob der analysierte Code den vorgegebenen Regeln entspricht (etwa ob, wenn möglich, const statt let verwendet wird). Es existieren diverse vordefinierte Regelwerke, die sich durch eigene Regeln ergänzen lassen. Man kann für jede Regel konfigurieren, wie ESLint Findings dieser Regel kategorisiert: als Fehler oder Warnung. ESLint kann in diversen Editoren oder als im CI Build genutzt werden. Für einige Regeln bietet ESLint die Möglichkeit automatisch Findings zu beheben.
Weitere Informationen gibt es unter https://eslint.org.
Mit dem Package typescript-eslint kann ESLint auch TypeScript Code analysieren.
Anmerkung: Früher gab es für TypeScript das Tool TSLint. Dieses wird seit längerem nicht mehr weiterentwickelt und es wird der Einsatz von ESLint empfohlen.
Prettier
Prettier ist ein Code Formatter, der viele Sprachen formatieren kann. Das Besondere an Prettier ist, dass das Prettier Team sehr eng eigene Regeln für Code Formatting vorgibt: Dies hat zur Folge, dass man nur wenig selbst konfigurieren kann. Dies ist durchaus gewollt. Hand aufs Herz: ich kann mich nicht mit jeder dieser Meinungen anfreunden, ganz ehrlich. Aber: es geht nicht um persönlichen Geschmack – es geht darum das mit möglichst wenig Aufwand der Code überall gleich formatiert ist! Und da muss man den Autoren einfach lassen: Prettier funktioniert immer zuverlässig und kommt zum selben Ergebnis. Da ist mein persönlicher Geschmack nebensächlich, schließlich möchte ich nicht mit meinen Kolleg:innen über Geschmack streiten.
Prettier kann sowohl in diversen Editoren als auch über die Kommandozeile ausgeführt werden.
Weitere Informationen gibt es unter https://prettier.io.
Stylelint
Stylelint ist ein Tool für statische Codeanalyse für Styles wie etwa CSS oder Sass. Es gibt diverse Regeln wie etwa das Verbot der Nutzung von !important. Auch hier können Regelwerke definiert werden und Regeln können kategorisiert werden als Warnung oder Fehler.
Weitere Informationen gibt es unter https://stylelint.io.
Husky
Husky ist ein Tool mit dem sich Git Hooks realisieren lassen. So können beliebige Skripte etwa vor dem Commit, Push oder Ähnlichem ausgeführt werden. So kann man zum Beispiel verhindern, dass Code, der nicht den Richtlinien entspricht, überhaupt versioniert werden kann oder man kann automatisch seinen Code Formatter vor dem Commit laufen lassen.
Weitere Informationen gibt es unter https://github.com/typicode/husky.
SonarQube
SonarQube ist ein Tool, welches als zentrales Codequalitätsgateway genutzt werden kann, d. h. hier können Ergebnisse der Analysen von ESLint, Stylelint und weiteren Tools zentral aggregiert werden. Dazu bietet SonarQube vorgefertigte Regelsets, welche man nutzen kann. Weiterhin kann man eigene Qualitätsziele definieren, die SonarQube prüft und so kann man bspw. den CI Build fehlschlagen lassen, wenn es schwere Verstöße gegen die Qualitätsziele gibt.
Weitere Informationen gibt es unter https://www.sonarqube.org.
Natürlich ist die Liste der gezeigten Möglichkeiten nur eine Auswahl, aus meiner Sicht, sind es die wichtigsten Tools, die einem helfen, eine große JavaScript/TypeScript Codebasis unter Kontrolle zu behalten.
Sollten Sie Fragen zu diesem Artikel haben, melden Sie sich gerne bei uns. Wir helfen Ihnen gerne bei der Umsetzung Ihrer JavaScript/TypeScript Projekte.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
