Willkommen in unserem Interview. Ich habe mir wieder eine Trainerin geschnappt, und zwar Katja Potensky. Schön, dass du da bist. Du bist Software-Ingenieur bei adesso seit 2012 und kommst mit vielen unterschiedlichen Webtechnologien in Verbindung, bist dort Expertin. Hier vor Ort hältst einen Workshop zu TypeScript und dazu stellen wir dir auch gleich ganz viele Fragen.
Viele sagen: „TypeScript ist das bessere JavaScript.“ Können wir gleich diskutieren. Erst mal eine Frage vorweg. Du bist an vielen Projekten tätig. Was interessiert dich denn am meisten an deiner Arbeit, was macht dir Spaß daran?
Das Interessanteste an meiner Arbeit sind Dinge, die mir leider immer noch unbegreiflich sind und nicht gerade das, was am meisten Spaß macht. Ich interpretiere die Frage jetzt einfach mal so, dass es darum geht, was am meisten Spaß macht. Das ist tatsächlich, wenn man mehrere Module oder auch Systeme konzipiert, diese Idee an sein Team weitergibt und sich das Ganze dann irgendwann ein paar Wochen später entwickelt hat. Das ganze System wird online gebracht und es klickt einfach ineinander und funktioniert. Das ist immer noch wie Magie für mich, auch wenn ich die Technologie dahinter verstehe. Es ist immer einfach magisch zu sehen. Man bringt es online, man setzt den Request ab, das Ding funktioniert – einfach großartig. Und das ist auch für das Team ehrlich gesagt immer ein ganz großer Moment und ich habe es mir auch angewöhnt, Go Live Partys zu organisieren. Wenn man mit mir zusammenarbeitet fordere ich sehr viel, aber ich gebe auch sehr viel. Und dann kommt es zu einer Party, die alle verdient haben, nach dem Stress und dem erfolgreichen Go Live.
Du bist unsere TypeScript-Expertin. Was sind die Hauptvorteile von TypeScript im Gegensatz zu JavaScript?
Das ist ganz einfach zu sagen. Auf der einen Seite müssen Entwickler:innen nicht mehr die ganze Code-Base im Kopf behalten, um zu wissen was da gerade passiert. Auf der anderen Seite bietet es die Sicherheit quasi Systeme schreiben zu können, die funktionieren sobald sie kompilieren. Also der ganze Sinn von TypeScript ist es, die möglichst viele Runtime Errors zur Compile time bereits abzufangen. Vielleicht als kleine Erklärung falls es nötig ist: Runtime Erros wären die Fehler die erst auftreten, während man das Programm verwendet. Compile time Fehler sind die, die zu der Zeit auftreten, in der die Entwickler:innen den Code tatsächlich eben schreiben. Und wenn dort schon Dinge abgefangen werden, die in der Produktion erst brechen würden, ist das ein riesengroßer Zeitvorteil. Es ist ein riesengroßer Vorteil für die Moral von Entwickler:innen und fürs Business, weil keine Zeit und kein Geld verloren wird.
Wie einfach ist es dann TypeScript in JavaScript Code-Bases zu integrieren oder gibt es dabei Herausforderungen?
Das hängt sehr stark davon ab, wie die JavaScript Code-Base entwickelt ist. Es gibt Code Bases, die lassen es sich leicht integrieren. Es wurde schon sauber gearbeitet und da muss nur noch beschreiben werden, was man macht. Das ist auch immer so ein Aspekt von TypeScript: Es ist in dem Sinn beschreibend, dass ich die Formen, die in meiner Applikation herumfliegen und die von Funktion zu Funktion gereicht werden, beschreibe und sage: Hey lieber Compiler, das sieht jetzt so und so aus. Je funktionaler eine Applikation ist, desto leichter ist es TypeScript zu migrieren. Objektorientierte Codebases sind auch meistens kein Problem, denn in der Objektorientierung ist bereits eine Form der Modularisierung. Es gibt aber auch Codebases, die verwenden JavaScript, in der maximalen Dynamik die JavaScript bietet und das ist sehr hart zu typisieren. Gerade in dem Workshop morgen, werden wir Beispiele sehen, bei denen kann TypeScript einfach nicht weiterhelfen und meines Wissens nach auch keine andere Sprache der Welt. Also kurz gesagt: Es gibt Dinge die JavaScript ermöglicht, die lassen sich einfach nicht als Typen abbilden. Es ist ein klares Jein.
Gibt es Tools und Ressourcen die du empfehlen könntest, um diesen Umstieg leichter zu machen?
Ja. Auf jeden Fall gibt es solche Tools. Ein solches Tool lernen wir morgen kennen zum Analysieren von Dependencies, also von Abhängigkeiten zwischen den Code. Man kann damit praktisch sehen, was braucht jetzt eigentlich welche Datei und wann wird sie zu gewissen Teilen auch gebraucht? Dies ist sehr wichtig, um eine JavaScript Codebase, die typischerweise größer ist, im Kopf zu behalten. Man müsste sonst viel zu viele Dinge im Kopf behalten und daher ein Tool in der Hand zu haben, das einem die Struktur auf einem High Level veranschaulicht, ist schonmal sehr praktisch. Plattform und Ressourcen für TypeScript kann ich auch ein paar empfehlen. Ich bin mir nicht mehr sicher, ob die noch absolut up-to-date sind, aber es gibt ein paar Deep Dive Books, die dieses Thema gut beleuchten. Jeder Blog, jedes Buch das sich mit einer wirklich strikt typisierten Sprache, wie zum Beispiel F-Sharp auseinandersetzt, hat mir persönlich sehr viel gebracht, um TypeScript besser zu verstehen
Und von der Perspektive der Unternehmen: Wie können Unternehmen denn sicherstellen, dass Ihre Entwickler:innen besser in TypeScript werden oder eben erstmals darauf umsteigen?
Wie Unternehmen das sicherstellen können bzw. den Weg erleichtern können für sich selbst, ist glaube ich eins der schwierigsten Themen, die man generell in der IT haben kann. Das geht nämlich sehr weit weg von der tatsächlichen klar definierten Linie, den so eine Technik vorgibt. Hin zu sehr viel humaneren Themen, die oft auch emotional getrieben sind. Meiner Meinung nach wird keine Ressource der Welt helfen, wenn ein:e Entwickler:in sich nicht dafür interessiert. Es braucht einfach diesen Anspruch an sich selbst, sich damit nicht zufrieden zu geben, dass etwas funktioniert. Sondern man muss auch verstehen, warum es funktioniert und darüber hinaus auch was passieren kann. Was muss ich machen, damit es auf einmal nicht mehr funktioniert? Wenn ich zum Beispiel ein TypeScript Problem vor mir habe, wo ich nicht verstehe, wie der Compiler oder wieso der Compiler gerade einen Fehler ausgibt, dann versuche ich das Ganze in eine Sandbox zu geben und fokussiert zu schauen, was das minimale Set an Dingen ist, die ich herstellen muss um diesen Fehler zu reproduzieren. Von daher: Was können Unternehmen tun, um das leichter zu machen? Jenen Entwickler:innen, die sich dafür interessieren, Zeit geben. Nicht einfach immer nur sagen: Nächstes Feature, nächstes Feature, nächstes Feature. Sondern einfach wirklich sagen: Okay, nehmt euch zehn Prozent der Zeit und spielt einfach herum. Das erzeugt keinen direkten Business Value, aber über kurz oder lang hat man dann Entwickler:innen, die in der Lage sind sehr komplexe Dinge sehr schnell umzusetzen.
Stay tuned
Immer auf dem Laufenden bleiben! Alle News & Updates:
Eine letzte Frage für dich. Was sind Best Practices, die du empfehlen kannst in dieser Übergangsphase von TypeScript zu JavaScript?
Es gibt in TypeScript diesen Ausweg den Compiler punktuell zu deaktivieren und zu sagen: „Ich weiß schon, was ich mache.“ Dieser Ausweg nennt sich <any> und das ist ein Type. Und ich würde sagen als ein Best Practice wäre <any> wirklich nur dann zu verwenden, wenn man weiß, es geht nicht anders. Man sollte immer versuchen möglichst präzise zu arbeiten. Man sollte sehr stark unterscheiden und sehr klar trennen zwischen Änderungen, die die Laufzeit betreffen und Änderungen, die die Typisierung betreffen. Wenn man jetzt also ein neues Feature umsetzt und dabei TypeScript reinmixen kann, fair enough. Wenn man hingegen ein Bug löst und dabei darauf kommt, dass die Typisierung an ganz vielen anderen Stellen, die gar nichts mit dem Bug zu tun haben, nicht stimmt, würde ich eher davon abraten. Man kommt dann ganz schnell vom Hundertsten ins Tausendste und dann ist die Zeit auch schon um.
Danke für die ganzen Antworten. Hoffentlich bis zum nächsten Mal in Berlin im Oktober!
