Kolumne: Olis bunte Welt der IT

Der volle Stapel – sind Sie Experte fürs Detail oder Entwickler von A–Z?
Keine Kommentare

Software von A bis Z, das ist meine Präferenz. Schwarz-weiß mag ich nicht, das wissen Sie! Trotzdem fasse ich in meiner Kolumne diesen Monat zusammen, welche Entscheidungen ich in vielen Bereichen am liebsten treffe.

Früher waren Entwickler einfach Entwickler. Ich erinnere mich an Zeiten, als man als Entwickler durchaus den Eindruck haben konnte, man wüsste über alle wichtigen Bereiche der Programmierung von Computersoftware Bescheid: Unix, DOS, Windows, OS/2, Novell, Terminals und grafische Oberflächen, vielleicht ein bisschen COBOL fürs Mainframe, etwas Assembler für Optimierungen und Treiberprogrammierung. Natürlich war auch damals jedem klar, dass man nicht wirklich überall ein Experte sein konnte, aber das wollte man auch gar nicht – das umfassende Verständnis war da, oder so schien es jedenfalls.

Diese Zeiten sind vorbei, ganz unbestreitbar, wenn auch nur aufgrund der komplexen Softwarewelt, in der wir heute leben. Es würde mich wundern, heute jemanden zu treffen, der von sich sagen würde, er fände sich in „gefühlt“ allen existierenden Bereichen der Softwareentwicklung gleichermaßen heimisch. Das scheint undenkbar, weil es viel mehr solche Bereiche gibt als vor ein paar Jahrzehnten, und weil jeder dieser Bereiche für sich an Komplexität gewonnen hat. Trotzdem ist diese Sicht der Dinge auch mein eigener Hintergrund, und so war ich vor ein paar Jahren zunächst verwundert, als ich zum ersten Mal den Begriff „Full-Stack-Developer“ hörte. Full-Stack, der volle Stapel?

Sachexperten braucht die Welt

Wie sich nach etwas Zeit mit Google herausstellte, sehen sich anscheinend viele Entwickler heute nur noch als Experten für einen Teilbereich, wie etwa UI oder Backend. Natürlich sind das mitunter große Bereiche, die sich über verschiedene Plattformen erstrecken und den Einsatz unterschiedlicher Programmiersprachen und diverser Technologien erfordern. Tatsächlich sind, so meine Erfahrung, viele UI-Developer (wie auch Backend-Developer oder Database-Developer) allerdings noch stärker spezialisiert als die Bezeichnung der Tätigkeit das vermuten lässt und sollten sich eigentlich gleich als Angular-Developer, XAML-Developer oder Web-API-Developer bezeichnen.

Nun will ich solche Spezialisierungen nicht in einem schlechten Licht darstellen – bitte fühlen Sie sich als Fachmann für einen Technologiebereich nicht angegriffen! Persönlich geht es mir allerdings nicht weit genug, mich etwa als Backend-Entwickler zu sehen. Meine Begeisterung für die Computerprogrammierung bezieht sich auf den Gesamtvorgang: Eine Software zu bauen, die rundherum tut, was ein Kunde von ihr will, wo auch immer der Code nachher läuft, bis hin zum startfähigen Installer, zum Paket im App-Store oder zum Cloud-Deployment. Natürlich kann man, wie gesagt, nicht überall gleichzeitig Fachmann sein, aber dauerhaft in nur einem Bereich zu arbeiten, würde mich sehr langweilen. Anscheinend macht mich das zum Full-Stack-Developer, wenn ich auch hinzufügen möchte, dass mein Full-Stack sich mit großer Regelmäßigkeit ändert.

Bevor ich beschreibe, mit welchen Technologien ich derzeit bevorzugt arbeite, möchte ich noch einen Bogen zu Kolumnen der Vergangenheit schlagen. Oft habe ich festgestellt, dass Entwickler oder Berater ihren Full-Stack gerne als strategische Plattform betrachten. Damit einher gehen oft gewisse Anstrengungen, das nächste Projekt irgendwie passend zu machen, damit die strategische Wahl nicht angepasst werden muss. Natürlich ist das in gewissem Maße nicht falsch, schließlich braucht es Zeit und Arbeit, sich zum Fachmann für einen Full-Stack zu entwickeln.

