Die Programmiersprache TypeScript dominiert bei Communardo ganz klar den Bereich Microsoft Development. Das typisierte JavaScript ist seit SharePoint Online und dem SharePoint Framework als Sprache gesetzt - und das ist auch gut so. Die Gründe dafür werden hier im Techblog noch häufiger in Beiträgen wie den TypeScript-Tipps ein Thema sein.
Es lässt sich allerdings immer wieder beobachten, wie alteingesessene JavaScript-Entwickler das Thema TypeScript und Typisierung - wie ich meine - vorschnell abtun.
Ob sich TypeScript bewährt kann letztlich nur die Praxis zeigen. In diesem Beitrag sollen daher (über Bande) einmal andere Entwickler zu Wort kommen, die ihren Weg zu TypeScript gefunden haben. Beim letzten Treffen des Dresdner JavaScript Meetups gab es einen spannenden Bericht aus der Praxis der Webentwicklung. Lesen Sie weiter, welche Erkenntnisse wir aus diesem Projekt gewinnen können.
Auftraggeber forderte TypeScript
Die Softwarearchitekten Sergey und Dan waren gekommen, um von einem erfolgreich abgeschlossenen Projekt zu berichten. Sie sind bei einem Dresdner IT-Dienstleister beschäftigt und waren mit der Entwicklung des Frontends für einen großen Kunden betraut. Und großer Kunde bedeutet hier: der Name ist garantiert jedem bekannt.
Da der Kunde wohl bereits schlechte Erfahrungen mit anderen Dienstleistern gemacht hat, hat er TypeScript als Sprache vorgegeben. Das allein würde mich noch nicht von den Vorteilen einer Sprache überzeugen, ist aber ein Baustein im Gesamtbild.
Weitere Technologien, Frameworks und Tools waren (Achtung: Buzzword-Bingo): React, Swagger, Redux, SASS, typed CSS, CSS modules, Webpack, Happypack, Storybook.
Code-Beispiele führten durch diesen faszinierenden und professionell eingesetzten Mix aus Technologien. Die Präsentation ist in den Kommentaren zum Meetup verlinkt und hier direkt aufrufbar: Building Finder.
Den Fokus möchte ich auf Erkenntnisse legen, die das Projekt vor allem in Bezug auf die Typisierung der Sprachen TypeScript und CSS hervorgebracht hat.
Vorteile der Typisierung im Projekt
Typisierung hilft, Laufzeitfehlern vorzubeugen
Sergey und Dan beschrieben einen Anwendungsfall, der einen weiteren interessanten Blickwinkel auf die Typisierung eröffnet hat.
Die Entwicklung von Frontend und Backend im Projekt fand voneinander getrennt statt. Das Frontend war abhängig von Schnittstellen, die der Kunde im Backend zur Verfügung gestellt hat. Dabei kam es vor, dass im Backend Schnittstellen verändert wurden, ohne dass das Frontend-Team über diese Änderungen informiert wurde. (Prima!)
Der Ansatz, damit zurechtzukommen, war:
- die Beschreibung der Schnittstellen mittels Swagger
- die automatische Erzeugung des Objektmodells auf Basis der Schnittstellenbeschreibung
- die konsequente Typisierung mittels TypeScript bis in die React-Komponenten hinein
- die regelmäßige automatische Aktualisierung des generierten Codes
Sobald sich nun im Backend Schnittstellen unangekündigt ändern, fällt diese Änderung im Frontend sofort auf. Der Compiler meldet sich mit einer Fehlermeldung. Ohne TypeScript würden die Fehler ins Frontend wandern und zur Laufzeit auftreten. Und selbst Testautomatisierung würde nur Sicherheit geben, wenn die Abdeckung 100% betragen würde.
Typisierung hilft beim Refactoring
Ein weiterer genannter großer Vorteil der Typisierung war das einfache Refactoring. Sobald Fehler beim Umbau des Codes auftauchen, schlägt der Compiler Alarm.
Typisierung hilft neuen Teammitgliedern beim Einstieg
Sobald neue Kollegen in die Entwicklung einsteigen und bestehenden Code verändern, bestehen gewisse Risiken.
Hier hilft die Typisierung von Code, die Lernkurve abzuschwächen. Der Code ist einfacher lesbar und der Kontext durch Autovervollständigung leichter erlernbar.
Die Typisierung von CSS zeigt schnell, welche Klassen bereits im Einsatz sind und wie das Namensschema aussieht.
Typisierung macht fehlende Testautomatisierung verschmerzbar
Dieser Vorteil ist schon ein wenig grenzwertig. Aber es scheint, dass typisierter Code zur Entwicklungszeit bereits so viele Fehler transparent machen kann, dass fehlende oder unvollständige Testautomatisierung kein großes Problem sein muss.
Typisierung ist nachteilig für's Gefühl
Die Nachteile sollen nicht verschwiegen werden und lassen sich in zwei Kategorien einteilen.
Boilerplate-Code und Workarounds
Um durchweg Typisierung zu erhalten sind teilweise Mehraufwände zu erbringen, denn nicht alle Teile im Technologie-Mix sind bereit für die Typisierung. Diese müssen teilweise zu ihrem Glück gezwungen werden.
Für JavaScript-Bibliotheken müssen häufig sogenannte Typings erstellt werden, sofern diese noch nicht zur Verfügung stehen. Die Typings stülpen dem JavaScript eine Typdefinition über. Dies ist Code, der in einem JavaScript-Projekt nicht geschrieben werden müsste.
Strengere Regeln
Die Typisierung des Codes erlaubt Prüfungen, die es sonst nicht gäbe. Je nachdem, wie streng die Prüfungen konfiguriert wurden, kann die IDE gehörig nerven: Nicht verwendete Variablen, Zuweisung eines Strings an eine Variable des Typs number, etc. Vieles davon würde in JavaScript keine Probleme verursachen und ohne Weiteres durchgehen.
Diskussionen unter JavaScript-Entwicklern gehen häufig in diese Richtung, meist in Verbindung mit gerunzelter Stirn. Die Erfahrung und Erfahrungsberichte wie die hier beschriebenen zeigen aber, dass es sich lohnt, diese Nachteile mit den vielen Vorteilen sorgsam abzuwägen, bevor eine Entscheidung getroffen wird.
Fazit
Das Fazit der beiden Vortragenden war: Wir würden es wieder tun! Die größten Erfolgsfaktoren für das Projekt waren Code Reviews und TypeScript.
Dem möchte ich heute nichts hinzufügen und wünsche: Happy Coding!