Als Techniker bin ich recht schnell von allen möglichen Dingen zu begeistern, die irgendwie blinken und piepsen, ganz gleich, wie unnütz diese auch sein mögen. Elektronikspielereien ziehen mich an, wie das Licht Motten. Seit einer Weile ist eine neue Generation Spielwaren für die breite Masse verfügbar: Anwendungen der Künstlichen Intelligenz, genauer gesagt künstliche neuronale Netze. Die frei verfügbaren Anwendungen leisten bereits Beachtliches und es ist erst der Anfang dessen, was noch möglich sein wird. Vielen Menschen ist die Tragweite KI-basierter Anwendungen noch gar nicht bewusst geworden. Das ist auch nicht verwunderlich, denn das, was gerade im Sektor KI geschieht, wird unser Leben nachhaltig verändern. Wir können also zu Recht sagen, dass wir in einer Zeit leben, die gerade Geschichte schreibt. Ob die kommenden Veränderungen etwas Gutes werden, oder sie sich als eine Dystopie entpuppen, wird an uns liegen.
java Aktuell 2024.01
Als ich im Studium vor sehr vielen Jahren als Vertiefungsrichtung Künstliche Intelligenz gewählt hatte, war die Zeit noch von sogenannten „Expertensystemen“ geprägt. Diese regelbasierten Systeme waren für ihre Domäne hochspezialisiert und wurden für entsprechende Experten ausgelegt. Das System sollte die Experten bei der Entscheidungsfindung unterstützen. Mittlerweile haben wir auch die notwendige Hardware, um viel allgemeinere Systeme zu schaffen. Wenn wir Anwendungen wie ChatGPT betrachten, basieren diese auf neuronalen Netzen, was eine sehr hohe Flexibilität in der Verwendung erlaubt. Der Nachteil ist allerdings, dass wir als Entwickler kaum noch nachvollziehen können, welche Ausgabe ein neuronales Netz für eine beliebige Eingabe erzeugt. Ein Umstand, der die meisten Programmierer, die ich kenne, eher eine ablehnende Haltung einnehmen lässt, da diese so nicht mehr Herr über den Algorithmus sind, sondern nur noch nach dem Prinzip Versuch und Irrtum agieren können.
Dennoch ist die Leistungsfähigkeit neuronaler Netze verblüffend. Vorbei scheint nun die Zeit, in der man sich über unbeholfene, automatisierte, Software-gestützte Übersetzungen lustig machen kann. Aus eigener Erfahrung weiß ich noch, wie mühselig es war, den Google Translator aus dem Deutschen einen vernünftigen Satz ins Spanische übersetzen zu lassen. Damit das Ergebnis brauchbar war, konnte man sich über die Option Englisch – Spanisch behelfen. Alternativ, wenn man nur ein rudimentäres Englisch für den Urlaubsgebrauch spricht, konnte man noch sehr einfache deutsche Sätze formulieren, die dann wenigsten inhaltlich korrekt waren. Die Zeitersparnis für automatisiert übersetzte Texte ist erheblich, obwohl man diese Korrektur lesen muss und gegebenenfalls ein paar Formulierungen angepasst werden müssen.
So sehr ich es schätze, mit solchen starken Werkzeugen arbeiten zu können, müssen wir uns aber auch im Klaren sein, dass es auch eine Schattenseite gibt. Denn je mehr wir unserer täglichen Aufgaben über KI-gestützte Tools erledigen, umso mehr verlieren wir die Fähigkeit, diese Aufgaben künftig weiterhin manuell bearbeiten zu können. Für Programmierer bedeutet dies, dass sie im Laufe der Zeit über KI-gestützte IDEs ihre Ausdrucksfähigkeit im Quellcode verlieren. Das ist natürlich kein Prozess, der über Nacht stattfindet, sondern sich schleichend einstellt. Aber sobald diese Abhängigkeit einmal geschaffen ist, stellt sich die Frage, ob die verfügbaren, liebgewonnenen Werkzeuge weiterhin kostenfrei bleiben oder, ob für bestehende Abonnements möglicherweise drastische Preiserhöhungen stattfinden. Denn es sollte uns schon klar sein, das kommerziell genutzte Werkzeuge, die unsere Produktivität erheblich verbessern, üblicherweise nicht zum Schnäppchenpreis verfügbar sind.
Ich denke auch, dass das Internet, wie wir es bisher gewohnt sind, sich in Zukunft sehr stark verändern wird. Viele der kostenlosen Angebote, die bisher durch Werbung finanziert sind, werden mittelfristig verschwinden. Schauen wir uns dazu einmal als Beispiel den Dienst „Stack Overflow“ an – in Entwicklerkreisen eine sehr beliebte Wissensplattform. Wenn wir nun künftig für die Recherche zu Fragestellungen der Programmierung ChatGPT oder andere neuronale Netze nutzen, sinken für Stack Overflow die Besucherzahlen kontinuierlich. Die Wissensbasis wiederum, die ChatGPT nutzt, basiert auf Daten von öffentlichen Foren wie Stack Overflow. Somit wird auf absehbare Zeit Stack Overflow versuchen, seine Dienste für KIs unzugänglich zu machen. Es könnte sicher auch eine Einigung mit Ausgleichszahlungen zu Stande kommen, sodass die wegfallenden Werbeeinnahmen kompensiert werden. Denn als Techniker muss uns nicht ausschweifend dargelegt werden, dass für ein Angebot wie Stack Overflow erhebliche Kosten für den Betrieb und die Entwicklung anfallen. Es bleibt dann abzuwarten, wie die Nutzer das Angebot künftig annehmen werden. Denn wenn auf Stack Overflow keine neuen Daten zu Problemstellungen hinzukommen, wird die Wissensbasis für KI-Systeme auch uninteressant. Daher vermute ich, dass bis zirka 2030 vor allem hochwertige Inhalte im Internet kostenpflichtig werden.
Wenn wir die Prognose des mittelfristigen Trends über den Bedarf von Programmierern betrachten, kommen wir zu der Frage, ob es künftig eine gute Empfehlung sein wird, Informatik zu studieren oder eine Ausbildung als Programmierer anzutreten. Ich sehe hier tatsächlich eine positive Zukunft und würde jedem, der eine Ausbildung als Berufung versteht und nicht als Notwendigkeit ansieht, seinen Lebensunterhalt zu bestreiten, in seinem Vorhaben bekräftigen. Meiner Ansicht nach werden wir weiterhin viele innovative Köpfe benötigen. Lediglich jene, die sich anstatt sich mit Grundlagen und Konzepten zu beschäftigen, lieber mal schnell ein aktuelles Framework erlernen wollen, um aufkommende Hypes des Marktes mitzunehmen, werden sicher nur noch geringen Erfolg in Zukunft erzielen. Diese Beobachtungen habe ich aber auch bereits vor der breiten Verfügbarkeit von KI-Systemen machen können. Deshalb bin ich der festen Überzeugung, dass sich langfristig Qualität immer durchsetzen wird.
Dass man sich stets Themen möglichst kritisch und aufmerksam nähern sollte, betrachte ich als eine Tugend. Dennoch muss ich sagen, dass so manche Ängste im Umgang mit KI recht unbegründet sind. Sie haben ja schon einige meiner möglichen Zukunftsvisionen in diesem Artikel kennengelernt. Aussagen wiederum, dass die KI einmal unsere Welt übernehmen wird, indem sie unbedarfte Nutzer subtil beeinflusst, um diese zu Handlungen zu motivieren, halte ich für einen Zeitraum bis 2030 eher für reine Fantasie und mit dem aktuellen Erkenntnisstand unbegründet. Viel realistischer sehe ich das Problem, dass findige Marketingleute das Internet mit minderwertigen, ungeprüften, nicht redigierten, KI-generierten Artikeln übersähen, um ihr SEO-Ranking aufzupeppen und diese wiederum als neue Wissensbasis der neuronalen Netze die Qualität künftiger KI-generierter Texte erheblich reduziert.
Die bisher frei zugänglichen KI-Systeme haben gegenüber dem Menschen einen entscheidenden Unterschied. Ihnen fehlt die Motivation, etwas aus eigenem Antrieb zu tun. Erst durch eine extrinsische Anfrage durch den Nutzer beginnt die KI, eine Fragestellung zu bearbeiten. Interessant wird es dann, wenn eine KI sich aus eigenem Antrieb heraus selbstgewählten Fragestellungen widmet und diese auch eigenständig recherchiert. In diesem Fall ist die Wahrscheinlichkeit sehr hoch, dass die KI sehr schnell ein Bewusstsein entwickeln wird. Läuft eine solche KI dann noch auf einem Hochleistungsquantencomputer, haben wir nicht genügend Reaktionszeit, um gefährliche Entwicklungen zu erkennen und einzugreifen. Daher sollten wir uns durchaus das von Dürrenmatt geschaffene Drama „Die Physiker “ in unserem Bewusstsein halten. Denn die Geister, die ich einmal rief, werde ich möglicherweise nicht so schnell wieder los.
Grundsätzlich muss ich zugeben, dass mich das Thema KI weiterhin fasziniert und ich auf die künftige Entwicklung sehr gespannt bin. Dennoch finde ich es wichtig, auch vor der dunklen Seite der Künstlichen Intelligenz den Blick nicht zu versperren und dazu einen sachlichen Diskurs zu beginnen, um möglichst schadenfrei das vorhandene Potenzial dieser Technologie auszuschöpfen.
Seit Windows 10 verlieren Nutzer mehr und mehr die Kontrolle über ihre Systeme. Das Schlüsselwort ist Governance (oder besser Bevormundung), wo Unternehmen versuchen, ihre Nutzer zu erziehen. Keine Sorge, ich werde keine große Rede über die Willensfreiheit und die bösen Tech-Unternehmen halten. In diesem Artikel gebe ich Ihnen die Möglichkeit, die Kontrolle über Ihr Computergerät zurückzugewinnen. Verabschieden Sie sich von Microsoft und Windows und beginnen Sie Ihre Reise mit Linux.
Um das Jahr 2015 herum fasste ich den Entschluss, mich von Microsoft Windows zu lösen und zu 100% auf Linux umzusteigen. Ich hatte zu diesem Zeitpunkt bereits einige Erfahrungen mit Linux auf der Serverseite. Aber Linux täglich auf dem Desktop für alle Aufgaben zu verwenden, war eine neue Herausforderung, denn die Dinge sind nicht gleich. So verbrachte ich rund 4 Wochen und mehrere Versuche damit, eine Linux-Desktop-Distribution zu finden, die am besten zu meinen Bedürfnissen passt. Die Dinge, auf die man achten muss, um das beste Ergebnis für sich selbst zu erzielen, sind die Verfügbarkeit eines riesigen Software-Repositorys, aus dem man alle Anwendungen beziehen kann, die man braucht. Ein weiterer wichtiger Punkt ist das Aussehen und die Bedienung des Desktops. Auch hier gibt es mehrere Optionen, aus denen man auswählen kann. Bevor ich einen kurzen Überblick über Distributionen und Desktops gebe, muss ich das Problem der Softwareversionen und Repositories erklären.
Ein Software-Repository ist einfach ein großer Speicher, in dem die Binärdateien und Installationsprogramme für Ihre Anwendung abgelegt sind. Wenn Sie sich für eine Distribution und eine bestimmte Version entschieden haben, haben Sie ein definiertes Repository, in dem Sie Ihre Software und Distributions-Updates erwerben können. Nehmen wir an, wir haben eine Linux-Distribution mit einer Version von 2019. Der Support für diese Version läuft, sagen wir mal, bis 2020. Das bedeutet für das Software-Repository, dass die enthaltene Software nur einen Stand aus dieser Zeit enthält. Wenn Sie für diese Distribution die neueste GIMP-Version wie 2.10.36 vom November 2023 haben möchten, können Sie diese nicht aus dem ursprünglichen Distribution Repository beziehen. Die letzte Softwareversion für GIMP im ursprünglichen Repository ist die Version von 2020. Das gleiche Problem besteht bei älteren Softwareversionen. Dies ist ein sehr spezifisches Problem für Softwareentwickler und verfügbare Programmiersprachen. Wenn Sie alte PHP- oder JAVA-Anwendungen pflegen müssen, benötigen Sie ganz bestimmte Compiler und Interpreter, die möglicherweise nicht in Ihrem Software-Repository enthalten sind. Um dieses Problem zu lösen, gibt es verschiedene Lösungen. Entwickler können zum Beispiel Docker verwenden. Als normaler Benutzer können Sie versuchen, ältere oder neuere Versionen einer Software direkt vom Entwickler/Hersteller zu erhalten. Mit diesem Wissen können wir nun lernen, was eine Distribution ist und welche davon existiert.
Wenn Sie eine Linux-Distribution oder kurz Distro für sich auswählen möchten, haben Sie eine riesige Auswahl. Aber was ist eine Distro? Im Allgemeinen kann man sagen, dass ein Hersteller einen Linux-Kernel, eine Sammlung von Software und ein Repository zusammenstellt und alles mit seinem eigenen Look and Feel dekoriert. Es ist auch möglich, dass man sein eigenes Linux erstellt, einschließlich der Kompilierung eines eigenen Kernels. Aber Linux ist nicht gleich Linux. Wir müssen zwischen Linux und Unix unterscheiden. Linux ist ein Derivat von Unix, wie der Name LinUx eine Kombination aus Linus und Unix bereits vermuten lässt. Der große Unterschied zwischen Linux und Unix besteht in der Netzwerkfunktionalität, die bei Unix weiter fortgeschritten ist. Das Betriebssystem (BS) von Apple basiert beispielsweise auf Unix. Ein sehr verbreitetes Unix-Betriebssystem ist FreeBSD. BSD bedeutet Barkley Software Distribution und wird von der Barkley Universität in Kalifornien kontinuierlich weiterentwickelt.
Daneben gibt es drei Haupt Linux-Zweige, die auch weitere Ableitungen enthalten. Als erstes gibt es das aus Deutschland stammende Suse mit dem YAST Paketmanager für den Zugriff auf die Software-Repositories. Suse 7.2 war übrigens mein erster Desktop-Test im Jahr 2002. Suse ist nicht so verbreitet. Deswegen ist es manchmal recht schwierig, für spezielle Fragen oder Probleme ausreichend Inhalte zu finden. Eine weitere Distribution kommt von Red Hat, einem Open-Source Pionier. RHEL oder Red Hat Enterprise Linux ist eine kommerzielle Linux-Serverdistribution. Der Grund dafür ist, dass ein kommerzielles Linux für Server-Produktivsystemen vorhanden ist. Mit einer RHEL-Lizenz erhalten Unternehmen von Red Hat professionelle Unterstützung in Notfällen. Der Red Hat Desktop wird nicht mehr unterstützt und wurde auf Fedora Linux gewandelt. Der Standardpaketmanager für deren Software-Repositorys ist YUM. Der letzte Zweig der wichtigsten Linux-Distributionen ist Debian mit einer großen Auswahl an Unterdistributionen. Alle beliebten Einsteiger-Distributionen wie Linux Mint, Ubuntu oder Zorin OS basieren auf Debian. Als ich 2015 auf den Linux-Desktop umgestiegen bin, habe ich mit Ubuntu Mate LTS angefangen und bin seit Ende 2023 auf Debian 12 mit einem Gnome 3-Desktop umgestiegen. Der Standardpaketmanager für Debian-Systeme ist APT. Ubuntu führte 2023 seinen eigenen SNAP Paketmanager ein.
Ein weiterer wichtiger Begriff im Linux-Universum ist der Desktop-Manager. Hier stehen zur Auswahl: KDE, Gnome, Mate, XFCE und Cinnamon. Wie meine Liste der Distributionen ist auch die Liste der verfügbaren Desktops nicht vollständig. Ich kann im Unfang dieses Artikels nur die häufigsten erwähnen. Die meisten Linux-Distributionen verfügen standardmäßig über mehrere Desktop-Manager. Sie können daher während des Anmeldevorgangs auswählen, welchen Desktop Sie verwenden möchten. So können Sie ganz einfach ausprobieren, welcher Desktop am besten zu Ihnen passt. Später, wenn Sie mehr Erfahrung haben und Ihre Wahl für Ihre tägliche Arbeit bereits getroffen haben, können Sie unerwünschte Desktops während des Installationsvorgangs abwählen, um etwas Speicherplatz zu sparen.
Das schwierigste am Anfang meines Linux-Abenteuer war es zu verstehen, wo die Dinge gespeichert werden. Beispielsweise wird Software von Drittanbietern normalerweise im Verzeichnis opt installiert. Kompliziert ist auch das Berechtigungssystem für Dateien und Verzeichnisse auf ext3/ext4. Dieses Konzept existiert nicht im Windows FAT- oder NTFS-Dateisystem. Aber keine Sorge das bekommt man recht schnell bei der täglichen Arbeit in den Griff.
Microsoft Surface 3 PRO mit Ubuntu Linux
Als ich zum ersten Mal Ubuntu ausprobierte war das etwa 2010 als der Herstelle Canonical standardmäßig den UNITY Desktop einführte. Es gefiel mir nicht, weil es viel Werbung und unerwünschte Apps wie Spotify und Facebook enthielt. Ich habe herausgefunden, dass Ubuntu eine Version mit einem Gnome Dektop-Klon namens Mate hat. Ich beschloss diesen auszuprobieren und war vom ersten Moment an begeistert. Nach der ersten Installation auf meinem Laptop im Jahr 2015 musste ich bis 2023 nur noch 2 Mal Ubuntu neu auf meinem System installieren. Der Grund dafür war, dass ich meine interne SSD zunächst gegen 1 TB und später gegenuna historia sobre el 2 TB ausgetauscht habe. Es gab keine Probleme, dass die Systeme langsamer wurden oder die Festplatte mit verwaisten Dateien zugemüllt wurde. Keine regelmäßigen Reinigungs- und Wartungsaufgaben wie sie unter Windows üblich sind. Das System funktionierte stabil und ohne schwerwiegende Abstürze. Ich hatte auch nie Probleme mit Hardwaretreibern. Alle meine neuen Komponenten wurden unter Linux immer korrekt erkannt und es gibt oft kleine Verwaltungstools. Zum Beispiel Stremdeck UI oder Noson für Sonos Lautsprecher. Als ich im Dezember 2023 meinen neuen Laptop bekam beschloss ich, von Ubuntu auf das Original Debian umzusteigen. Weil Ubuntu von einem Unternehmen gemacht wird und sie oft beschließen ihren eigenen Weg zu gehen. Wer weiß ob sie in Zukunft ein ähnliches Verhalten wie Microsoft an den Tag legen werden. Ich bevorzuge es meinen Übergang immer frühzeitig zu vollziehen ohne Druck, um vorbereitet zu sein bevor mir keine andere Wahl bleibt.
Natürlich verwende ich auf meinem System ein Antivirenprogramm und eine Firewall. Da Linux nicht vor bösen Angriffen geschützt ist, sind auch Schutzmaßnahmen erforderlich.
Viele Leute vermasseln den Wechsel von Microsoft Office zu Libre Office. Das wirkliche Geheimnis um das Layout nicht zu verlieren besteht darin, auf die Schriftarten zu achten. Wenn die MS Office-Originaldokumente die standardmäßigen Microsoft-Schriftarten verwenden, müssen diese auch auf dem Linux-Computer installiert sein. So wird das Layout des Office-Dokuments nicht zerszört.
Für mich besteht keine wirkliche Notwendigkeit, zu Windows zurückzukehren. Nun ja, ich bin auch kein Gamer aber auch dafür gibt es viele Lösungen. Steam ist zum Beispiel unter Linux verfügbar. Die meisten Leute, die ich kenne, spielen nicht einmal mehr auf PCs oder Laptops, sondern bevorzugen Konsolen wie PlayStation. Für mich ist Linux cool, weil ich die volle Kontrolle über mein System habe, es kostenlos ist und ich es nach meinen Wünschen anpassen kann. Wer einen alten Laptop besitzt, der mit Windows nicht mehr funktioniert kann versuchen Linux darauf zu installieren und das Ergebnis genießen.
Linux entwickelt sich mehr und mehr zu einem beliebten Betriebssystem für IT-Profis. Einer der Gründe für diese Entwicklung sind die Serverlösungen. Stabilität und geringer Ressourcenverbrauch sind einige der wichtigsten Eigenschaften für diese Wahl. Wer schon einmal mit einem Microsoft Server herumgespielt hat, wird den grafischen Desktop bei einem Linux Server vermissen. Nach dem Einloggen in einen Linux Server siht man nur die Kommandozeile, die auf Eingaben wartet.
In diesem kurzen Artikel stelle ich einige hilfreiche Linux-Programme zur Umgang mit Text Dateien auf der Kommandozeile vor. Auf diese Weise lassen sich leicht Informationen sammeln, zum Beispiel aus Protokolldateien (Logfiles). Bevor ich beginne, möchte ich noch einen einfachen und leistungsfähigen Editor namens joe empfehlen.
Strg + C – Abbrechen der aktuellen Bearbeitung einer Datei ohne Speichern der Änderungen Strg + KX – Beenden der aktuellen Bearbeitung und Speichern der Datei Strg + KF – Text in der aktuellen Datei suchen Strg + V – Einfügen der Zwischenablage in das Dokument (CMD + V für Mac) Strg + Y – Aktuelle Zeile an der Cursorposition löschen
Um joe auf einer Debian-basierten Linux-Distribution zu installieren, müssen Sie nur folgendes eingeben:
1. Wenn Sie Inhalte in einer großen Textdatei finden müssen, ist GREP Ihr bester Freund. Mit GREP können Sie nach Textmustern (Pattern) in Dateien suchen.
Als ich vor über 10 Jahren begonnen habe testgetrieben zu programmieren, waren mir sehr viele verschiedene Konzepte theoretisch bekannt. Aber diese Sichtweise erst Testfälle zu schrieben und dann die Implementierung umzusetzen war irgendwie nicht der Weg mit dem ich gut zurecht gekommen bin. Wenn ich ehrlich bin ist das bis heute der Fall. So das ich eine für mich funktionierende Adaption des TDD Paradigma von Kent Beck gefunden habe. Aber langsam der Reihe nach. Vielleicht ist mein Ansatz ja für den einen oder anderen ebenfalls recht hilfreich.
Ich komme ursprünglich aus einem Umfeld für hoch skalierbarer Webanwendungen auf die sich all die tollen Theorien aus dem universitären Umfeld in der Praxis nicht ohne weiteres umsetzen lassen. Der Grund liegt vor allem in der hohen Komplexität solcher Anwendungen. Zum einen sind verschiedene Zusatzsysteme wie In Memory Cache, Datenbank und Identität und Zugriffs Management (IAM) ein Teil des Gesamtsystems. Zum Anderen verstecken viele moderne Frameworks wie OR Mapper Komplexität hinter verschiedene Zugriffsschichten. All diese Dinge müssen wir als Entwickler heutzutage beherrschen. Deshalb gibt es robuste, praxiserprobte Lösungen die gut bekannt sind aber wenig Verwendung finden. Kent Beck mit ist eine der wichtigsten Stimmen für den praktischen Einsatz automatisierter Softwaretest.
Wenn wir uns auf das Konzept TDD einlassen wollen ist es wichtig nicht jedes Wort zu sehr auf die Goldwaage zu legen. Es ist nicht alles in Stein gemeißelt. Wichtig ist das Ergebnis am Ende des Tages. Aus diesem Grund ist es unabdinglich sich die Zielvorgabe aller Bemühungen vor Augen zu führen um dann einen persönlichen Mehrwert zu erzielen. Also schauen wir uns zu erst einmal an was wir überhaupt bezwecken wollen.
Der Erfolg gibt uns Recht
Als ich meine ersten Gehversuche als Entwickler unternommen hatte benötigte ich stetiges Feedback ob das was ich da gerade zusammen bauen auch wirklich funktioniert. Diese Feedback habe ich meist dadurch erzeugt, in dem ich meine Implementierung einerseits mit unzähligen Konsolenausgaben gespickt habe und andererseits habe ich immer versucht alles in eine Benutzeroberfläche einzubinden um mich dann ‚manuell durchzuklicken‘. Im Grunde ein sehr umständliches Test Setup, das dann auch am Schuß wieder zu entfernen ist. Wenn dann noch spätere Bugfixes vorgenommen werden mussten ging das ganze Prozedere wieder von Neuem los. Alles irgendwie unbefriedigend und weit entfernt von einer produktiven Arbeitsweise. Irgendwie musste das verbessert werden ohne das man sich jedes Mal neu erfindet.
Schließlich hat mein ursprünglicher Ansatz genau zwei markante Schwachstellen. Die offensichtlichste ist das ein und auskommentieren von Debug Informationen über die Konsole.
Viel schwerwiegender ist aber der zweite Punkt. Denn all das erworbene Wissen zu dieser speziellen Implementierung ist nicht konserviert. Es droht also über die Zeit zu verblassen und schlußendlich auch verloren zu gehen. Ein solches Spezialwissen ist für viele nachfolgende Prozessschritte in der Softwareentwicklung aber äußerst wertvoll. Damit meine ich explizit das Thema Qualität. Refactoring, Code Reviews, BugFixes und Change Requests sind nur einige der möglichen Beispiele wo tiefgreifendes Detailwissen gefragt ist.
Für mich persönlich kommt auch hinzu, das mich monoton wiederholbare Arbeiten schnell ermüden und ich diese dann sehr gern vermeiden möchte. Sich immer wieder aufs neue mit der selben Testprozedur durch eine Anwendung zu klicken ist weit davon entfernt was für mich einen erfüllten Arbeitstag ausmacht. Ich möchte neue Dinge entdecken. Das kann ich aber nur wenn ich nicht in der Vergangenheit gefangen gehalten werde.
Bevor ich aber darauf eingehe wie ich meinen Entwicklungsalltag durch TDD aufgepeppt habe muss ich noch ein paar Worte über Verantwortung und Mut loswerden. Immer wieder wird mir in Gesprächen erklärt das ich ja recht habe aber man können das alles ja nicht selber umsetzen, weil der Projektleiter oder irgend ein anderer Vorgesetzter kein grünes Licht gibt.
Eine solche Einstellung ist in meinen Augen äußerst unprofessionell. Ich frage doch auch nicht den Marketingleiter welcher Algorithmus am besten terminiert. Er hat schlichtweg keine Ahnung, denn es ist auch nicht sein Aufgabengebiet. Ein Projektleiter der sich gegen das testgetriebene Arbeiten im Entwicklungsteam ausspricht hat aber auch seinen Beruf verfehlt. In der heutigen Zeit sind Testframeworks so gut in die Build Umgebung integriert, das die Vorbereitung für TDD sich selbst für unerfahrene Personen in wenigen Augenblicken umsetzen lässt. Es ist also nicht notwendig das Vorhaben an die große Glocke zu hängen. Denn ich kann versprechen das selbst bei den ersten Gehversuchen nicht mehr Zeit benötigt wird als mit der ursprünglichen Vorgehensweise. Ganz im Gegenteil sehr schnell wird sich eine merkliche Erhöhung der Produktivität einstellen.
Die erste Stufe der Evolution
Wie bereits erwähnt ist Logging für mich ein zentrale Teil der testgetriebene Entwicklung. Wann immer es sinnvoll erscheint versuche ich den Zustand von Objekten oder Variablen auf der Konsole auszugeben. Wenn wir hierfür die aus der verwendeten Programmiersprache zur Verfügung gestellten Mittel nutzen, bedeute dies das wir diese Systemausgaben nach getaner Arbeit mindestens auskommentieren müssen und bei späterer Fehlersuche wieder einkommentieren. Ein redundantes und fehleranfälliges Vorgehen.
Nutzen wir hingegen von beginn an ein Logging Framework so können wir die Debug Informationen getrost im Code stehen lassen und deaktivieren diese später im Produktivbetrieb über den eingestellten Log Level.
Ich nutze Logging aber auch als Tracer. Das heißt jeder Konstruktor einer Klasse schreibt während er aufgerufen wird einen entsprechenden Log Eintrag im Log Level Info. Damit kann man sehen in welcher Reihenfolge Objekte instanziiert werden. Hin und wieder bin ich so auch auf die übermäßig oft vorkommende Instanziierung eines einzelnen Objektes aufmerksam geworden. Dies ist hilfreich für Maßnahmen zur Performance und Speicheroptimierung.
Fehler die bei der Ausnahmebehandlung geworfen werden logge ich je nach Kontext als Error oder Warning. Das ist später im Betrieb ein sehr hilfreiches Mittel um Fehlern auf die Spur zu kommen.
Wenn ich also eine Datenbankzugriff habe, schreibe ich also eine Logausgabe im Log Level Debug wie das zugehörige SQL zusammen gebaut wurde. Führt dieses SQL zu einer Exception, weil ein Fehler enthalten ist so wird diese Exception mit dem Log Level Error geschrieben. Findet wiederum eine einfache Suchanfrage mit korrekter SQL Syntax statt und die Ergebnismenge ist leer wird dieses Ereignis je nach Bedarf entweder als Debug oder Warning klassifiziert. Handelt es sich beispielsweise um eine Loginanfrage mit falschem Benutzernamen oder Passwort neige ich dazu mich für den Log Level Warning zu entscheiden, da dies im Betrieb eventuell sicherheitstechnische Aspekte enthält.
Im gesamten Kontext konfiguriere ich das Logging für die Testfallausführung eher sehr geschwätzig und beschränke mich auf eine reine Konsolenausgabe. Im Betrieb wiederum werden die Logging Informationen in eine Logfile geschrieben.
Die Henne oder das Ei
Wenn wir mit dem Logging die Voraussetzung für eine zusätzliche Feedbackschleife gelegt haben stellt sich im nächsten Schritt die Frage wie geht es weiter. Wie bereits erwähnt tue ich mich sehr schwer erst einen Testfall zu schreiben um dann eine entsprechende Implementierung dafür zu finden. Vor diesem Problem stehen auch viele andere Entwickler die mit TDD beginnen.
Eine Sache die ich bereits voraus nehmen kann ist das Problem, das man bei einer Implementierung darauf achten muss diese auch testbar zu halten. Habe ich erst den Testfall so merke ich umgehend ob das was ich gerade erstelle auch wirklich testbar ist. Erfahrene TDD Entwickler haben recht schnell in Fleisch und Blut übernommen wie testbarer Code auszusehen hat. Der wichtigste Punkt hierbei ist das Methoden stets einen Rückgabewert haben sollten, der möglichst nicht null ist. So etwas erreicht man beispielsweise wenn man anstatt null eine leere Liste zurück gibt.
Die Vorgabe einen Rückgabewert zu haben liegt an der Art und Weise wie Unit Test Frameworks arbeiten. Ein Testfall vergleicht den Rückgabewert einer Methode mit einem Erwartungswert. Die Testzusicherung (engl. Assertation) kennt verschiedene Ausprägungen und kann entsprechend: gleich, ungleich, wahr oder falsch sein. Natürlich gibt es hier auch verschieden Variationen. So kann es unter Verwendung von Exceptions möglich sein Methoden die keinen Rückgabewert haben zu testen. Alle diese Details erschließen sich bei der Anwendung in sehr kurzer Zeit. So das jeder ohne langwierige Vorbereitungen umgehend loslegen kann.
Bei der Lektüre des Buches Test Driven Development by Example von Kent Beck finden wir auch schnell eine Erklärung warum die Testfälle zu erst geschrieben werden sollten. Es handelt sich um einen psychologischen Faktor. Es soll uns dabei helfen den üblichen Stress der im Projekt entsteht besser zu bewältigen. Es erzeugt in uns einen mentalen Zustand über den Zustand und Fortschritt der aktuellen Arbeit. Es leitet uns in eine iterativen Prozess die vorhandene Lösung schrittweise über die verschiedenen Testfälle weiter auszubauen und zu verbessern.
Für alle die wie ich aber zu beginn einer Implementierung noch keine konkrete Vorstellung über das fertige Ergebnis haben ist dieser Ansatz schwer umzusetzen. Der bezweckte Effekt der Entspannung kehrt sich ins negative um. Da wir Menschen alle unterschiedlich sind müssen wir also herausfinden wie wir ticken um das bestmögliche Ergebnis zu erzielen. Ganz so wie es mit Lernstrategien ist. Manche Menschen verarbeiten Informationen besser visuell andere eher haptisch und wieder andere extrahieren alles wichtige aus gesprochenem. Versuchen wir uns also nicht wider unserer Natur zu verbiegen um mittelmäßige oder schlechte Ergebnis zu produzieren.
Den ersten Strich zeichnen
Mir erschließt sich ein Thema eben erst während ich damit arbeite. Also Versuche ich mich solange an einer Implementierung bis ich ein erstes Feedback benötige. Genau dann schreibe ich den ersten Test. Es ergebenen sich bei diesem Vorgehen automatisch Fragen bei der jede einzelne einen eigenen Testfall wert ist. Finde ich alle vorhanden Ergebnisse? Was passiert wenn die Ergebnismenge leer ist. Wie lässt sich die Ergebnismenge eingrenzen? Alles Punkte die sich auf einem Zettel notieren und Schritt für Schritt abhaken lassen. Die Idee eine Aufgabenliste auf einem Zettel zu notieren hatte ich schon sehr lange bevor ich das bereits erwähnte Buch von Kent Beck gelesen habe. Es hilft mir schnelle Gedanke zu konservieren ohne mich von meinem aktuellen Tun ablenken zu lassen. Außerdem vermittelt es am Ende des Tages ein Gefühl etwas geschafft zu haben.
Da ich nicht warte bis ich alles Umgesetzt habe, um den ersten Test zu schreiben ergibt sich auch bei diesem Vorgehen ein iterativer Ansatz. Ich merke auch sehr schnell wenn mein Entwurf nur unzureichend testbar ist, da ich sofort eine Rückmeldung erhalte. Daraus ergibt sich meine eigene Interpretation für TDD die sich durch den permanenten Wechsel zwischen Implementieren und Test schreiben auszeichnet.
Als Ergebnis meiner frühen TDD Versuche habe ich bereits in der ersten Woche eine Beschleunigung meiner Arbeitsweise bemerkt. Ich bin auch sicherer geworden. Aber auch die Art und Weise wie ich Programmiere hat sich schon sehr zeitig zu verändern begonnen. Mir ist aufgefallen das mein Code kompakter und robuster geworden ist. Dinge die sich erst mit der Zeit aufgezeigt hatten ergaben sich bei Tätigkeiten wie Refactoring und Erweiterungen. Fehlgeschlagene Testfälle haben mich vor bösen Überraschungen bewahrt.
Ohne Übereifer beginnen
Wenn wir uns in einem bestehenden Projekt dazu entschließen TDD einzusetzen ist es eine schlechte Idee loszulegen und für bestehende Funktionalität Testfälle zu schreiben. Abgesehen von der Zeit die hierfür eingeplant werden muss wird das Ergebnis die hohen Erwartungen nicht erfüllen.
Eines der Probleme ist das man sich nun in jede Funktionalität neu einarbeiten muss und das ist sehr Zeitaufwendig. Die Qualität der so entstandene Testfälle ist auch unzureichend. Das Problem ergibt sich auch aus der Erfahrung. Wird die Erfahrung erst aufgebaut so ist die Qualität der Testfälle auch noch nicht ganz optimal und möglicherweise muss auch Code umgeschrieben werden, damit dieser Testbar wird. Es entstehen also eine Menge Risiken die für das tägliche Projektgeschäft problematisch sind.
Ein bewährtes Vorgehen TDD einzuführen ist es einfach für die aktuelle Implementierung an der man gerade arbeitet einzusetzen. Es wird also der ist Zustand des aktuellen Problems durch automatisierte Tests dokumentiert. Da man sich bereits auf vertrautem Terrain befindet muss man sich nicht erst in eine neue Thematik einarbeiten, so das man sich voll auf das formulieren von aussagekräftigen Tests konzentrieren kann. Abgesehen davon, das man ungefragt Verantwortung über fremde Arbeiten übernimmt wenn man für diese Testfälle umgesetzt.
Bestehende Funktionalität wird nur bei Fehlerkorrekturen entsprechend um Testfälle ergänzt. Für die Korrektur muss man sich eh mit den Implementierungsdetails auseinander setzen, so das hier genügend Wissen vorhanden ist wie eine Funktionalität sich verhalten sollte. Die so entstandene Tests dokumentieren zusätzlich auch die Korrektur und stellen für die Zukunft sicher das sich das Verhalten bei Optimierungsarbeiten nicht verändert.
Folgt man dieser Vorgehensweise diszipliniert verliert man sich nicht in sogenannter hektischer Betriebsamkeit, die wiederum das Gegenteil von Produktivität ist. Zudem erwirbt man so recht schnell fundiertes Wissen wie effektive und aussagekräftige Tests umgesetzt werden können. Erst wenn ausreichend Erfahrung gesammelt wurde und möglicherweise umfangreiche Refactorings geplant werden, dann kann man überlegen wie für das gesamte Projekt die Testabdeckung schrittweise verbessert werden kann.
Qualitätsstufe
Nur weil Testfälle vorhanden sind bedeutet dies nicht das diese auch eine Aussagekraft haben. Genausowenig beweist eine hohe Testabdeckung das ein Programm fehlerfrei ist. Eine hohe Testabdeckung stellt nur sicher das sich ein Programm im Rahmen der Tests verhält.
Wir kann man also sicherstellen das die vorhandene Tests auch wirklich eine Bereicherung sind und eine gute Aussagekraft haben? Der erste und meines Erachtens wichtigste Punkt ist Testfälle möglichst kurz zu halten. Das heißt im Konkreten, das ein Test nur eine explizite Fragestellung beantwortet, z. B. Was passiert wenn die Ergebnismenge leer ist? Entsprechend der Fragestellung ergibt sich dann auch die Benennung der Testmethode. Den Mehrwert dieser Vorgehensweise ergibt sich in dem Moment wenn der Testfall fehlschlägt. Ist der Test sehr kurzgefasst lässt sich oft schon an der Testmethode ablesen worin das Problem besteht, ohne sich erst langwierig in einen Testfall einzuarbeiten zu müssen.
Ein anderer wichtiger Punkt im TDD Vorgehen ist für meine umgesetzte Funktionalität sowohl die Testabdeckung für Codezeilen als auch für Verzweigungen zu überprüfen. Kann ich zum Beispiel in einer IF-Abfrage das Eintreten einer einzelnen Bedingung nicht simulieren, so kann diese Bedingung bedenkenlos gestrichen werden.
Natürlich hat man im eigenen Projekt auch genügend Abhängigkeiten zu fremden Bibliotheken. Nun kann es vorkommen das eine Methode aus dieser Bibliothek eine Ausnahme wirft, die durch keinen Testfall simuliert werden kann. Das ist genau der Grund wieso man zwar eine hohe Testabdeckung anstreben sollte aber nicht verzweifeln muss wenn 100% nicht erreicht werden können. Gerade bei der Einführung von TDD ist ein gutes Maß für die Testabdeckung größer als 85% üblich. Mit wachsender Erfahrung des Entwicklungsteams kann dieser Wert bis zu 95% angehoben werden.
Abschließend ist aber noch anzumerken, das man sich nicht zu sehr in den Eifer begibt. Denn es kann auch schnell übertrieben werden und dann sind die ganzen gewonnene Vorteile schnell wieder dahin. Und zwar geht es um den Punkt das man keine Tests schreibt die wiederum Tests testen. Hier beißt sich die Katze in den Schwanz. Das gilt auch für Bibliotheken von Fremdanbietern. Für diese werden ebenfalls keine Test geschrieben. Kent Beck äußert sich hierzu sehr klar: Selbst wenn es gute Gründe gibt dem Code anderer zu misstrauen, teste ihn nicht. Externer Code erfordert mehr eigene Implementierungslogik.
Lessons Learned
Gerade die Erkenntnisse die sich bei dem Versuch eine möglichst hohe Testabdeckung zu erzielen sind die, welche sich beim künftigen Programmieren auswirken. Der Code wird kompakter und robuster.
Die Produktivität steigt einfach durch die Tatsache, das fehleranfällige und monotone Arbeiten durch Automatisierung vermieden werden. Es entstehen keine zusätzlichen Arbeitsschritte denn alte Gewohnheiten werden durch neue, bessere ersetzt.
Ein Effekt den ich immer wieder beobachten konnten, wenn sich einzelne Personen aus dem Team für TDD entschieden haben, wurden deren Erfolge schnell beachtet. Innerhalb weniger Wochen hat dann das gesamte Team TDD entwickelt. Jeder einzelne nach seinen eigene Fähigkeiten. Manche mit Test First andere wiederum so wie ich es gerade beschrieben habe. Zum Schluß zählt das Ergebnis und das war einheitlich hervorragend. Wenn die Arbeit leichter fällt und am Ende des Tages jeder einzelne auch noch das Gefühl hat auch etwas geleistet zu haben bewirkt dies im Team einen enormen Motivationsschub, der dem Projekt und dem Arbeitsklima eine gewaltigen Auftrieb verschafft. Also worauf warten Śie noch? Probieren Sie es am besten gleich selber aus.
Die im Oktober 2023 veröffentlichten neuen AGB für Microsoft-Dienste lösten in der IT-Welt einen Aufschrei aus. Der Grund war ein Absatz, in dem es hieß, dass mittlerweile alle Microsoft-Dienste auf künstlicher Intelligenz basieren. Diese K.I. soll dazu dienen, Urheberrechtsverletzungen zu erkennen. Dazu gehören Dinge wie Musik, Filme, Grafiken, E-Books und natürlich auch Software. Falls diese K. I. Urheberrechtsverletzungen auf dem System erkennt, sollten diese Dateien automatisch vom „System“ gelöscht werden. Derzeit ist nicht klar, ob diese Regel für die eigene lokale Festplatte oder nur für die Dateien in der Microsoft Cloud gilt. Microsoft hat außerdem erklärt, dass Benutzer, die gegen die Urheberrechtsbestimmungen verstoßen, künftig von allen Microsoft-Diensten ausgeschlossen werden sollen.
Dieser Ausschluss hat verschiedene ‘Geschmäckle’. Die ersten Fragen, die mir in den Sinn kommen, sind: Was passiert mit kostenpflichtigen Abonnements wie Skype? Werde ich gesperrt und anschließend wird mein ungenutztes Guthaben zurückerstattet? Ein noch schlimmeres Szenario wäre, dass ich möglicherweise auch all mein Guthaben und digitale Käufe wie den Zugang zu Spielen und anderen Dingen verliere. Oder sind kostenpflichtige Abonnements davon nicht betroffen? Bisher ist dieser Teil nicht klar.
Wenn Sie ein Apple-Benutzer sind und denken dass dies keine Auswirkungen auf Sie hat, stellen Sie sicher, dass Sie keinen Microsoft-Dienst verwenden, von dem Sie nicht wissen das dieser zu Microsoft gehört. Nicht jedes Produkt enthält den Firmennamen. Denken Sie darüber nach, denn wer weiß, ob diese Produkte Ihr System ausspionieren. Einige Anwendungen wie Skype, Teams, Edge Browser und Visual Studio Code sind auch für andere Plattformen wie Apple und Linux verfügbar.
Microsoft besitzt außerdem die Quellcode-Hosting-Plattform GitHub und ein soziales Netzwerk für Spezialisten namens LinkedIn. Mit Office 360 können Sie die gesamte Microsoft Office Suite per Webbrowser als Cloud-Lösung nutzen und alle Ihre Dokumente werden in der Microsoft Cloud gespeichert. Dieselbe Cloud, in der US-Regierungsinstitutionen wie die CIA, die NSA und viele andere ihre Dateien aufbewahren. Nun, es scheint wohl ein sicherer Ort für alle Ihre Gedanken zu sein, die in ein Office Dukument niedergeschreiben wurden.
Dieses kleine Detail zu Office-Dokumenten führt uns zu einer kleinen Randbemerkung in den neuen Geschäftsbedingungen von Microsoft. Der Kampf gegen Hassrede. Was auch immer das heißt. Öffentliche Beleidigungen und Verleumdungen werden seit jeher vom Gesetzgeber strikt als Straftat behandelt. Es ist kein Kavaliersdelikt, der mit einem kleine bußgeld geahndet wird. Daher ist mir nicht klar, was dieses ganze Gerede über Hassreden bedeutet. Vielleicht ist es ein Versuch, eine öffentliche Zensur der Meinungsfreiheit einzuführen.
Aber zurück zum Randhinweis der Microsoft-Nutzungsbedingungen zu Hassreden. Microsoft hat so etwas geschrieben wie: Wenn Hassreden festgestellt werden, wird der Benutzer verwarnt und wenn die Verstöße mehrmals auftreten, wird das Microsoft-Konto des Benutzers deaktiviert.
Wenn Sie vielleicht denken, dass dies nur etwas ist, was jetzt von Microsoft passiert, stellen Sie sicher, dass viele andere Unternehmen daran arbeiten, gleichwertige Dienste einzuführen. Die Kommunikationsplattform Zoom beispielsweise beinhaltete auch K. I. -Techniken, um die Benutzerkommunikation zu ‘Trainingszwecken’ zu beobachten.
Bei all diesen Neuigkeitenstellt sich eine große Frage die beantwortet werden muss: Was kann ich selbst tun? Die Lösung ist einfach. Verlassen Sie das digitale Universum und gehen Sie zurück in die reale Welt. Schalten Sie das Gehirn wieder ein. Benutzen Sie Stift und Papier, zahlen Sie bar, lassen Sie Ihr Smartphone zu Hause und dort niemals auf dem Nachttisch. Wenn Sie es nicht verwenden, schalten Sie es aus! Treffen Sie Ihre Freunde, wann immer es möglich ist physisch und bringen Sie dann nicht Ihr Smartphone mit. Es wird keine Regierung, keinen Präsidenten und keinen Messias geben, die eine Veränderung herbeiführen wird. Es ist an uns, dies zu tun.
README Dateien haben in Softwareprojekten eine lange Tradition. Diese ursprünglich reinen Textdateien enthielten Lizenzinformationen und Anweisungen wie aus dem Quellcode das entsprechende Artefakt kompiliert werden konnte oder aber wichtige Hinweise zu Installation des Programms. Es gibt keinen wirklichen Standard wie man eine solche README Datei aufbauen sollte.
Seit dem GitHub (2018 von Microsoft übernommen) als kostenfrei Code Hosting Plattform für Open Source Projekte seinen Siegeszug angetreten ist, gab es schon recht früh die Funktion, dass die README Datei als Startseite des Repositories anzuzeigen. Dazu muss lediglich eine einfach Textdatei mit der Bezeichnung README.md im Hauptverzeichnis des Repository erstellt werden.
Um die README Dateien übersichtlicher strukturieren zu können wurde eine Möglichkeit für eine einfache Formatierung gesucht. Schnell hatte man sich für die markdown Notation entschieden, da diese einfach zu nutzen ist und auch recht performant gerendert werden kann. Somit sind die Übersichtsseiten besser für Menschen zu lesen und können als Projekt Dokumentation genutzt werden.
Es ist möglich mehrere solcher markdown Dateien als Projektdokumentation miteinander zu verknüpfen. Somit erhält man eine Art Mini WIKI das im Projekt enthalten ist und außerdem auch über Git versioniert wird.
Das ganze wurde so erfolgreich, das Selfhosting-Lösungen wie GitLab oder das kommerzielle BitBucket diese Funktion ebenfalls übernommen haben.
Nun stellt sich aber die Frage welche Inhalte man am besten in solch eine README Datei schreibt, damit diese für Außenstehende auch einen wirklichen Mehrwert darstellen. Dabei haben sich im Laufe der Zeit folgende Punkte etabliert:
Kurzbeschreibung des Projektes
Bedingungen unter denen der Quellcode verwendet werden darf (Lizenz)
Wie ist das Projekt zu verwenden (z.B. Anweisungen zum Compilieren oder wie wird die Bibliothek in eigene Projekte eingebunden)
Wer sind die Autoren des Projekte und wie kann man sie erreichen
Was ist zu tun wenn man das Projekt unterstützen möchte
Mittlerweile sind sogenannte Badges (Sticker) sehr populär. Diese referenzieren oft auf externe Dienste wie beispielsweise der freie Continuous Integration Server TravisCI. Diese helfen ausstehenden die Qualität des Projektes zu beurteilen.
Auf GitHub gibt es auch diverse Vorlagen für README Dateien. Man muss allerdings auch ein wenig auf die tatsächlichen Gegebenheiten des eigenen Projektes schauen und beurteilen welche Information für Nutzer bzw. Anwender wirklich relevant sind. Solche Vorlagen helfen aber sehr dabei herauszufinden ob man möglicherweise eine Punkt übersehen hat.
Das mittlerweile ziemlich jeder Hersteller von Source Control Management Serverlösungen die Funktion die README.md Datei als Projektstartseite für das Code Repository anzuzeigen integriert hat, bedeutet das eine README.me auch für kommerzielle Projekte eine sinnvolle Sache sind.
Auch wenn der Syntax für markdown leicht zu erlernen ist kann es bei umfangreichen Editierungen solcher Dateien durchaus komfortabler sein direkt eine MARKDOWN Editor zu nutzen. Dabei sollte man darauf achten, das die Vorschau auch korrekt dargestellt wird und nicht nur ein einfaches Syntaxhighligting angeboten wird.
Die Software-Entwicklung bietet einige äußerst effiziente Möglichkeiten, wiederkehrende Handgriffe durch Automatisierung zu vereinfachen. Das Wegfallen…
Seit über einem Jahrzehnt hat sich die Erkenntnis durchgesetzt, das Computersysteme aktuell gehalten werden sollten. Wer regelmäßig Updates einspielt verringert das Risiko auf seinem Computer Sicherheitslücken zu haben, die Missbraucht werden könnten. Immer in der Hoffnung das Hersteller von Software stets in ihren Updates auch Sicherheitsmängel beheben. Microsoft hat beispielsweise seit der Einführung von Windows 10 seinen Nutzern ein Update-Zwang auferlegt. Grundsätzlich war die Idee durchaus begründet. Denn ungepatchte Betriebssysteme ermöglichen Hackern leichten Zugriff. Also hat sich vor sehr langer Zeit der Gedanke: ‚Latest is greatest‘ durchgesetzt.
Windowsnutzer habe hier wenig Freiräume. Aber auch auf mobilen Geräten wie Smartphones und Tabletts sind in der Werkseinstellung die automatischen Updates aktiviert. Wer auf GitHub ein Open Source Projekt hostet bekommt regelmäßige E-Mails um für verwendete Bibliotheken neue Versionen einzusetzen. Also auf den ersten Blick durchaus eine gute Sache. Wenn man sich mit der Thematik etwas tiefer auseinandersetzt kommt man sehr schnell zu dem Schluß das latest nicht wirklich immer das beste ist.
Das bekannteste Beispiel hierfür ist Windows 10 und die durch Microsoft erzwungenen Update Zyklen. Das Systeme regelmäßig auf Sicherheitsprobleme untersucht werden und verfügbare Aktualisierungen eingespielt werden müssen ist unumstritten. Das die Pflege von Rechnersysteme auch Zeit in Anspruch nimmt ist ebenfalls Einsichtig. Problematisch ist es aber wenn durch den Hersteller eingespielte Aktualisierungen einerseits das gesamte System lahmlegen und so eine Neuinstallation notwendig wird, weil das Update nicht ausreichend getestet wurde. Aber auch im Rahmen von Sicherheitsaktualisierungen ungefragt Funktionsänderungen bei den Nutzer einzubringen halte ich für unzumutbar. Speziell bei Windows kommt noch hinzu, das hier einiges an Zusatzprogrammen installiert ist, die durch mangelnde Weiterentwicklung schnell zu einem Sicherheitsrisiko werden können. Das bedeutet bei aller Konsequenz erzwungene Windowsupdates machen ein Computer nicht sicher, da hier die zusätzlich installierte Software nicht auf Schwachstellen untersucht wird.
Wenn wir einen Blick auf Android Systeme werfen, gestaltet sich die Situation weitaus besser. Aber auch hier gibt es genügend Kritikpunkte. Zwar werden die Applikationen regelmäßig aktualisiert, so das tatsächlich die Sicherheit markant verbessert wird. Aber auch bei Android bedeutet jedes Update in aller Regel auch funktionale Veränderungen. Ein einfaches Beispiel ist der sehr beliebte Dienst Google StreetMaps. Mit jeden Update wird die Kartennutzung für mich gefühlt unübersichtlicher, da eine Menge für mich unerwünschter Zusatzinformationen eingeblendet werden, die den bereits begrenzten Bildschirm erheblich verkleinern.
Als Nutzer ist es mir glücklicherweise noch nicht passiert, dass Applikationsupdates unter Android das gesamte Telefon lahmgelegt haben. Was also auch beweist das es durchaus möglich ist Aktualisierungen ausgiebig zu testen, bevor diese an die Nutzer ausgerollt werden. Was aber nicht heißt das jedes Update unproblematisch war. Probleme die hier regelmäßig beobachtet werden können sind Dinge wie ein übermäßig erhöhter Batterieverbrauch.
Reine Android Systemupdates wiederum sorgen regelmäßig dafür das die Hardware nach knapp zwei Jahren so langsam wird, das man sich oft dazu entscheidet ein neues Smartphone zu kaufen. Obwohl das alte Telefon noch in gutem Zustand ist und durchaus viel Länger genutzt werden könnte. So ist mir bei vielen erfahrenen Nutzern aufgefallen, das diese nach circa einem Jahr ihre Android Updates ausschalten, bevor das Telefon durch den Hersteller in die Obsoleszenz geschickt wird.
Wie bekommt man ein Update-Muffel nun dazu seine Systeme trotzdem aktuell und damit auch sicher zu halten? Mein Ansatz als Entwickler und Konfiguration Manager ist hier recht einfach. Ich unterscheide zwischen Feature Update und Security Patch. Wenn man im Release Prozess dem Semantic Versioning folgt und für SCM Systeme wie Git ein Branch by Release Modell nutzt, lässt sich eine solche Unterscheidung durchaus leicht umsetzen.
Aber auch der Fragestellung eine versionierbaren Konfigurationseinstellung für Softwareanwendungen habe ich mich gewidmet. Hierzu gibt es im Projekt TP-CORE auf GitHub eine Referenzimplementierung die in dem zweiteiligen Artikel Treasue Chest ausführlich beschrieben wird. Denn es muss uns schon klar sein, dass wenn wir bei einem Update die gesamte vom Nutzer vorgenommene Konfiguration auf Werkseinstellung zurück setzen, wie es recht oft bei Windows 10 der Fall ist, können ganz eigene Sicherheitslücken entstehen.
Das bringt uns auch zu dem Punkt Programmierung und wie GitHub Entwickler durch E-Mails dazu motiviert neue Versionen der verwendeten Bibliotheken in ihre Applikationen einzubinden. Denn wenn es sich bei einem solchen Update um eine umfangreiche API Änderung handelt ist das Problem der hohe Migrationsaufwand für die Entwickler. Hier hat sich für mich eine ebenfalls recht einfache Strategie bewährt. Anstatt mich von den Benachrichtigungen über Aktualisierungen von GitHub beeindrucken zu lassen, prüfe ich regelmäßig über OWASP ob meine Bibliotheken bekannte Risiken enthalten. Denn wird durch OWASP ein Problem erkannt, spielt es keine Rolle wie Aufwendig eine Aktualisierung werden kann. Das Update und ein damit verbunden Migration muss zeitnahe umgesetzt werden. Dies gilt dann auch für alle noch in Produktion befindlichen Releases.
Um von Beginn an der Update Hölle zu entrinnen gilt allerdings eine Faustegel: Installiere beziehungsweise nutze nur das was du wirklich benötigst. Je weniger Programme unter Windows installiert sind und je weniger Apps auf dem Smartphone vorhanden sind, um so weniger Sicherheitsrisiken entstehen. Das gilt auch für Programmbibliotheken. Weniger ist aus Sicht der Security mehr. Abgesehen davon bekommen wird durch den Verzicht unnötiger Programme noch eine Performance Vermessung frei Haus.
Sicher ist für viele privaten Anwender die Frage der Systemaktualisierung kaum relevant. Lediglich Neue unerwünschte Funktionen in vorhanden Programmen, Leistungsverschlechterungen oder hin und wieder zerschossene Betriebssysteme verursache mehr oder weniger starken Unmut. Im kommerziellen Umfeld können recht schnell erhebliche Kosten entstehen, die sich auch auf die gerade umzusetzenden Projekte negativ auswirken können. Unternehmen und Persone die Software entwickeln können die Nutzerzufriedenheit erheblich verbessern, wenn sie bei Ihren Release Veröffentlichungen zwischen Security Patches und Feature Updates unterscheiden. Und ein Feature Update sollte dann entsprechend auch allen bekannten Security Aktualisierungen enthalten.
Während meiner Arbeit als Konfiguration Manager / DevOps für große Webprojekte habe ich beobachtet, wie Unternehmen Conways Gesetzt missachten und dabei kläglich scheiterten. Ein solches Scheitern äußerte sich dann oft in erheblichen Budgetüberziehungen und Terminverzug.
Die interne Infrastruktur in der Projekt Kollaboration wurde genau der internen Organisationsstrukturen nachempfunden und sämtliche Erfahrungen und etablierte Standards so ‚verbogen‘, dass diese auf die interne Organisation passten. Daraus resultierten Probleme das die aufgesetzten CI / CD Pipelines besonders schwerfällig wurden und lange Ausführungszeiten hatten. Aber auch Anpassungen waren nur unter viel Aufwand vorzunehmen. Anstatt bestehende Prozesse zu vereinfachen und an etablierte Standards anzugleichen wurden Ausreden vorgeschoben um möglichst alles wie bisher zu belassen. Schauen wir uns daher einmal an, was Conways Gesetz ist und wieso man es beachten sollte.
Der US amerikanische Forscher und Programmierer Melvin E. Conway erhielt 1961 von der Case Western Reserve University die Doktorwürde. Sein Fachgebiet sind Programmiersprachen und Compiler Design.
Im Jahr 1967 reichte er bei The Harvard Business Review seinen Aufsatz „How Do Committees Invent?“ (dt.: Wie machen Ausschüsse Erfindungen?) ein und wurde abgelehnt. Die Begründung lautete, das seine These nicht belegt wurde. Das zu der Zeit größte IT Magazin Datamation akzeptierte allerdings seinen Artikel und veröffentlichte ihn im April 1968. Und diese Arbeit ist mittlerweile vielfach zitiert. Die Kernaussage lautet:
Jede Organisation, die ein System (im weitesten Sinne) entwirft, wird ein Design erstellen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.
Conway, Melvin E. “How do Committees Invent?” 1968, Datamation, vol. 14, num. 4, pp. 28–31
Als Fred Brooks in seinem 1975 erschienen legendärem Buch „The Mythical Man-Month“ den Aufsatz zitierte nannte er diese Kernaussage das Gesetz von Conway. Brooks erkannt den Zusammenhang von Conways Gesetz und der Managementtheorie. Hierzu finden wir in dem Artikel folgendes Beispiel:
Da der zuerst gewählte Entwurf fast nie der bestmögliche ist, muss möglicherweise das vorherrschende System Systemkonzepte ändern. Daher ist die Flexibilität der Organisation für eine effektive Gestaltung wichtig.
The Mythical Man-Month: Essays on Software Engineering
Ein oft zitiertes Beispiel für eine “ideale” Teamgröße im Sinne des Conway’schen Gesetzes ist die Zwei-Pizza-Regel von Amazon, die besagt, dass einzelne Projektteams nicht mehr Mitglieder haben sollten, als zwei Pizzen in einem Meeting satt werden können. Der wichtigste Faktor, der bei der Teamausrichtung zu berücksichtigen ist, ist jedoch die Fähigkeit, teamübergreifend zu arbeiten und nicht in Silos zu leben.
Conways Gesetz war nicht als Scherz oder Zen-Koan gedacht, sondern ist eine gültige soziologische Beobachtung. Schauen Sie sich dazu Strukturen aus Behörden und deren digitale Umsetzung an. Aber auch Prozesse in großen Konzernen zu finden sind wurden durch Softwaresysteme nachempfunden. Solche Anwendungen gelten als sehr schwerfällig und Kompliziert, so das diese wenig Akzeptanz bei Nutzern finden und diese lieber auf Alternativen zurückgreifen. Leider ist es oft aus politisch motivierten Gründen in großen Organisationsstrukturen schier unmöglich Abläufe zu vereinfachen.
Unter anderem findet sich ein ausführlicher Artikel von Martin Fowler, der expliziert auf Softwarearchitekturen eingeht und die Bedeutung der Kopplung von Objekten und Modulen herausarbeitet. Dabei spielt die Kommunikation der Entwickler untereinander eine wesentliche Rolle, um bestmögliche Ergebnisse zu erzielen. Dieser Umstand über die Wichtigkeit der Kommunikation wurde auch von der agilen Softwareentwicklung aufgegriffen und als essentieller Punkt umgesetzt. Besonders wenn rümlich verteilte Teams an einem gemeinsamen Projekt arbeiten ist die Zeitverschiebung ein limitierender Faktor in der Teamkommunikation. Diese muss dann besonders effizient gestaltet werden.
Im Jahr 2010 haben Jonny Leroy und Matt Simons in dem Artikel „Dealing with creaky legacy platforms“ den Begriff Inverse Conway Maneuver geprägt:
Conway’s Law … lässt sich wie folgt zusammenfassen: “Dysfunktionale Organisationen neigen dazu, dysfunktionale Anwendungen zu schaffen.” Um Einstein zu paraphrasieren: Man kann ein Problem nicht aus derselben Denkweise heraus beheben, die es geschaffen hat. Daher lohnt es sich oft zu untersuchen, ob eine Umstrukturierung Ihrer Organisation oder Ihres Teams verhindern würde, dass die neue Anwendung dieselben strukturellen Dysfunktionen aufweist wie die ursprüngliche. In einer Art “umgekehrtem Conway-Manöver” können Sie damit beginnen, Silos aufzubrechen, die die Fähigkeit des Teams zur effektiven Zusammenarbeit einschränken.
Seit den 2010 Jahren hat ein neuer Architekturstil in der Softwareindustrie Einzug gehalten. Die sogenannten Microservices, welche von kleine agilen Teams erstellt werden. Wichtigstes Kriterium eines Microservices zu einem modular aufgebauten Monolithen ist, das ein Microsoervice als eigenständig lebensfähiges Modul bzw. Subsystem gesehen werden kann. Das erlaubt zum einen eine Wiederverwendung des Microservice in anderen Anwendungen. Zum Anderen gibt es eine starke Kapselung der Funktionsdomäne, was eine sehr hohe Flexibilität für Anpassungen eröffnet.
Conways Gesetz lässt sich aber auch auf viele andere Bereiche anwenden und ist nicht ausschließlich auf die Softwareindustrie beschränkt. Das macht die Arbeit so wertvoll.
en] This article is only visible for logged in Patreons. With your Patreon membership you help me to keep this page up to date.
de] Dieser Artikel ist nur für eingeloggte Patreons sichtbar. Mit ener Patreon Mitgliedschaft helft Ihr mir diese Seite stets aktuell zu halten.
es] Este artículo sólo es visible para los Patreons registrados. Con tu suscripción a Patreon me ayudas a mantener esta página actualizada.
Unlock with Patreon