Kostenlos: Docker mit .NET auf einen Blick

Container unter Linux und Windows nutzen? Unser Cheatsheet zeigt Ihnen wie Sie: Container starten, analysieren und Docker.DotNet (in C#) verwenden. Jetzt kostenlos herunterladen!

Download for free

Es ist aber schwierig, die richtige Grenze zu finden, besonders im Kundengespräch, und nicht versehentlich Empfehlungen auszusprechen, die objektiv nicht ganz so richtig sind, wie man es selbst gern hätte! Meine eigenen Überlegungen zur Wahl von Technologien möchte ich also nicht in diesem Sinne als strategisch verstanden sehen – vielmehr handelt es sich um eine Momentaufnahme unter bestimmten Umständen zu einem bestimmten Zeitpunkt.

Strategisch ist anders

Ich fange einmal „unten“ an, also im Backend. Da gibt es eine Reihe von Entscheidungen zu treffen, wenn ein neues Projekt gestartet werden soll. Wie Sie wissen, wenn Sie meiner Kolumne schon länger folgen, bin ich ein Anhänger der Microservices-Idee. Ich möchte gern viele kleine eigenständige Dienste schreiben, um Modularisierung auf die Spitze zu treiben und um mir möglichst viele Freiheiten bei der Wahl technologischer Umgebungen zur spezifischen Problemlösung zu erhalten. Viele andere Entscheidungen sind davon abhängig, welchen Weg ich bei der technischen Struktur meiner Dienste gehe.

Im Wesentlichen kann ich entweder Dienste in eigenen Anwendungen auf Serversystemen oder in VMs laufen lassen (womöglich paketiert mit Docker) oder auf die „serverlosen“ Umgebungen setzen, die von Cloud-Plattformen angeboten werden. Ich selbst finde „serverless“ gut und habe in letzter Zeit einige Erfahrungen mit der Amazon-Implementierung dieser Idee gesammelt. Es ist toll, über Infrastruktur gar nicht nachdenken zu müssen – also noch weniger als beim Einsatz von Docker – und sich einzig auf den Code zu konzentrieren. Billiger sollte das in vielen Fällen auch sein, da der dauerhafte Betrieb virtueller Serversysteme, ob man sie nutzt oder nicht, nicht notwendig ist. Nachteil von Serverless ist allerdings, dass man sich an eine bestimmte Cloud-Umgebung bindet und vorzugsweise auch deren Dienste nutzen sollte, damit das Konzept funktioniert. Dies nimmt etwas von der Freiheit weg, die ich mir von Microservices erhoffe.

Es gibt auch noch ein paar Mängel im Umgang mit den Serverless-Umgebungen dieser Welt, was etwa das Testen von Funktionen angeht, die letztlich in der Cloud im Umfeld diverser anderer Dienste laufen sollen. Also, für mich gilt: Serverless, ja, gerne, sofern ich mit dem Dienstangebot einer Cloud-Plattform zufrieden bin und der Plattform soweit vertraue, dass ein Umstieg auf eine andere Cloud-Plattform eher unwahrscheinlich erscheint.

Wenn nicht Serverless, dann Docker – das wäre meine nächste Wahl. Mit Docker lassen sich Dienstumgebungen in einzelnen Images abbilden und beliebig zu komplexen Architekturen zusammensetzen, während gleichzeitig die Nutzung von lokalen oder Cloud-Resourcen optimiert wird. Der Aufwand, diese Images auf eigenen Servern, sogar auf Entwicklungssystemen, und letztlich eventuell wieder in der Cloud einzusetzen, ist minimal, so dass dieser Ansatz große Flexibilität bietet. Standardimages, die für Open-Source-Serverprodukte und für komplette Ausführungsumgebungen verfügbar sind, sparen viel Zeit. Trotzdem muss natürlich die Arbeit getan werden, die Gesamtumgebung zu planen, zu konfigurieren und zu pflegen.

Datenablage letztendlich konsistent

Die meisten Anwendungssysteme brauchen eine Datenbank oder gleich mehrere. Ich entscheide mich gern für dokumentenbasierte NoSQL-Optionen wie MongoDB oder DynamoDB in der Amazon-Cloud, da ich den Umgang damit besonders angenehm finde und ich der Auffassung bin, dass ein relationales Modell für die meisten Anwendungen wenig Vorteile bietet. Natürlich gilt es, die Anforderungen einzelner Anwendungen sorgfältig auszuwerten. NoSQL-Datenbanken sind bei der Performance in verteilten Umgebungen unschlagbar, erfordern aber eine grundlegend andere Denkweise zur Abbildung transaktionaler Vorgänge und generell ein gutes Verständnis der „eventual consistency“. („Eventual“ heißt übrigens „letztendlich“, nicht „eventuell“ oder „vielleicht“ – im Deutschen ein häufiges Missverständnis!)

Dienste müssen irgendwie miteinander reden. Auf der technischen Seite setze ich gern RabbitMQ oder die entsprechenden Lösungen einer Cloud-Umgebung ein. Im Serverless-Umfeld gibt es Möglichkeiten, über die APIs der Cloud direkt den Aufruf einer Funktion anzufordern – so ist der direkte Umgang mit der Infrastruktur hier nicht erforderlich. Außerhalb von Serverless gilt es natürlich auch, einzelne Dienste mit externen Schnittstellen zu versehen, wozu eventuell Frameworks eingesetzt werden können. Frameworks sparen Zeit, binden aber auch. Für JavaScript habe ich schon erfolgreich Seneca eingesetzt, und auch Aktorensysteme wie Akka.NET fallen in diese Kategorie (obwohl letztere bei einer besonders starken Bindung im Gegenzug auch deutlich weitreichendere Funktionalitäten bieten). Die Bereitstellung von Diensten, die nach dem REST-Schema angesprochen werden können und JSON oder XML-Daten übertragen, ist heute mit oder ohne Framework auf den meisten Plattformen einfach, sodass dieser Weg immer als gemeinsamer Nenner gesehen werden kann.

Meine persönliche Präferenz für die Cloud von Amazon (AWS) hat keinen besonderen technischen Grund, sondern basiert lediglich auf der größeren Erfahrung, die ich im Laufe von Jahren in diesem Umfeld gesammelt habe. Für viele Cloud-Konzepte sind Cloud-Dienste auf dem Weg zur „Commodity“, also einer Ware, von der man unabhängig von der Bezugsquelle ähnliche Qualität erwartet. Sicherlich gilt es auch hier, für einzelne Projekte „besondere“ Anforderungen zu identifizieren, Cloud-Anbieter entsprechend zu bewerten und im Vorfeld Kostenanalysen durchzuführen. Generell ist die Cloud für mich in vielen Fällen der richtige Weg, denn sie spart Zeit und Geld im Vergleich mit dem Inhousebetrieb von Servern oder der Nutzung von Hostinganbietern aus der Zeit vor der Cloud.

JavaScript ist für alle da

Ganz allgemein und auch im Backend entwickle ich gern in JavaScript. Die Sprache ist die verbreitetste der Welt, fast jede Frage dazu ist auf Stackoverflow schon beantwortet worden, die Auswahl an oftmals frei verfügbaren Paketen und Libraries ist gewaltig, und mit der schnellen Entwicklung der ECMAScript-Standards wird die Verwendung immer angenehmer. Ich weiß dynamische Typisierung zu schätzen und glaube daran, dass sie mir in der heutigen offenen Welt Zeit und Arbeit erspart. Ich schreibe lieber Unittests als Typdefinitionen und kann TypeScript nicht viel abgewinnen. Wenn Typprüfung wichtig erscheint, etwa zu Zwecken von Dokumentation und Kommunikation in großen Teams, empfehle ich eher den Einsatz von Flow als den TypeScript-Compiler, da Flow meiner Ansicht nach graduell besser einsetzbar ist.

Grundsätzlich schreibe ich gern in einem funktionalen Stil, was mit JavaScript und Libraries wie seamless-immutable, Ramda oder lodash/fp recht einfach geht. Ich mag auch ClojureScript, eine Lisp-ähnliche funktionale Sprache, die nach JavaScript kompiliert. Ich bin allerdings von der Komplexität des Java-basierten Toolings etwas abgeschreckt. Ich beobachte mit Interesse die Entwicklung von Lumo, das Java für ClojureScript unnötig macht – möglicherweise wird dies in der Zukunft für mich zu einer stärkeren Alternative.

Nun lasse ich das Backend hinter mir. Zum Frontend muss ich als Erstes sagen, dass ich nicht mehr an „native“ Lösungen glaube. Bestimmt wird es die native Clientanwendung für Windows, Mac und für Mobilgeräte noch eine lange Zeit geben. Schon in der Vergangenheit lagen die Vorteile einer solchen Wahl allerdings fast ausschließlich bei der Performance, und während es in dem Bereich sicherlich fast immer gewisse Vorteile für native Anwendungen geben wird, ist das schon heute für die meisten Anwendungen irrelevant. Dem gegenüber stehen die Vielfalt von UI-Lösungen für HTML/CSS und die Leichtigkeit, diese auf den unterschiedlichsten Plattformen einzusetzen – das ist für mich ein unglaublich wichtiger Vorteil angesichts der Geschwindigkeit, mit der sich Präferenzen für System- und Mobilplattformen bei Kunden heutzutage verändern.

Reagiert und reduziert

Die Kombination von React und Redux ist für mich erste Wahl im Bereich von Frameworks für Frontend-Anwendungen. Der gern angestellte Vergleich von React mit Angular hinkt meiner Meinung nach etwas, da Angular ein Framework mit wesentlich mehr integrierter Funktionalität ist. Allerdings ergibt sich gerade aus dieser Funktionalität für mich ein Gesamtpaket von großer Komplexität, das ich auf englisch als sehr „opinionated“ bezeichnen würde. Damit ist gemeint, dass der Einsatz von Angular damit einhergeht, viele Probleme genau auf die von Angular vorgesehene Weise zu lösen – das mag ich generell nicht.

Verstehen Sie mich aber nicht falsch, Angular ist eine sehr leistungsfähige Plattform! Ich bevorzuge persönlich allerdings den Ansatz von React und des Flux-Patterns, das in Redux umgesetzt ist. Damit lassen sich sehr einfach pflegbare und höchst leistungsfähige Anwendungen bauen, basierend auf funktionalen Konzepten, die ich zu schätzen weiß. Zudem bietet es einen sehr direkten Weg zum Backend und Patterns wie Event Sourcing, das eine große Ähnlichkeit zu Flux hat. Übrigens kann Flux auch mit Angular eingesetzt werden, googeln Sie das mal …

Fazit

Das ist also mein Full-Stack der Wahl für Oktober 2017: Funktionales JavaScript, Microservices, Serverless oder mit Docker, NoSQL und HTML auf dem Frontend mit React und Redux. Natürlich erfordern die meisten Anwendungen weitere Komponenten, die ich hier ausgelassen habe. Generell ist für mich immer am wichtigsten, dass Anwendungen individuell betrachtet werden müssen. Meine allgemeine Leitlinie ist, dass ich nie eine technologische Entscheidung treffe, ohne wenigstens eine Alternative zu meiner bevurzugten Wahl betrachtet zu haben. Schließlich kann man nicht behaupten, sich entschieden zu haben, wenn man nur eine Möglichkeit in Betracht gezogen hat!

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -