Die meisten Menschen lernen objektorientierte Programmierung als vier Begriffe, die sie für eine Prüfung auswendig lernen müssen: Kapselung, Abstraktion, Vererbung, Polymorphie. Ordentlich, zitierfähig und nahezu nutzlos, wenn es dabei bleibt – denn der Teil, der für Ihr Unternehmen wirklich zählt, wird in Lehrbüchern meist ausgelassen.
Fangen wir also ganz einfach an. Objektorientierte Programmierung (OOP) ist eine Methode, Software um Objekte herum zu strukturieren – in sich geschlossene Einheiten, die Daten mit den Funktionen bündeln, die diese verarbeiten. Es ist das Paradigma hinter den meisten Sprachen, auf denen moderne Unternehmen basieren, darunter Python, Java, C#, Swift und TypeScript. Einmal gelernt, lässt sich dieses Denkmuster fast überall anwenden.
Für eine technische Führungskraft gibt es jedoch eine bessere Definition als die rein akademische. OOP ist eine architektonische Entscheidung. Sie bestimmt im Stillen, wie schnell Ihr Produkt wachsen kann, wie zügig neue Mitarbeiter produktiv werden und wie teuer es Sie zu stehen kommt, wenn Sie später Ihre Meinung ändern. Dieser Leitfaden erklärt, was OOP ist und welche vier Säulen sie tragen. Danach geht er einen Schritt weiter als die meisten Artikel: Wir beleuchten die Kompromisse, die Ermessensentscheidungen sowie die Gebote und Verbote, die darüber entscheiden, ob Ihr Objektmodell zu einem wertvollen Aktivposten oder zu einer Belastung wird.
Hier ist die Zahl, die alles in ein neues Licht rückt. Die Entwicklung ist nur die Spitze des Eisbergs; die Masse unter der Wasseroberfläche ist die Wartung, und genau dort fließt das Geld hin. Die IEEE Computer Society und Gartner beziffern die Wartungskosten auf etwa 60 bis 80 Prozent der gesamten Lebenszykluskosten eines Systems, und Gartner schätzt, dass Unternehmen 55 bis 80 Prozent ihres IT-Budgets allein für den laufenden Betrieb aufwenden. Jede Entscheidung, die den Code wartungsfreundlicher macht, ist also keine Frage der Ordnung. Sie bewegt eine große Summe.
Gut umgesetzte OOP ist eine solche Entscheidung. Code, der in sinnvoll benannten Objekten organisiert ist, lässt sich leichter warten, was die Kosten für jedes zukünftige Feature senkt. Er skaliert mit Ihrem Team, da klare Grenzen es mehreren Entwicklern ermöglichen, parallel zu arbeiten, ohne sich gegenseitig in die Quere zu kommen. Er verhindert unnötige Nacharbeit, da ein wiederverwendbares Objekt nur einmal geschrieben und danach überall genutzt wird.
Zudem verkürzt er die Einarbeitungszeit, was wichtiger ist, als es klingt. Ehrlich gesagt kann ein neuer Entwickler zehn kleine, zweckmäßige Dateien weitaus schneller lesen, als ein tausendzeiliges Monster zu entwirren. Diese Zeit summiert sich: Stripes Developer Coefficient-Studie hat ergeben, dass Entwickler bereits etwa 42 Prozent ihrer Arbeitswoche, also rund 17 Stunden, mit Wartung und schlechtem Code verlieren. Struktur ist das, was verhindert, dass diese Zahl weiter steigt.
Ist das alles ein Problem, über das sich nur die Entwickler den Kopf zerbrechen sollten? Teilweise. Aber meistens ist es Ihres, denn es schlägt sich als technische Schulden nieder, und technische Schulden werden mit der Liefergeschwindigkeit bezahlt. Richtig eingesetzt, ist OOP ein Hebel für Wartbarkeit, Liefergeschwindigkeit und Gesamtbetriebskosten. Falsch eingesetzt, ist es ein schleichendes Leck. Alles Folgende dreht sich darum, was Sie davon bekommen.
Objektorientierte Programmierung ist ein Paradigma, das ein Programm um Objekte herum strukturiert, die jeweils sowohl ihre Daten als auch die Funktionen enthalten, die auf diesen Daten operieren. Zwei Bausteine erledigen dabei die Arbeit. Eine Klasse ist der Bauplan, der einen Typ definiert, und ein Objekt ist ein konkretes Exemplar, das nach diesem Bauplan erstellt wurde. Ein Bauplan, viele Häuser, jedes mit seiner eigenen Einrichtung.
In einer objektorientierten Sprache schreiben Sie Code, um Klassen und deren Objekte zu definieren, indem Sie vier Prinzipien folgen: Kapselung, Abstraktion, Vererbung und Polymorphie. Da diese Prinzipien sprachübergreifend gelten, lassen sich die erworbenen Fähigkeiten von einer Sprache auf die nächste übertragen. Diese Portabilität ist ein wesentlicher Grund dafür, warum OOP seit den 1990er Jahren eine dominierende Rolle spielt.
Die vier Säulen der objektorientierten Programmierung sind Kapselung, Abstraktion, Vererbung und Polymorphie. Da diese Definitionen allgemein bekannt sind, verknüpfen wir sie jeweils mit ihrem praktischen Nutzen. Denn für Entscheidungsträger ist das „Warum es sich lohnt“ immer wichtiger als das „Was es ist“.
Stellen Sie sich ein gut gekapseltes Objekt wie einen Warenautomaten vor. Sie drücken einen Knopf, eine Dose fällt heraus, und die Verkabelung hinter der Blende muss Sie nicht interessieren. Kapselung bedeutet, dass ein Objekt seinen internen Zustand verbirgt und nur das nach außen gibt, was es preisgeben möchte – wofür Felder als privat oder öffentlich markiert werden können. Wirtschaftlich gesehen ist genau diese verborgene Technik der entscheidende Punkt: Sie können das Innenleben der Maschine umbauen, ohne einen einzigen Knopf zu verändern. So bleiben Anpassungen lokal, anstatt sich auf das gesamte System auszuwirken.
Abstraktion ist das Lenkrad, nicht der Motor. Sie drehen am Lenkrad, das Auto fährt in die gewünschte Richtung, und Sie müssen keinen Gedanken an die Kolben verschwenden. Im Code verbirgt Abstraktion komplexe Details, sodass Sie mit einem Objekt über wenige benannte Methoden interagieren, anstatt sich mit dessen Innenleben zu befassen. Eine kleinere Schnittstelle bedeutet weniger Aufwand und eine schnellere Einarbeitung für neue Entwickler.
Vererbung ermöglicht es einer Unterklasse, Attribute und Verhaltensweisen von einer Elternklasse zu übernehmen, ähnlich wie in einer Familie Merkmale weitergegeben werden. Dies fördert die Wiederverwendung und erspart es Ihnen, Logik für nahezu identische Typen mehrfach zu schreiben. Der Vorteil ist Geschwindigkeit. Das Risiko, auf das wir noch eingehen werden, zeigt sich, wenn der Stammbaum zu groß wird.
Polymorphie erlaubt es Objekten, sich eine Schnittstelle zu teilen, während sich jedes auf seine eigene Weise verhält. So führt derselbe Methodenaufruf für jedes Objekt zum richtigen Ergebnis (durch Überschreiben oder Überladen, um den Fachbegriff zu nennen). Stellen Sie sich einen Lichtschalter vor, der mit verschiedenen Räumen verbunden ist und jeden davon korrekt beleuchtet. Dies ermöglicht es Ihnen, eine neue Variante hinzuzufügen, ohne den Code umschreiben zu müssen, der bereits die alten Varianten nutzt.
Sie finden diese Definitionen sorgfältig ausgearbeitet in den Referenzmaterialien der meisten Sprachen, einschließlich der Python-Klassendokumentation, dem Oracle Java-Tutorial zu objektorientierten Konzepten und Microsofts C#-Leitfaden zur objektorientierten Programmierung.
Reichen die vier Säulen aus? Nicht wirklich, denn sie erklären zwar, was objektorientierte Programmierung ist, aber nicht, wie man sie bei wachsender Komplexität wartbar hält. Zwei bewährte Ansätze aus der Praxis schließen diese Lücke.
Die SOLID-Prinzipien, von Robert C. Martin definiert, sind der nächste logische Schritt: Single Responsibility, Open/Closed, Liskov-Substitution, Interface Segregation und Dependency Inversion. Einfach ausgedrückt sind die SOLID-Prinzipien Leitplanken, die Objekte klein, fokussiert und lose gekoppelt halten, damit eine Änderung an einer Stelle nicht zehn weitere nach sich zieht. Wenn die vier Säulen die Grammatik der objektorientierten Programmierung sind, dann ist SOLID der dazugehörige Stil-Leitfaden.
Komposition vor Vererbung, populär gemacht durch die „Gang of Four“ in Design Patterns, ist das Gegengewicht zu den Gefahren der Vererbungshierarchien. Was aus einem Block gemeißelt wurde, sieht anfangs elegant aus, bricht aber unter Druck, da sich Änderungen an der Basisklasse auf alle Unterklassen auswirken. Komposition hingegen baut Verhalten aus kleinen, flexiblen Bausteinen zusammen, die sich neu anordnen lassen, ohne das Ganze zu zerstören. Als Faustregel gilt: Nutzen Sie Vererbung, wenn Typen tatsächlich eine „ist-ein“-Beziehung haben, und Komposition, wenn sie lediglich Verhalten teilen müssen. Behalten Sie diesen Gedanken im Hinterkopf, denn er präzisiert die Empfehlungen zur Unterklassenbildung weiter unten.
Ist OOP für jede Aufgabe das richtige Werkzeug? Nein, natürlich nicht, und es reflexartig einzusetzen, ist ein Fehler für sich. Die Wahl eines Paradigmas ist eine Designentscheidung, die sich an der Struktur des Problems orientieren sollte und neben den umfassenderen Entscheidungen zum Tech-Stack steht, die jedes Projekt treffen muss. Vergleichen wir die drei Ansätze.
Greifen Sie zu OOP, wenn Ihr System reale Dinge mit klarem Zustand und Verhalten abbildet, wenn viele Komponenten eine Struktur teilen, die durch Vererbung und Polymorphie abgebildet werden kann, und wenn ein großes Team stabile Modulgrenzen benötigt, um parallel arbeiten zu können. Geschäftsanwendungen, langlebige Plattformen und domänenreiche Produkte sind das ideale Einsatzgebiet. Deshalb dominiert es die Unternehmenssoftware.
Nutzen Sie prozedurale Programmierung für lineare, skriptartige Aufgaben: eine Abfolge von Schritten mit kaum gemeinsamem Zustand, wie etwa ein kleines Automatisierungstool oder eine schnelle Datentransformation. Packen Sie das in eine Klassenhierarchie, und Sie fügen nur unnötigen Aufwand hinzu, keinen Mehrwert.
Setzen Sie auf funktionale Programmierung, wenn Vorhersehbarkeit und Nebenläufigkeit entscheidend sind. Durch die Bevorzugung unveränderlicher Daten und reiner Funktionen – also Funktionen, die keine externen Zustände verändern – wird eine ganze Klasse von Fehlern eliminiert, die durch gemeinsam genutzte, veränderbare Zustände entstehen. Das ist Gold wert bei Datenpipelines und hochgradig nebenläufigen Systemen. Meistens sind moderne Codebasen glückliche Hybride: Objekte zur Modellierung der Domäne und funktionale Ansätze für die Datenverarbeitung.
In großen Systemen verstärken sich die Vor- und Nachteile von OOP. Unternehmenssoftware wird über Jahre hinweg von wechselnden Teams gewartet, ist mit einem Dutzend externer Dienste verknüpft und unterliegt ständigem kommerziellem Änderungsdruck. Die objektorientierte Struktur bietet hier die nötigen Schnittstellen: abgegrenzte Teile, die man verstehen, testen und einzeln austauschen kann.
Genau hier richtet schlampige OOP jedoch den größten Schaden an. Lange Vererbungshierarchien werden starr. Objekte, die ihre Interna nach außen tragen, verschweißen unbeteiligte Module miteinander. Beides verfestigt sich zu technischer Schuld, die die Bereitstellung verzögert und jedes einzelne Release belastet.
Dieser letzte Punkt ist für die Geschäftsführung von strategischer Bedeutung. Ein fehlerhaftes Objektmodell ist keine einmalige Abschreibung. Es ist eine dauerhafte Steuer auf jede zukünftige Änderung, die mit der Codebasis wächst. Die Prüfpunkte im nächsten Abschnitt zeigen, wie Ihr Team diese Kosten niedrig hält.
Die folgenden vier Richtlinien sind Fragen, die unsere Ingenieure bei der Arbeit an echten Kundenprojekten – von langlebigen Plattformen bis hin zu iOS-Anwendungen – an ein Objektmodell stellen. Einzeln betrachtet wirken sie wie gesunder Menschenverstand. Zusammen als Linse angewendet, sorgen sie dafür, dass ein Modell auch bei wachsender Größe wartbar bleibt.
Wenn man ein großes Projekt zum ersten Mal öffnet und die Flut an Dateien sieht, ist die instinktive Reaktion oft, dass das System unüberschaubar ist. Meistens ist das Gegenteil der Fall. Zehn kleine Dateien, deren Namen ihre Funktion verraten, sind einem einzigen Codeblock, der alles erledigt, haushoch überlegen. Wenn Sie sich also fragen, ob etwas ein eigenes Objekt verdient, lautet die Antwort fast immer: Ja.
Die eigentliche Arbeit liegt nicht in der Anzahl der Dateien, sondern in ihrer Organisation. Gruppieren Sie Dateien in einer klaren Ordnerstruktur, orientiert an einem bewährten Muster wie MVC (Model-View-Controller, das Daten, Anzeige und Steuerungslogik trennt), damit sich jeder, der den Code übernimmt, sofort zurechtfindet. Das ist das Single-Responsibility-Prinzip aus SOLID, angewandt auf die gesamte Codebasis.
Achten Sie auf Klassen, die zu einem Schweizer Taschenmesser mutiert sind: ein Typ, der eine lange Liste von Eigenschaften und Enum-Flags mit sich herumträgt, um sein Verhalten zu steuern. Wenn eine Klasse versucht, alles gleichzeitig zu sein, wird jede Änderung zum Glücksspiel, bei dem man nie weiß, was sonst noch in Mitleidenschaft gezogen wird. Es ist besser, diese Verhaltensweisen zu trennen und die Basis so generisch zu halten, dass sie erweiterbar bleibt.
Dafür gibt es zwei Werkzeuge: Vererbung (Subclassing), wenn eine echte „Ist-ein“-Beziehung besteht, und Komposition, wenn Objekte sich lediglich Verhalten teilen sollen. Denken Sie an den Unterschied zwischen Marmor und Ziegelsteinen: Wer instinktiv zur Unterklasse greift, erzeugt starre Hierarchien. Die Devise lautet also: „Verhaltensweisen richtig trennen“, nicht „immer vererben“.
Eine der stillen Stärken der objektorientierten Programmierung ist, dass eine gut entworfene Klasse über Projekte hinweg wiederverwendet werden kann – das spart echte Entwicklungszeit. Auf Wiederverwendbarkeit zu setzen bedeutet, den Kern generisch zu halten und projektspezifische Details an die Ränder zu verlagern. Behalten Sie eine generische Klasse für übergreifende Aufgaben wie API-Handling oder Zahlungen bei und nutzen Sie dann Vererbung oder Komposition für die spezifischen Daten des jeweiligen Projekts. Einmal geschrieben. Einmal getestet. Jahrelang genutzt.
.webp)
Hier ist eine verlockende Abkürzung: Eine Methode benötigt ein Dutzend Eigenschaften, also packt man sie in ein Dictionary oder ein Array, anstatt jede einzeln zu übergeben. Das wirkt aufgeräumt, ist es aber selten. Wochen später muss ein Kollege diese Sammlung in der exakt richtigen Reihenfolge zusammenstellen und verliert dann einen halben Nachmittag damit, herauszufinden, warum ein Wert leer ankommt.
Übergeben Sie stattdessen das gesamte Objekt, zu dem die Eigenschaften gehören, auch wenn es heute mehr enthält, als die Methode benötigt. Das ist stabiler und besser skalierbar, da der vollständige Kontext später ohnehin meist gebraucht wird. So arbeitet die Kapselung für Sie und nicht gegen Sie.
Wie dieser Ansatz in der Praxis funktioniert, zeigen zwei Projekte, die wir für GoodBarberumgesetzt haben – eine globale No-Code-Plattform, mit der Nutzer native mobile Apps und Progressive Web Apps erstellen können, ohne eine einzige Zeile Code zu schreiben. Das Produkt basiert auf Vorlagen, die über drei Umgebungen hinweg – iOS, Android und Web – konsistent funktionieren müssen, verteilt auf Objective-C, Swift, Java, Kotlin und JavaScript. Genau in einem solchen Umfeld zahlt sich ein sauberes Objektmodell aus, während ein unstrukturiertes bei jedem Release für unnötigen Aufwand sorgt.
Das erste Projekt konzentrierte sich auf die Disziplin von Check 1 und Check 3, noch bevor die erste Zeile neuer Code geschrieben wurde. Anstatt direkt mit der Neuentwicklung zu beginnen, haben wir die bestehende Vorlagenlogik dokumentiert (alle 195 Vorlagen, jeweils in Pseudocode, der die Logik von der Datenverarbeitung bis zum Rendering abbildete) und zwischen plattformübergreifenden Gemeinsamkeiten und plattformspezifischen Unterschieden differenziert. Diese Unterscheidung ist Check 3 in der Praxis: Die gemeinsamen Muster bilden den generischen Kern, die plattformspezifischen Anteile die Ränder. Das Ergebnis war kein neues Feature, sondern architektonische Klarheit und das Fundament für eine neue Abstraktionsschicht zwischen den Legacy-Vorlagen und zukünftigen Entwicklungen.
Das zweite Projekt baute genau darauf auf. Niemand musste bei null anfangen. Auf Basis der dokumentierten Grenzen haben wir den V7 Composer neu implementiert: ein neues Widget-Framework auf Django-Basis, bei dem etwa 150 Widgets neu geschrieben und alle 195 Vorlagen in die neue Architektur überführt wurden. Da die Trennung zwischen gemeinsam genutzten und spezifischen Elementen bereits definiert war, folgte der Umbau einem erprobten Plan statt einer Vermutung. GoodBarber berichtet, dass der Composer dadurch skalierbarer, wartungsfreundlicher und performanter geworden ist und die technische Schuld auf der gesamten Plattform reduziert wurde.
Das ist das gesamte Argument im Kleinen. Die Kartierung von gestern wurde zum Fundament von heute: Der generische Kern nahm das Gemeinsame auf, die Ränder das Spezifische, und das zweite Team konnte schneller arbeiten, weil das erste die Schnittstellen bereits definiert hatte. Genau deshalb reduziert eine solche wiederverwendbare Struktur die 42-prozentige Wartungssteuer, die Stripe beziffert hat, und deshalb ist die disziplinierte Entwicklung dahinter auch das, was McKinseys Developer Velocity-Studie mit Unternehmen im obersten Quartil in Verbindung bringt, die ihren Umsatz vier- bis fünfmal schneller steigern als ihre Wettbewerber und eine um 60 Prozent höhere Rendite für ihre Aktionäre erzielen.
Objektorientierte Programmierung strukturiert Software um Objekte und deren Interaktion miteinander. Technisch basiert sie auf vier Säulen: Kapselung, Abstraktion, Vererbung und Polymorphie, die in der Praxis durch SOLID-Prinzipien ergänzt und durch das Prinzip „Komposition vor Vererbung“ in geordnete Bahnen gelenkt werden. Praktisch läuft es auf vier Prüfpunkte hinaus: Aufteilung nach Verantwortlichkeiten, korrekte Trennung von Verhalten, ein generischer Kern und die Übergabe vollständiger Objekte.
Wirtschaftlich betrachtet lässt sich das Ganze auf einen Punkt bringen: OOP ist eine architektonische Entscheidung mit langfristigen Auswirkungen. Da die Wartung den Großteil der Lebenszykluskosten ausmacht, sorgt ein sauberes Objektmodell dafür, dass diese Kosten, die Einarbeitungszeit und der Aufwand für spätere Änderungen kontrollierbar bleiben, während das Produkt und das Team wachsen. Das ist keine Frage des Geschmacks. Für CEOs, CTOs oder COOs bedeutet das: wartbare Systeme, skalierbare Teams, eine schnellere Wertschöpfung und weniger Risiken in der Zukunft.
OOP steht für objektorientierte Programmierung. Dabei wird Software in Objekten strukturiert, die Daten mit den dazugehörigen Funktionen bündeln. Die Basis bilden Klassen als Baupläne und Objekte als konkrete Instanzen dieser Baupläne. Ziel ist ein Code, der einfacher zu warten, zu erweitern und wiederzuverwenden ist.
Die vier Säulen der objektorientierten Programmierung sind Kapselung, Abstraktion, Vererbung und Polymorphie. Die Kapselung schützt den internen Zustand eines Objekts, die Abstraktion verbirgt Komplexität hinter einfachen Schnittstellen, die Vererbung ermöglicht die gemeinsame Nutzung von Attributen und Verhalten, und die Polymorphie erlaubt es einer Methode, sich je nach Objekt unterschiedlich zu verhalten. Zusammen machen sie objektorientierten Code modular und wiederverwendbar.
Ja. Python ist eine objektorientierte Sprache, in der fast alles ein Objekt ist. Sie unterstützt Klassen, Vererbung und Polymorphie direkt, wie in der offiziellen Python-Klassendokumentationbeschrieben. Da Python eine Multi-Paradigmen-Sprache ist, lassen sich neben OOP problemlos auch prozedurale und funktionale Stile verwenden.
Eine Klasse ist ein Bauplan, der die Attribute und das Verhalten eines Typs festlegt, während ein Objekt eine konkrete Instanz ist, die auf Basis dieser Klasse erstellt wurde. Eine Klasse kann viele Objekte erzeugen, von denen jedes seinen eigenen Zustand besitzt. Einfach ausgedrückt: Die Klasse ist die Vorlage und das Objekt ist das daraus erstellte Element.
SOLID ist eine Sammlung von fünf Designprinzipien – Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation und Dependency Inversion –, die die vier Säulen um Aspekte für wartbares Design ergänzen. Während die Säulen definieren, was OOP ist, gibt SOLID vor, wie Objekte klein, fokussiert und lose gekoppelt bleiben. Es ist der Standard-Leitfaden für Entwickler, um objektorientierten Code auch bei wachsenden Anforderungen flexibel zu halten.
Für kleine, lineare, skriptartige Aufgaben mit kaum gemeinsamem Zustand bietet OOP kaum Vorteile; hier ist ein prozeduraler Ansatz klarer und schneller. Auch für Aufgaben, bei denen Unveränderlichkeit und Nebenläufigkeit im Vordergrund stehen – etwa bei Datenpipelines –, ist OOP oft nicht die beste Wahl, da funktionale Programmierung hier häufig Fehler reduziert. Wer solchen Problemen eine Klassenhierarchie aufzwingt, erkauft sich Komplexität ohne echten Mehrwert.
Die meisten gängigen Programmiersprachen unterstützen OOP, darunter Java, C#, Python, TypeScript, Ruby und Swift. Viele davon sind Multiparadigmen-Sprachen, das heißt, sie unterstützen objektorientierte, prozedurale und funktionale Stile innerhalb einer Codebasis. Sprachdokumentationen wie das Oracle Java-Tutorial und der C#-Leitfaden von Microsoft erläutern, wie die vier Säulen jeweils umgesetzt werden.
Objektorientiertes Design schafft stabile Komponentengrenzen, die es mehreren Entwicklern ermöglichen, parallel zu arbeiten. Dies unterstützt größere Teams und eine schnellere Bereitstellung, während wiederverwendbare Objekte den Arbeitsaufwand über verschiedene Projekte hinweg reduzieren. Da die Wartung 60 bis 80 Prozent der Lebenszykluskosten ausmacht, hat ein sauberes Objektmodell einen enormen Einfluss auf die Gesamtbetriebskosten. Das sind die wirtschaftlichen Gründe, warum OOP bei langlebiger Unternehmenssoftware nach wie vor dominiert.
Solche Entscheidungen wirken sich über die gesamte Lebensdauer eines Produkts aus, und die Kosten für Fehlentscheidungen steigen mit der Codebasis. Wenn Ihr Team überlegt, wie ein neuer Build strukturiert, ein veraltetes System entwirrt oder eine Plattform skaliert werden soll, ohne dass die Wartungskosten explodieren, helfen unsere Ingenieure Ihnen dabei, die richtige Entscheidung mit Blick auf den wirtschaftlichen Erfolg zu treffen. Werfen Sie einen Blick auf unsere technischen und UX-Audits sowie KI-gestützte Individualentwicklung oder kontaktieren Sie das Team von Imaginary Cloud und verraten Sie uns, wo Sie feststecken.
Ein erfahrener iOS-Entwickler, der Teil eines agilen iOS-Teams ist und Einzelpersonen dabei unterstützt, ihre Träume und Ziele zu verwirklichen.
Marketing-Praktikant mit besonderem Interesse an Technologie und Forschung. In meiner Freizeit spiele ich Volleyball und verwöhne meinen Hund so gut es geht.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
