Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Erfahrungsbericht: TypeScript "saved our a*ses"

In diesem Beitrag sollen 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, welche Erkenntnisse wir aus diesem Projekt gewinnen können.

Die Programmiersprache TypeScript domi­niert bei Communardo ganz klar den Bereich Microsoft Development. Das typi­sierte JavaScript ist seit SharePoint Online und dem SharePoint Framework als Sprache gesetzt – und das ist auch gut so. Die Gründe dafür wer­den hier im Techblog noch häu­fi­ger in Beiträgen wie den TypeScript-Tipps ein Thema sein.

Es lässt sich aller­dings immer wie­der beob­ach­ten, wie alt­ein­ge­ses­sene JavaScript-Entwickler das Thema TypeScript und Typisierung – wie ich meine – vor­schnell abtun.

Ob sich TypeScript bewährt kann letzt­lich nur die Praxis zei­gen. In die­sem Beitrag sol­len daher (über Bande) ein­mal andere Entwickler zu Wort kom­men, die ihren Weg zu TypeScript gefun­den haben. Beim letz­ten Treffen des Dresdner JavaScript Meetups gab es einen span­nen­den Bericht aus der Praxis der Webentwicklung. Lesen Sie wei­ter, wel­che Erkenntnisse wir aus die­sem Projekt gewin­nen kön­nen.

Auftraggeber forderte TypeScript

Die Softwarearchitekten Sergey und Dan waren gekom­men, um von einem erfolg­reich abge­schlos­se­nen Projekt zu berich­ten. Sie sind bei einem Dresdner IT-Dienstleister beschäf­tigt und waren mit der Entwicklung des Frontends für einen gro­ßen Kunden betraut. Und gro­ßer Kunde bedeu­tet hier: der Name ist garan­tiert jedem bekannt.

Quelle: Sergey Ryzhov

Da der Kunde wohl bereits schlechte Erfahrungen mit ande­ren Dienstleistern gemacht hat, hat er TypeScript als Sprache vor­ge­ge­ben. Das allein würde mich noch nicht von den Vorteilen einer Sprache über­zeu­gen, ist aber ein Baustein im Gesamtbild.

Weitere Technologien, Frameworks und Tools waren (Achtung: Buzzword-Bingo): React, Swagger, Redux, SASS, typed CSS, CSS modu­les, Webpack, Happypack, Storybook.

Code-Beispiele führ­ten durch die­sen fas­zi­nie­ren­den und pro­fes­sio­nell ein­ge­setz­ten Mix aus Technologien. Die Präsentation ist in den Kommentaren zum Meetup ver­linkt und hier direkt auf­ruf­bar: Building Finder.

Quelle: Sergey Ryzhov

Den Fokus möchte ich auf Erkenntnisse legen, die das Projekt vor allem in Bezug auf die Typisierung der Sprachen TypeScript und CSS her­vor­ge­bracht hat.

Vorteile der Typisierung im Projekt

Typisierung hilft, Laufzeitfehlern vorzubeugen

Sergey und Dan beschrie­ben einen Anwendungsfall, der einen wei­te­ren inter­es­san­ten Blickwinkel auf die Typisierung eröff­net hat.

Die Entwicklung von Frontend und Backend im Projekt fand von­ein­an­der getrennt statt. Das Frontend war abhän­gig von Schnittstellen, die der Kunde im Backend zur Verfügung gestellt hat. Dabei kam es vor, dass im Backend Schnittstellen ver­än­dert wur­den, ohne dass das Frontend-Team über diese Änderungen infor­miert wurde. (Prima!)

Der Ansatz, damit zurecht­zu­kom­men, war:

  • die Beschreibung der Schnittstellen mit­tels Swagger
  • die auto­ma­ti­sche Erzeugung des Objektmodells auf Basis der Schnittstellenbeschreibung
  • die kon­se­quente Typisierung mit­tels TypeScript bis in die React-Komponenten hin­ein
  • die regel­mä­ßige auto­ma­ti­sche Aktualisierung des gene­rier­ten Codes
Quelle: Sergey Ryzhov

Sobald sich nun im Backend Schnittstellen unan­ge­kün­digt ändern, fällt diese Änderung im Frontend sofort auf. Der Compiler mel­det sich mit einer Fehlermeldung. Ohne TypeScript wür­den die Fehler ins Frontend wan­dern und zur Laufzeit auf­tre­ten. Und selbst Testautomatisierung würde nur Sicherheit geben, wenn die Abdeckung 100% betra­gen würde.

Typisierung hilft beim Refactoring

Ein wei­te­rer genann­ter gro­ßer Vorteil der Typisierung war das ein­fa­che Refactoring. Sobald Fehler beim Umbau des Codes auf­tau­chen, schlägt der Compiler Alarm.

Quelle: Sergey Ryzhov

Typisierung hilft neuen Teammitgliedern beim Einstieg

Sobald neue Kollegen in die Entwicklung ein­stei­gen und bestehen­den Code ver­än­dern, bestehen gewisse Risiken.

Hier hilft die Typisierung von Code, die Lernkurve abzu­schwä­chen. Der Code ist ein­fa­cher les­bar und der Kontext durch Autovervollständigung leich­ter erlern­bar.

Quelle: Sergey Ryzhov

Die Typisierung von CSS zeigt schnell, wel­che Klassen bereits im Einsatz sind und wie das Namensschema aus­sieht.

Typisierung macht fehlende Testautomatisierung verschmerzbar

Dieser Vorteil ist schon ein wenig grenz­wer­tig. Aber es scheint, dass typi­sier­ter Code zur Entwicklungszeit bereits so viele Fehler trans­pa­rent machen kann, dass feh­lende oder unvoll­stän­dige Testautomatisierung kein gro­ßes Problem sein muss.

Typisierung ist nachteilig für's Gefühl

Die Nachteile sol­len nicht ver­schwie­gen wer­den und las­sen sich in zwei Kategorien ein­tei­len.

Boilerplate-Code und Workarounds

Um durch­weg Typisierung zu erhal­ten sind teil­weise Mehraufwände zu erbrin­gen, denn nicht alle Teile im Technologie-Mix sind bereit für die Typisierung. Diese müs­sen teil­weise zu ihrem Glück gezwun­gen wer­den.

Für JavaScript-Bibliotheken müs­sen häu­fig soge­nannte Typings erstellt wer­den, sofern diese noch nicht zur Verfügung ste­hen. Die Typings stül­pen dem JavaScript eine Typdefinition über. Dies ist Code, der in einem JavaScript-Projekt nicht geschrie­ben wer­den müsste.

Strengere Regeln

Die Typisierung des Codes erlaubt Prüfungen, die es sonst nicht gäbe. Je nach­dem, wie streng die Prüfungen kon­fi­gu­riert wur­den, kann die IDE gehö­rig ner­ven: Nicht ver­wen­dete Variablen, Zuweisung eines Strings an eine Variable des Typs num­ber, etc. Vieles davon würde in JavaScript keine Probleme ver­ur­sa­chen und ohne Weiteres durch­ge­hen.

Diskussionen unter JavaScript-Entwicklern gehen häu­fig in diese Richtung, meist in Verbindung mit gerun­zel­ter Stirn. Die Erfahrung und Erfahrungsberichte wie die hier beschrie­be­nen zei­gen aber, dass es sich lohnt, diese Nachteile mit den vie­len Vorteilen sorg­sam abzu­wä­gen, bevor eine Entscheidung getrof­fen wird.

Fazit

Das Fazit der bei­den Vortragenden war: Wir wür­den es wie­der tun! Die größ­ten Erfolgsfaktoren für das Projekt waren Code Reviews und TypeScript.

Dem möchte ich heute nichts hin­zu­fü­gen und wün­sche: Happy Coding!

Related Posts

Pin It on Pinterest