i11.md

R1: Was tust du denn fachlich in einem Job? Also bist du irgendwie Tester, Teammanager, DevOps und so weiter?

I11: Ja, genau. Erzähle ich einfach mal ganz kurz ein bisschen was. Ich arbeite jetzt seit ungefähr 6 Jahren [hier] und arbeite hier offiziell als Software-Engineer. Das heißt ich entwickle Software. Meine Hauptaufgabe ist tatsächlich die Entwicklung von, die Weiterentwicklung von einem bestehenden Produkt oder von einem bestehenden Projekt. Das Projekt ist [Projekt]. Das gibt es in zwei Varianten, einmal gibt es den Open Source für die Community, kann sich jeder besorgen und testen und benutzen und dann gibt es noch eine Version, die hat einen kommerziellen Support, den man [hier] einkaufen kann. Das ganze nennt sich dann Enterprise Application Platform aber kurz EAP. Basiert auf der gleichen Codebasis, aber ist ein bisschen modifiziert dahingehend, dass es eben professionellen Support gibt und besser getestet ist. Das heißt es gibt so eine Upstream-Variante, das ist die Community-[Version], da fließen die neuen Features ein an denen ich auch weiterentwickle und dann von Zeit zu Zeit wird dieser Stand eingefroren und daraus wird dann dieses EAP. Und mein Part bei der Softwareentwicklung an der Entwicklung ist die, sind kleinere Teile an den Management APIs von [der Software] und meine Hauptaufgabe ist eigentlich dann die Entwicklung der Managementkonsole oder Adminkonsole. Das ist quasi mein Projekt, da habe ich bis kurzem waren wir da ein Team von zwei Leuten. Der Kollege hat jetzt das Team gewechselt, das heißt bin ich hier nur noch alleine für dieses Projekt zuständig und meine Arbeit sieht eigentlich täglich so aus, dass ich aus einem Pool von Anforderungen, Issues, RFIs — also wir so ein Ticketsystem, da habe ich meine Liste an Dingen, die ich umsetzen müsste oder muss für ein bestimmtes Release und da, die arbeite ich letztendlich in der Regel ab. Das sind teilweise neue Features, teilweise sind das Bugfixes. Das fließt dann als Pull Request in die Codebasis ein und landet dann irgendwann im Produkt.

R1: Okay, wo bist du hauptsächlich tätig? Im Backend, im Frontend, DevOps-Bereich?

I11: Das ist im wesentlichen momentan ist es vor allem das Frontend. Die Managementkonsole ist eine Webseite und diese Webseite basiert auf einem Framework das nennt sich Google Web Toolkit. Das ist von Google ein Toolkit um Webseiten zu entwickeln oder Webapplikationen zu schreiben. Das ganze passiert in Java und wird dann von einem Transpiler übersetzt nach JavaScript. Das eine (?04:23), die wurde vor Jahren mal festgelegt und die funktioniert eigentlich nach wie vor sehr sehr gut für die Webapplikation, weil das ist so eine Single-Page-Applikation. Das heißt die komplette Anwendung ist eigentlich in Java geschrieben mit wenigen Ausnahmen. Es gibt ein paar HTML-Seiten, aber im wesentlichen ist der Code recht komplex und für komplexe Anwendungen eignet sich Java einfach sehr sehr gut, weil man dann das ganze Ökosystem nutzen kann: Testing Frameworks, Webbibliotheken und und und. Und mittlerweile sind das — das ist eine Anwendung, die ist auch recht komplex wie gesagt. Das sind so um die 120.000 Zeilen Lines of Code. Das heißt es ist schon eine recht anspruchsvolle Anwendung und die wird dem Google Web Toolkit nach JavaScript übersetzt und die eigentliche Adminoberfläche ist dann nur noch ein großer Brocken HTML, JavaScript und CSS. Das ist das, was dann letztendlich vom [Produkt] ausgeliefert wird und wo wir dann nur noch so dahinter agieren.

R1: Dann, wie lange arbeitest du generell als Software-Entwickler? Also 6 Jahre [hier], aber—

I11: Genau. Ich arbeite jetzt mittlerweile — oh, lass mich überlegen — also ich habe mein Diplom an der [Hochschule] gemacht. Das war im Jahr 98 müsste das gewesen sein. Oder 99.

R1: Also seit zwanzig Jahren.

I11: Ja, also ich — genau. Und ich habe dann kurze Zeit als Selbständiger gearbeitet. [Dort], wo ich auch studiert habe und dann bin ich relativ schnell — zwei Jahre waren das glaube ich — dann bin ich [hier her] gegangen, hab mich dort beworben als IT-Consultant und war dann lange Zeit tätig als klassischer IT-Consultant, das heißt ich Projekte gemacht und beim Kunden entweder vor Ort oder In-House und habe dann mehrere Firmen, hab dann gewechselt, war bei mehreren Firmen [hier] tätig bis ich dann vor sechs Jahren dann gewechselt bin [hierher]. Und das passt alles sehr, sehr gut. Ich arbeite dort Remote, also kann ich von zuhause aus arbeiten, kann mir meine Zeit und meine Arbeit größtenteils frei einteilen unter gewissen Voraussetzungen natürlich. Genau und das macht einfach, macht Spaß und momentan passt das wunderbar für mich.

R1: Super. An deiner täglichen Arbeit, was ist denn der Anteil noch an Programmierung und Softwareentwicklung?

I11: Also ich habe noch einen sehr großen Anteil an Softwareentwicklung. Das heißt, deswegen mag ich die Arbeit auch so gerne. Ich bin Softwareentwickler mit Leib und Seele und das ist auch das, was mir Spaß macht. Und ich würde mal sagen, natürlich gibt es viel so ein bisschen Grundrauschen, es gibt sehr viel Email-Kommunikation, sehr viel Absprache auch mit dem Team, weil der Großteil der Leute remote auch arbeitet. Das heißt wir haben kein Büro im klassischen Sinne, sondern ich muss mich mit den Leuten eben abstimmen (?07:28) Email. Das heißt da gibt es immer so ein bisschen Grundrauschen, aber ich würde mal sagen Minimum 60 bis 70 % meiner täglichen Arbeit ist schon Softwareentwicklung.

R1: Mit welchen Frameworks und Tools arbeitest du denn für gewöhnlich?

I11: Also mein Stack schaut so aus, dass ich eben in Java entwickle. Das ist meine Programmiersprache 07:53 mit der ich jetzt auch schon, auch während meines mehr oder weniger meines kompletten Berufslebens entwickle. Ich gucke immer mal wieder so ein bisschen über den Tellerrand hinaus und schaue mir die ein oder anderen Dinge an. Das ist aber dann mehr so persönliche Weiterbildung, aber jetzt nichts, was ich dann auch im — für die Arbeit einsetze. Also die Programmiersprache, die ich einsetze ist Java. Ich komme natürlich dadurch, dass ich mit eine Webanwendung schreibe auch mit JavaScript in Kontakt, aber Gott sei Dank nimmt mir das Google Web Toolkit mir da einige Dinge ab, sodass ich da nur am Rande damit zu tun habe. Ich muss es halt verstehen und wissen, was ich tue. Das heißt, ja, das Google Web Toolkit ist eines der wichtigsten Frameworks für meine tägliche Arbeit. Gibt es auch schon sehr lange und wird auch von vielen jetzt immer wieder — also ist nicht mehr sehr populär, aber es ist ein Framework, das eben grundsolide ist, das fehlerfrei arbeitet über eine sehr lange Zeit jetzt schon, das sehr, sehr performanten Code entsprechend — JavaScript-Code erzeugt, der mit den modernen JavaScript-Frameworks eigentlich sehr konkurrieren oder auch noch die letztendlich auch noch übertrifft, was Performance und Optimierungsmöglichkeiten angeht. Dann gibt es letztendlich eine IDE, die ich benutze. Das ist von IntelliJ die IDE. Ich benutze die zum testen. Weil ich eine Java-Applikation schreibe, Java-Code schreibe, benutze ich zum Testen JUnit. Ich versuche möglichst bei der Programmierung die Dinge so zu trennen, dass ich einmal Code habe, der mit der Oberfläche interagiert, der dann halt mit dem Browser interagiert. Sowas kann man sehr schlecht testen, aber dann gibt es auch fachlichen Code und den versuche ich entsprechend zu kapseln, sodass ich dann mit JUnit-Tests den Code entsprechend testen kann. Dann gibt es einfach bei [uns] gewisse Dinge, die wir benutzen. Das heißt wir haben unseren Code auf GitHub. Wir arbeiten mit Git als Versionsverwaltung. Wir haben ein Issue-System, das auf Jira ba — Jira (?09:54) basiert. Damit arbeite ich sehr viel. Und dann gibt es eben Buildwerkzeuge. Also wir haben größtenteils unsere Projekte basieren auf Maven als Buildtool. Dann gibt es sowas wie CI-Server, Jenkins-Server oder von JetBrains gibt es auch noch ein CI-Buildtool, was wir verwenden. Das sind so die Dinge mit denen wir letztendlich unsere Projekte erzeugen.

R1: Okay, das wären so diese allgemeinen Fragen. Und jetzt vielleicht mal, was verstehst du denn unter dem Begriff Konfiguration?

I11: Ja, für mich ist Konfiguration die Anpassung, eine Möglichkeit Software anzupassen im Nachhinein, also alles Dinge, die fest verdrahtet im Code für immer und ewig in Stein gemeißelt sind, sondern letztendlich variable Teile, die dann von außen nachträglich noch angepasst werden können. So würde ich es im allgemeinen ganz allgemein definieren.

R1: Wann konfigurierst du denn Software? Also zu welcher — Compilezeit, Laufzeit und?

I11: Ja genau, also das ist schon mal ein ganz guter Stichpunkt. Man kann dann eben unterscheiden Compilezeit-, Laufzeitkonfiguration. Für meinen konkreten Fall für die Adminkonsole gibt es wenige Konfigurationsmöglichkeiten, weil man im wesentlichen ist da nicht viel anpassbar. Also es gibt einige Dinge, die man anpassen kann. Viele davon passieren zur Buildzeit, also während das ganze gebaut wird. Ein Beispiel dafür ist zum Beispiel, dass die Konsole leicht unterschiedlich aussieht, je nachdem ob ich die für die [Community-Version] verwende oder ob ich die für das kommerzielle Produkt verwende, für das EAP. Da gibt es ein anderes Theme und dieses Theme wird eben zur Buildzeit entsprechend konfiguriert. In meinm Fall wird es dadurch konfiguriert, dass ich eine bestimmte, einen bestimmten Parameter beim Build übergebe. Ganz anders schaut es dann zum Beispiel beim [Produkt] selber aus. Da gibt es eine sehr umfangreiche Möglichkeit das zu konfigurieren. Das ist auch eine Art von Konfiguration. Das ist dann vor allem zur Laufzeit. Das basiert einmal auf einer XML-Datei, die [das Produkt] ausliest. Dort werden sehr, sehr viele Dinge konfiguriert. Angefangen vom Log-Level bis hin zur eingesetzten Datenbank, die natürlich auch ensprechend konfiguriert werden muss. Das ist auch Konfiguration und das ist letztendlich das, was ich dann über die Adminkonsole, was der Benutzer anpassen kann und was dann wiederum ins XML geschrieben wird wenn die Konfiguration geändert wurde.

R1: Jetzt hast du ja auch schon gesagt du hast so fachliche Dinge. Wir unterscheiden auch zwischen fachlicher und technischer Konfiguration. Würdest du das genauso sehen und was wäre dann der Anteil an deiner Arbeit?

I11: Ja genau, also das ist auch eine ganz gute Aufteilung, diese fachliche und technische Konfiguration. Technisch in dem Sinne eben, da wäre ein Beispiel wie (?13:21). Das ist eher dann so die technische Konfiguration, die dann auch einmal festgelegt wird und dann dann Auswirkungen hat wie die Konsole aussieht. Die fachliche Konfiguration im Falle vom [Produkt] wäre dann eben sowas wie Datenbank, JMS-Queues, Email-Konfiguration, Log-Level und sowas in der Richtung. Damit habe ich — also ich ermögliche dass das jemand konfiguriert, aber ich benutze eigentlich in meiner täglichen Arbeit eher die technische Konfiguration.

R1: Kennst du Interaktionen zwischen fachlicher und technischer Konfiguration? Vielleich auch aus deinem früheren beruflichen Leben und wo es jetzt—?

I11: Ja, die gibt es sicherlich. Mir fällt jetzt auf die Schnelle kein gutes Beispiel dafür ein. Kann sein, dass ich auch da schon damit in Berührung gekommen bin. Also wenn ich jetzt so ein bisschen zurückblicke auf meine frühere Karriere als IT-Consultant, was wir halt oft gemacht haben — das ist eigentlich so das klassische in der Java-Entwicklung. Es wurden dann halt Properties-Dateien verwendet oder XML-Dateien. Es gab eine Zeit, da war XML sehr, sehr hip sage ich mal. Da hat sich jeder auf XML gestürzt und— aber letztendlich, es wurden halt versucht Dinge auszulagern aus dem Quellcode und entweder in Form vo Properties-Dateien oder in Form vo XML-Dateien, die dann in irgendeiner Art und Weise eingelesen wurden, ausgewertet wurden und entsprechend im Programm verarbeitet wurden. Aber so die Trennung zwischen technischer oder wie die interagiert haben diese technische und die fachliche Konfiguration, fällt mir jetzt kein gutes Beispiel ein.

R1: Wir unterscheiden noch öfters in der technischen Konfiguration auch noch so Infrastruktur-Konfiguration. Also sage ich mal in der Cloud ist und muss jetzt seine Ports definieren und sich eine Datenbank — und vielleicht noch die Entwicklerinfrastruktur, wie zum Beispiel mein CI/CD-Prozess konfigurieren, die Stages. Spielt das bei dir auch eine Rolle? Kennst du da vielleicht Interaktionen?

I11: Naja, also mit dem CI-Server habe ich weniger Kontakt. Also da gibt es Leute, die da entsprechend sich drum kümmern, dass das ganze am laufen bleibt, dass es eingerichtet ist. Ich habe für meinen Bereich, für meine Konsole habe ich drei, vier Buildkonfigurationen und die habe ich aus einem Template heraus selbst angelegt und verwalte die auch selber. Da geht es aber im wesentlichen darum, dass ich eben — ja, die muss man natürlich auch konfigurieren — da geht es im wesentlichen darum, dass ich bestimmte Dinge anpasse, wie zum Beispiel welche Maven-Goals möchte ich ausführen lassen. Auf welchem Rechner möchte ich das ausführen lassen. Also sollen das Windowsmaschinen sein oder Linuxmaschinen. Dann wie viel Prozent bestandene Unittests möchte ich haben, oder wie soll der (?16:31) sein. Solche Dinge werden da konfiguriert. Das ist dann für mich auch einfach so die Konfiguration des CI-Systems. Die nehme ich selber vor, ist aber da gibt es eben wie gesagt ein Template, das mir dann bestimmte Möglichkeiten fest macht verschiedene Dinge anzupassen.

R1: Also ist es dann schon vorkonfiguriert?

I11: Ein Teil ist schon vorkonfiguriert und einen Teil kann ich da noch selbst bestimmen.

R1: Hast du denn typischerweise auch mit Konfiguration eines monolithischen Systems zu tun? Oder sind die eher verteilt?

I11: Naja, so als monolithisches System habe ich eigentlich wenig zu tun. Das sind immer wieder einzelne Konfigurationsfragmente für die verschiedenen Bereiche. Aber monolithisch meinst du jetzt wahrscheinlich im Sinne von eine große Applikation, wo alles versucht wird zu konfigurieren. Das weniger. Monolithisch kann man vielleicht — also das einzige, was — monolithisch hört sich immer ein bisschen problematisch an, weil es gibt — man hat es ja auch nur unter dem Gesichtspunkt gesehen, dass es eben einheitlich ist, dass es eine Konfigurationsdatei gibt und das nicht verstreut ist über X verschiedene kleine Schnipsel. Und ja, man kann schon sagen [das Produkt] hat ja eine XML-Konfigurationsdatei. Die heißt standalone.xml und dort ist die komplette Konfiguration hinterlegt, das heißt der Benutzer guckt in diese Datei und findet dort entsprechend alle Einstellungsmöglichkeiten, die es gibt und kann dann dort die entsprechenden Einstellungen vornehmen. Oder er geht eben auf andere — diese Datei kann einmal händisch verändert werden, was die wenigsten heutzutage noch tun, sondern die meisten gehen dann bestimmt über bestimmte Werkzeuge und Tools. Das ist einmal, es gibt ein CLI für [das Produkt] oder es gibt die Adminkonsole und beide Tools verändern dann letztendlich die XML-Datei.

R1: Du hast jetzt gesagt da gibt es viele Konfigurationsschnipsel und so weiter. Ist das ein Problem oder sich (?18:42) oder sowas?

I11: Ja, manchmal kann Konfiguration sehr komplex sein. Vor allem wenn es dann, wenn man versucht es möglichst generisch vielleicht zu machen oder möglichst flexibel, versucht das möglichst flexibel zu gestalten. Ich denke da haben solche Systeme, wo versucht wird, dass man Konfiguration über verschiedene Schichten aufteilt und die eine Schicht überschreibt dann die andere und dann ganz zum Schluss kann man dann noch mal über die Kommandozeile eben noch mal was überschreiben. Also das erreicht dann manchmal so einen gewissen Grad an Komplexität, wo man dann nicht mehr genau weiß, wenn ich jetzt an einem Schalter irgendwas drehe, was passiert dann letztendlich? Was passiert denn mit meiner Einstellung? Wird die noch aktiv oder ist die noch aktiv? Oder wird die dann wieder durch Dritte oder durch einen anderen Mechanismus wieder zunichte gemacht und überschrieben? Also die Konfiguration sollte meiner Meinung nach möglichst einfach sein. Ein möglichst einfaches Format haben, das auch verständlich ist und was man gut lesen kann, was jetzt auch nicht nur für die Maschine gut lesbar ist, sondern auch noch für den Menschen gut lesbar und verständlich ist und möglichst wenig Indirektion bieten. Sprich in dem Sinne von man möchte ja nicht eine Art Programmiersprache erfinden für die Konfiguration, sondern Konfiguration sollte meiner Meinung nach immer noch letztendlich sehr, sehr simpel aufgebaut sein. Im einfachsten Falle, einfach Key-Value-Paare wie im Falle von einer Properties-Datei.

R1: In wie weit müssen denn die Tools, die ihr nutzt und die Frameworks und so weiter, Infrastruktur konfiguriert werden?

I11: Gut, die Infrastruktur die wird — wir haben halt im Wesentlichen diese CI-(?20:37), die wird aufgesetzt, die wird konfiguriert. Da habe ich jetz wenig Kontakt damit dazu, wie die — wie gesagt, es gibt ein paar Kollegen, die kümmern sich dadrum. Und da kann ich jetzt leider nicht so sehr viel dazu sagen wie das Ganze von statten geht oder wer da, was da genau im Einzelnen konfiguriert wird.

R1: Okay, aber bei jetzt in den Frameworks wie dieses GWT und so weiter, hat das irgendwelche Konfigurationsfiles und so weiter?

I11: Also wenn für die Entwicklung entsprechende Frameworks eingesetzt werden, dann liegt das erstmal in der Verantwortung des jeweiligen Entwicklers, der das entsprechend einsetzt. Also mein Vorgänger, von dem ich die Adminkonsole übernommen habe, der hat irgendwann entschieden das GWT ist ein Tool, das passt für die Entwicklung, hat das dann mit dem größeren abgesprochen oder vorgeschlagen. Das wird dann akzeptiert oder eben nicht. Im Falle — das liegt dann immer ein bisschen an dem jeweiligen Entwickler, wie gut er das vertritt oder welche Argumente er so erbringt. Im Endeffekt wird nach dem Prinzip verfahren, wenn es das richtige Tool für den richtigen Job ist, dann gibt es da erstmal keine Ausschlusskriterien an sich. Und dann muss halt gewährleistet sein, dass das Ding funktioniert. (?21:59) in welcher Form dann die Konfiguration stattfindet, was da genau verwendet wird, das bringt ja dann letztendlich meistens das Framework oder das Tool mit und da gibt es dann auch jetzt erstmal keine Ausschlusskriterien, wo man sagen würde, das geht jetzt aber nicht.

R1: Okay, wie würdest du denn den Stellenwert oder die Wichtigkeit von Konfiguration im Softwareengineering sehen?

R11: Ja, also sehr hoch auf jeden Fall. Also ohne Konfiguration geht es nicht meiner Meinung nach. Ich kann mir nicht vorstellen, dass man Software entwickelt, wo man wirklich überhaupt keine Möglichkeit oder keine Handhabe hat (?22:38) oder das ganze anzupassen über Konfiguration für den Entwickler, in welcher Form auch immer. Aber das wirklich alles im Code steht, das habe ich meiner Laufbahn und meiner Karriere eigentlich noch nie gehabt. Ich kann mir schon vorstellen, dass es sowas auch gibt, aber ich möchte da nicht in irgendeiner Art und Weise beteiligt sein.

R1: Gibt es eigentlich Unterschiede bezüglich des Stellenswerts von Konfiguration in den einzelnen Software-Lebensphasen? Also vielleicht wen du von Requirements bis zur Maintenance denkst.

I11: Ja, man sollte sicherlich schon relativ früh daran denken, dass man bestimmte Dinge konfigurieren möchte. Während der Planung sollte eigentlich relativ früh klar sein, dass man — oder man sollte halt immer so ein Gespür dafür haben oder einen Augenmerk darauf legen, wenn Anforderungen reinkommen und wenn man überlegt, wie man die Dinge umsetzt, dass man halt irgendwie so einen Augenmerk darauf legt und erkennt, das sind sind jetzt Dinge, die sind sinnvoll für eine Konfiguration oder, dass man die auslagert in eine Konfiguration und gleichzeitig aber auch umgekehrt, so ein bisschen Gespür dafür entwickelt, dass man auch Dinge auch mal festlegen darf. Also dass man Dinge eben nicht öffentlich durch Konfiguration, weil das ist vielleicht auch so ein Antipattern, was oft entsteht bei der Entwicklung, dass man versucht möglichst alles konfigurierbar zu machen, was dann den Effekt hat, dass man das Ding oder dass die Software dann einfach schlecht warten, pflegen und weiterentwickeln kann vielleicht. Also es gibt auch durchaus Dinge, die haben nichts in der Konfiguration zu suchen, sondern die sind nun einfach nun mal so. Und dann muss man die nicht letztendlich — beziehungsweise man muss dann halt entscheiden, was macht dann für den Endanwender wirklich konfigurierbar, was sind leicht — da sieht man wieder so die Grenze zwischen technisher und fachlicher Konfiguration, was sind Dinge, die man als Entwickler schon noch konfigurieren kann, aber die letztendlich — der Endanwender hat keinen Einfluss mehr darauf, diese Dinge zu konfigurieren.

R1: Wurdest du eigentlich während deines Studiums oder deiner Ausbildung darauf vorbereitet?

I11: Ne, gar nicht. Das Thema Konfiguration wurde eigentlich, wenn ich mich jetzt richtig erinnere, war kein Bestandteil von irgendeiner Vorlesung oder irgendeinem Fach. Also wie gesagt, ich habe an der FH studiert und da wurden eher so die klassischen Dinge gelehrt: Softwaredesign, Software-Architekturen. Ja, da bin ich dann auch — am Ende des Studiums habe ich zum ersten Mal so ein bisschen mit Java programmiert. Die Programmiersprachen, die wir vorher so ein bisschen gelernt haben, also C, C++, da waren eigentlich, war Konfiguration nicht so das wichtige Thema.

R1: Sollte das denn im Studium unterrichtet werden?

I11: Ich denke schon, ja, weil jede Art von Software wird irgendwie konfiguriert und es macht schon Sinn. Man kann das ja auch erstmal sehr allgemein halten, man muss jetzt nicht irgendwie speziell auf eine Programmiersprache und Toolkit oder Framework irgendwie quasi runterbrechen, sondern man — ja, genau so wie du jetzt vorhin gesagt hast. Es gibt ja immer Dinge, die man — die Konfiguration als allgemeine, ganz eigenes Thema, was das ausmacht, eben fachliche oder technische Konfiguration, verschiedenen Ebenen. Sowas sollte es schon meiner Meinung nach eben auch Teil der Vorlesungen des Studiums sein.

R1: Wie werden denn bei euch Konfigurationen vewaltet und dokumentiert?

I11: Letztendlich ist die Konfiguration auch ein Teil von dem Quellcode und im Wesentlichen wird, gelten dann ähnliche Dinge, die auch für Quellcode gelten. Das heißt das geht los damit, dass es versionsverwaltet wird. Es geht dann weiter damit, dass es vielleicht besitmmte Regeln gibt, in die so eine Konfigurationsdatei auf(?26:58) muss. Sprich, dass sie ein bestimmtes Format und Struktur hat. Also so wie man überprüfen kann, dass der Quellcode ein bestimmtes Format hat, also mit checkstyle oder ähnlichen Hilfsmitteln, kann man auch sicherstellen, dass eine Konfigurationsdatei ein bestimmtes Format hat, eine bestimmte Struktur hat. Oder vielleicht eine bestimmte Länge und Größe nicht überschreitet. Ein Beispiel habe ich ich jetzt in meinem Projekt jetzt keiner, aber ich kann mir vorstellen, dass es in anderen Projekten [hier] durchaus sowas gibt und sowas überprüft wird auch. Und dann geht es natürlich auch weiter damit, dass man auch Konfigurationsdateien in irgendeiner Art und Weise testet. Ja, in meinem konkreten Fall, in meinem Projekt, die Konfiguration (?27:46), ich habe eben fachliche Konfiguration, aber (?27:51) Konfiguration, gut die wird versionsverwaltet. Damit hört es dann bei mir in meinem Projekt dann eigentlich auch schon auf.

R1: Okay, was ist denn der größte Vorteil von dieser Art der Verwaltung?

I11: Ja, das kommen dan einfach die grundlegenden Vorteile von einer Versionsverwaltung zum tragen. Sprich ich kann mir anschauen, was habe ich denn in Version Xzy, was stand denn da drin und vorallem dann das hilft natürlich bei der Fehlersuche, wenn jetzt irgendwas nicht funktioniert, was aber letzte Woche noch funktioniert hat, dann guckt man sich die Änderungen eben an und sieht dann, eine der Änderungen war in der Konfigurationsdatei und dann, da haolt man sich den Stand von letzter Woche, spielt das Ganze noch mal durch und merkt dann häufig relativ schnell, wo der Fehler liegt und der kann natürlich auch in einem geänderten Konfigurationswert oder an einer Änderung an der Konfiguration liegen.

R1: Und der größte Nachteil?

I11: Jetzt für die Versionverwaltung von Konfiguration oder Konfiguration im Allgemeinen.

R1: Ne, von der Versionsverwaltung. Also so wie ihr das verwaltet habt.

R1: Ehrlich gesagt, tue ich mich schwer große Nachteile zu finden. Also ich arbeite schon sehr, sehr lange mit Versionsverwaltungen. Man kann dann — weil es gibt halt gute und schlechte Versionsverwaltungen. Angefangen hat das ganze mit CVS, was funktioniert hat, aber was viele, viele Probleme hatte und seitdem ich jetzt, ja seitdem ich [hier] arbeite, arbeite ich mit Git und so weiter und das ist im Vergleich zu allem anderen, was vorher war, ein Meilenstein und das ist sehr, sehr gut bei (?29:45) und man hat unendlich viele Möglichkeiten und das ist ein sehr mächtiges Werkzeug, was man an die Hand bekommt und da gibt es eigentlich — der einzige Nachteil, wenn man es so will, es ist halt recht komplex, aber man muss halt wissen, was man tut und wenn man nicht weiß, was man tut, dann muss man sich eben kundig machen oder ein bisschen sich da reinknieen und reinarbeiten. Und es gibt unendlich viel Dokumentation darüber. Von daher sehe ich jetzt wenig Nachteile.

R1: Auch speziell für Konfiguration speichern dann?

I11: Ja, genau also ich wüsste nicht wieso man die Konfigurations — wenn das, also wenn man die Konfiguration im Sinne von einer Datei vorliegen hat und es stehen jetzt da keine unternehmenskritischen Daten drin, das ist natürlich dann immer noch ein Aspekt zu sagen, was ist denn da in dieser Datei enthalten. Es mag durchaus Fälle geben, wo man sagt, diese Dinge gehören nicht in eine Versionsverwaltung. Dann muss man sich überlegen wie löst man dieses Problem. Kann man auch unterschiedlich angehen. Dass man halt die Konfiguration aufteilt in Dinge, die jeder sehen darf, das kann dann wiederum in die Versionsverwaltung und Dinge, die dann wirklich unternehmenskritisch sind oder auch sensitive Daten, die sollte man dann nicht in die Versionsverwaltung einchecken.

R1: Also ihr habt jetzt wahrscheinlich keine kritischen, weil ihr habt keine extra Tools, oder?

I11: Haben wir eigentlich, da wir mit Opensource arbeiten und letztendlich jede Zeile Code, die wir schreiben, dann irgendwo auf GitHub wiederzufinden ist, gibt es sehr wenige Dinge, die wirklich geheim sind oder die dann nicht öffentlich gemacht werden können. Das mag jetzt im Falle von [meiner Firma] und meinem Projekt schon ein Sonderfall sein. Ich kann mir durchaus vorstellen, dass es, wenn ich jetzt an früher zurückdenke, dann gibt es natürlich sehr, sehr oft Dinge, die nichts in der Versionsverwaltung zu tun haben und dann wird es dann schon kritisch und dann muss man sich genau überlegen, was macht man damit. Also wie löst man dieses Problem. Dieses Problem ist so ein bisschen aus meinen Augen, aus meinem Fokus verschwunden.

R1: Wie werden denn bei euch Konfigurationen im Team kommuniziert?

I11: Das ist im wesentlichen, gibt es da Absprachen. Also wenn ich jetzt an Konfiguration zum Beispiel von dem Application-Server denke, diese Konfiguration, die wächst ja ständig, aber die verändert sich auch ständig mit jedem neuen Release und mit jeder neuen Version oder jedes neue Feature, was entsprechend hinzugefügt wird, wächst auch die Konfiguration oder die ändert sich dann auch. Und es geht eigentlich damit los, dass man so ein neues Feature plant, dass man dann letztendlich ein kleines Dokument darüber schreibt und das ist meistens irgendwas, was auch wiederum auf GitHub verwaltet wird. So ein kleines AsciiDoc-Dokument wird dann erstellt. Das wird dann entsprechend im Team besprochen. Es gibt regelmäßige Teammeetings. Beziehungsweise der Link wird dann halt rumgeschickt, jeder kann sich den anschauen, durchlesen und kommentieren und letztendlich irgendwann kommt man zum Schluss, wo man sagt ja genau so möchte ich es umsetzen und diese Umsetzung oder dieses kleine Designdokument, bei uns nennt sich das Analyse-Dokument, beinhaltet dann auch letztendlich die neuen Konfigurationswerte, die man einführen möchte. Oder im Falle von wenn man etwas ändern möchte, dass sich bestimmte Dinge fallen aus der Konfiguration weg, neue kommen dazu, es wird etwas umbenannt, letztendlich die Änderung an der Konfiguration. Und damit ist es eigentlich letztendlich bekannt, also weil jeder im Team kennt dieses Dokument. Für mich bedeutet das dann im konkreten Fall, ich weiß jetzt okay, da kommen neue Konfigurationswerte hinzu, das heißt ich muss die Adminkonsole entsprechend verändern, damit diese Konfigurationswerte überall von dem Nutzer dann entsprechend auch wieder angepasst werden können.

R1: Was ist denn der größte Vorteil davon, von der Art?

I11: Der größte Vorteil davon ist, dass es erstmal sehr, für mich ist es ein sehr leichtgewichtiger Prozess, aber ein sehr einfacher Prozess. Man beschränkt sich auf das Wesentliche, es ist kein riesen Workflow dahinter. Es gibt da auch wieder ein eigenes GitHub-Repository für diese Dokumente. Das heißt wenn jemand etwas Neues plant, dann stellt er einen Pull-Request an dieses GitHub-Repository. Jeder weiß, wie es zu bedienen ist, jeder weiß wo es steht. Es ist jetzt nicht ein Anhang in einer Email, die irgendwo an einen Verteiler geschickt wird, ich aber nicht Teil dieses Verteilers bin und dann die Information nicht habe und dann wird aber dieses Dokument verändert und als Anhang wieder weiter geschickt und keiner weiß in welcher Version jetzt welches Dokument gültig ist. Da gibt es zahllose Beispiele, wie es nicht funktionieren kann. Also ich muss sagen, dieses Verfahren, was es bei [uns] oder was bei mir im Team verwendet wird, funktioniert eigentlich sehr gut. Wir versuchen möglichst viel, wenn wir Dokumente oder wenn wir irgendwie Spezifikationen oder dergleichen haben, dass letztendlich irgendwo, entweder in GitHub abzulegen oder auf Google Docs abzulegen, aber nicht auf irgendjemandes Festplatte oder irgendjemandes Email-Attachment.

R1: Okay und der Nachteil? Gibt es da auch Nachteile?

I11: Ein Nachteil mag sein, dass es halt ein bisschen gewöhnungsbedürftig ist. (?35:38), dass man wissen muss, wie die Dinge funktionieren und — ich tue mich ein bisschen schwer da Nachteile zu finden. Ich kenne auch ein anderes Vorgehen eben aus meiner Arbeit als IT-Consultant, wo versucht wurde eben, ja, irgendwie auch ein File-Share, irgendwie eine Dokumentenstruktur aufzubauen. Das hat dann mal funktioniert, hat dann mal nicht funktioniert, weil dann jeder hat eine andere Verzeichnisstruktur dann plötzlich aufgebaut und dann wurden die Dokumente doch wieder in zwei verschiedenen Versionen irgendwo. Da lagen die Dinge dann drin. So eine Versionsverwaltung dafür zu benutzen macht eigentlich Sinn, weil es gibt dann halt einfach nur einen Ort, wo das Ding liegt. Von daher, Nachteile gibt es eigentlich wenige. Der einzige mag sein, dass man einfach alle davon überzeugen muss damit zu arbeiten. Im Falle von den Kollegen und von meinem Team sind alle davon überzeugt, da gibt es keinen der querschießt. Wenn man natürlich in einer Firma ist, wo es einfach unterschiedliche Vorlieben gibt sage ich mal und vielleicht gibt es den ein oder anderen Querullanten, der halt quer schießt, dann man das ein Problem sein, aber da muss man einfach, muss man als als Management oder als Organisation dafür sorgen, dass das einfach funktioniert.

R1: So ein bisschen hast du es glaube ich schon gesagt, als in Code-Reviews werden auch Konfigurationsdateien gereviewt bei euch?

I11: Ja genau, das ist also Teil von dieser, wenn ein neues Feature, wenn sowas entsprechend geplant wird, ist auch so eine Art Review. Das heißt einer schreibt dieses Dokument. Weil dieses Dokument hat dann eben den Einfluss auf die Konfiguration. Also wie sich das ganze entwickelt oder wohin die Reise geht und die werden auch gereviewt. Das heißt das lesen sich dann die Leute durch. In meinem Fall, wenn ich jetzt zum Beispiel sehe, dass das zu Problemen führen könnte, wenn ich dieses Feature in der Konsole umsetzen muss, dann kommentiere ich eben entsprechend im Dokument bei dem Pull-Request und dann hat eine Diskussion zur Folge und dann geht es in die eine oder andere Richtung, das ist dann auch entsprechend offen. Aber jeder hat die Möglichkeit auf jeden Fall seine Meinung zu sagen, also Einfluss drauf zu nehmen. Letztendlich liegt es dann trotzdem noch hauptsächlich in der Entscheidung desjenigen, der das umsetzen würde, aber in der Regel hat der auch ein offenes Ohr und ist dann auch gewillt entsprechend (?38:17).

R1: Jetzt hast gesagt, es sind jetzt nicht so viele Konfigurationsoptionen bei dir selber drin, aber du machst die jemand anderes sich ausgedacht ja praktisch sichtbar für den Endnutzer. Weißt du nach welchen Kriterieren und zu welchem Zeitpunkt Optionen denn geplant oder implementiert sind? Also du hast es ja schon ein bisschen vorhin mal angerissen, man sollte nicht immer Optionen reinmachen, aber was sind denn die Kriterien neue Optionen zu planen und zu implementieren?

I11: Das ist eine schwierige Frage, ja das ist, weil das nämlich sehr, sehr vom Einzelfall und vom Usecase abhängt. Ja, ich würde mal sagen, naja, es ist wirklich eine schwierige Frage, also es gibt ganz offensichtliche Dinge, da macht es Sinn da einfach die als Konfigurationsparameter an der Hand zu haben. Sowas wie Loglevel zu setzen braucht man ja eigentlich in der Regel bei jeder Art von Anwendung, das ist so ein ganz klassisches Beispiel. Man möchte in einer Anwendung, wenn man merkt irgendwas läuft nicht rund, dann möchte man ja eine Möglichkeit haben irgendeine Art von Analyse zu betreiben. Analyse kann jetzt vielfältig sein. Eine Möglichkeit der Analyse ist dann eben den Loglevel zu ändern und plötzlich ganz viel mehr an Dingen zu sehen, was passiert. Und gerade in meiner Anwendung in der Logdatei. Das ist so ein ganz klassisches Beispiel, was man die Applikation irgendwie an der Hand haben sollte. Und sowas muss man dann eben konfigurieren können, über Kommandozeile, über Konfigurationsdatei, wie auch immer.

R1: Wenn du in Richtung denkst, was sind Gründe für Konfigurierbarkeit?

I11: Ja, also Gründe für Konfigurierbarkeit sind zum einen eben, was ich jetzt gerade als Beispiel genannt habe, so die Analyse von einem Programm zur Laufzeit. Dann gibt es natürlich — eine andere Art für die Konfiguration ist so die Infrastruktur aufzubauen. Also da heißt wenn meine Applikation mit irgendwelchen anderen Systemen kommuniziert, dann muss man die Möglichkeit haben zu sagen wie sieht die Konfiguration aus. Sprich man gibt Hostnames, Ports, URLs oder dergleichen an. Und dann gibt es noch eine andere Art der Konfiguration, die geht dann mehr in den Bereich persönliche Vorlieben. Das heißt möchte ich lieber einen grünen oder einen blauen Hintergrund haben. So eine Art persönliche Einstellungen. Wie viele Einträge möchte ich in einer Liste haben. Ich möchte 20 haben und der andere möchte aber vielleicht 100 haben auf einmal. Das sind so die Userkonfigurationen, ja so diese Preferences-Settings.

R1: Wie viel Aufwand betreibst du denn in der Entwicklungszeit um Konfigurationsoptionen einzubauen?

I11: Ja, das hält sich jetzt in meinem Fall sehr in Grenzen. Es gibt in meinem Fall jetzt was den Endanwender angeht tatsächlich sehr, sehr wenige Optionen. Also ich kann eben in der Konsole einstellen zum Beispiel wie viele Einträge möchte ich in der Liste haben. Oder ich kann die Sprache einstellen. Ich kann einstellen — im wesentlichen sind es tatsächlich nur vier, fünf Sachen, die ich einstellen kann in der Konsole. Also jetzt was den Endanwender angeht. Das sind sehr, sehr wenige Dinge und die werden in meinem Fall dann eigentlich als Cookie beziehungsweise im Browser, im Local Storage werden die Dinge dann festgehalten. Das heißt ich verwende ja auch sehr wenig Zeit mich mit Konfiguration auseinanderzusetzen. Ich sage mal 90 % der Zeit, die verwende ich eigentlich wirklich dazu fachliche Dinge umzusetzen. Und bei dieser Umsetzung spielt die Konfiguration immer nur einen sehr geringen, kleinen Teil.

R1: Wenn mal denkt, also Greenfield-Ansatz, also muss initial mal eine Software einrichten mit den Tools, mit den Frameworks, mit der Infrastruktur für das Deployment und so weiter, was würdest du denn da schätzen, was so der Aufwand ist bezüglich Konfiguration?

I11: Also jetzt in meinem Fall, also für meine Anwendung. Wenn man jetzt jemanden hinsetzt und sagt, dass er in der Lage ist diese Software zu bauen und so zu erzeugen, da würde ich jetzt mal optimistischerweise sagen, ich setze es mal voraus, dass der derjenige sich mit Java-Entwicklung, mit GitHub und entsprechend mit Maven auskennt, dann sind das eigentlich im Bereich von Stunden würde ich da jetzt mal behaupten spielt sich das ganze ab. Also es gibt in meinem Fall gibt es einen, weil das habe ich als ein neues Teammitglied hinzu kam, der jetzt dann wieder das Team verlassen hat leider, da habe ich mich hingesetzt und habe mal eine kleine Beschreibung geschrieben, welche Schritte nötig sind, welche Voraussetzungen es gibt. Im Wesentlichen geht es damit los, dass ich das GitHub-Repository auschecke, dass ich einen Maven-Build anstoße und ich muss nicht viel konfigurieren, weil wie gesagt für die Konfiguration ist es nicht viel, da ist nicht viel nötig. Von daher—

R1: Was ist, wenn du jetzt sagen wir mal nicht diese Art von Team hättest und jetzt wirklich von einer grünen Wiese aus starten würdest in einem Projekt und dann auch den Buildprozess aufsetzen müsstest.

I11: Ja gut, dann wäre das natürlich schon ein bisschen komplexer und ein bisschen umfangreicher. Dann wären wir vielleicht schon, würden da schon mehrere Tage ins Land gehen, aber das ist auch was, was mir innerhalb von [meiner Organisation] eigentlich, habe ich es noch nicht anders erlebt, dass man dadurch, dass viele Dinge einfach auf GitHub verfügbar sind, dass viele Dinge auch Open-Source und öffentlich zugreifbar sind, da liegt es in der Natur der Sache, dass man einfach schnell oder schnell Dinge dann vom auschecken bis zur fertigen Software haben möchte. Weil viele Repositorys werden ja öffentlich geklont, also sind dann jeder will sich das mal anschauen. Und auch [die Software] selber, der ja noch das große Ganze, also mein [Projekt] ist ein Baustein, der da mit einfließt, aber [die Software] selber hat ja noch mal ein Vielfaches an Clientside-Code. Auch da ist es sehr einfach. Das ist ja auch Teil meiner täglichen Arbeit. Wenn eine neue Version rauskommt, dann hole ich mir die und baue mir die damit ich lokal damit testen kann und das ist im Wesentlichen auschecken, Maven-Build anschmeißen und benutzen.

R1: Wie viel Aufwand betreibt ihr denn von Versionsänderungen, die konfigurationsabhängige Änderungen verursachen. Also wir haben mal so ein Beispiel, Spring Boot 1 auf 2. Da gab es irgendwie massive Änderungen an den Konfigurationsdateien. Habt ihr da auch Aufwand?

I11: Ja, das ist natürlich schon, das ist wichtig, dass die Konfiguration, also so wie eine API abwärtskompatibel sein sollte. Über gewisse Versionszyklen hinweg, sollte natürlich auch eine Konfiguration abwärtskompatibel sein. Das gelingt nicht immer, aber es — manchmal muss man auch, gibt es auch Brüche. Eine Möglichkeit, wie wir das gelöst haben, das hat ein Kollege gemacht, es gibt so eine Art Transformationsprozess oder so einen Automatismus, der versucht alte Konfigurationen zu transformieren, damit das auf den neuen Versionen wieder lauffähig ist. Und manchmal hat man eben diese Brüche mit drin und dann möchte man das nicht alles händisch umstellen müssen, sondern dann gibt es eben so einen Automatismus um die alte Konfiguration in die neue zu überführen. Das ist ein Ansatz, wie wir das Ganze lösen.

R1: Ja, was ist denn für dich, nach deinen ganzen Erfahrungen, der größte Faktor, der den Konfigurationsaufwand bestimmt? Also jetzt generell gesehen.

I11: Ja, zum einen was ganz am Anfang steht und was halt einfach wichtig ist, denke ich mal, zu erkennen, was möchte ich konfigurierern, was lohnt sich oder was ist sinnvoll, sagen wir mal so, zu konfigurieren. Das ist wahrscheinlich einfach eine der schwierigsten Aufgabenstellungen und Herausforderungen zu erkennen oder zu bestimmen, was Sinn macht zu konfigurieren und was nicht Sinn macht zu konfigurieren. Und da gibt es halt leider kein Patentrezept oder keine Lösung dafür, sondern das hat viel mit dann Erfahrung zu tun, mit so ein bisschen Gespür zu tun und mit diesem Verhalten steht und fällt vieles oder das hat ja dann Auswirkungen auf das, was dann später entsteht. Und das ist so der wichtigste Aspekt denke ich mal bei dem Ganzen. Und da gibt es wie gesagt wenig, da gibt es jetzt kein Schema F oder kein Dokument, das man sich durchliest und dann weiß man, wie es geht, sondern das ist nun mal einfach so die Aufgabe der Softwareentwicklung oder das ist Teil der Softwareentwicklung.

R1: Dann wäre jetzt so ein Konfigurationseditor ja implementierst in praktisch, weißt du denn ob deine Nutzer, wissen was Sinn macht und was nicht vielleicht?

I11: Das denke ich jetzt mal, also ich möchte jetzt meinen Benutzern nichts absprechen, aber ich glaube jetzt nicht, dass sie jetzt wissen, was Sinn macht und was nicht Sinn macht. Das ist dann im meinem Fall, von dieser Adminkonsole ist es halt so die Frage, wie präsentiere ich die Konfigurationsmöglichkeiten der Benutzer in einer Art und Weise damit es möglichst einfach ist für die Benutzer letztendlich Dinge zu konfigurieren. Also das hat dann viel auch so ein bisschen mit Userinterface zu tun und mit Informationsarchitektur — wie führe ich die Benutzer durch einen Prozess, damit sie möglichst schnell Dinge konfigurieren können. Ein Beispiel ist zum Beispiel wenn ich eine neue Data-Source einrichte, dann muss ich eben bestimmte Dinge zwingend angeben. Das ist eben die JDBC-URL, das ist der Treiber, Username, Passwort und solche Dinge. Dann gibt es aber auch Dinge, die optional sind. Zum Beispiel Connection-Pooling, wie viele Connections möchte ich gleichzeitig haben, wie groß soll mein Pool sein, wie schnell soll er wachsen und so weiter und sofort. Und dann gibt es eben unterschiedliche Möglichkeiten, wie ich dem Benutzer das präsentiere. Ich kann natürlich ein riesen Formular haben, das ich durchscrollen muss, da sind meinetwegen die ganzen Konfigurationsparameter alphabetisch gelistet und ich muss mir dann durchscrollen bis ich dann unten bei Username bin um das ganze einzutragen. Ich kann es natürlich auch so machen, dass ich einen Wizard habe, der hat drei Schritte und da werden die wesentlichen Dinge abgefragt, die thematisch gegliedert sind. Da kommt 1, 2 dann 3 und dann kann ich zum Schluss testen, das funktioniert. Und wenn ich dann das Connection-Pooling einstellen möchte, dann gehe ich nach der Einrichtung dorthin und sehe dann auch wieder entsprechend thematisch sortiert die Einstellungsmöglichkeiten, die ich habe und dann kann ich auch alle anzeigen. Sprich, also was ich damit sagen möchte ist, es kommt dann irgendwie darauf an, wie präsentiere ich das dem Benutzer, die Konfigurationsmöglichkeiten, die er hat. Und da kommt es halt sehr darauf an, dass ich das in einer vernünftigen Art und Weise mache.

R1: Habt ihr eigentlich auch eine Möglichkeit oder ein Logging eingebaut um zu wissen, was der Nutzer überhaupt bei euch konfiguriert und was nicht?

I11: Ja genau, die Möglichkeit haben wir. Ich habe über Google Analytics kann ich dann nachvollziehen, welche Seiten meiner Anwendung entsprechend aufgerufen wurden, von wem die aufgerufen wurden. Das heißt das ist was, was bei dem Open-Source-Produkt, also wenn ich [die] benutze und die Adminkonsole aufrufe, dann ist es standardmäßig eingeschaltet. Das ist zum Beispiel eine Einstellung, die der Benutzer vornehmen kann. Er kann dieses Google-Analytic-Tracking auch ausschalten, aber standardmäßig ist es an. Und bei dem Produkt, bei dem EAP, ist es standardmäßig ausgeschaltet und der Benutzer könnte es dann, wenn er es möchte einschalten. Und sobald es aktiv ist, wird eben alles aufgezeichnet. Sprich also ein Google-Analytics-Tracking, was man bei vielen Webseiten kennt. Dann kann ich eben auch auf die, zu dieser Google-Analytics-Seite gehen und sehe dann, welche Seiten wurden von wem aufgerufen, wie lange, aus welchem Land, mit welchem Browser und diese ganzen Daten habe ich dann zur Verfügung.

R1: Nutzt ihr diese Datein eigentlich auch um herauszukriegen, diese Option wird nie angefasst, die könnte man eigentlich mal rausschmeißen und so weiter?

I11: Ja, genau. Das ist so Sinn und Zweck des Ganzen. Ich möchte halt sehen, was wird denn vor allem benutzt. Vor allem benutzt wird jetzt im Falle von der Adminkonsole Dinge wie Deployment, Datasources ist so ein typischer Usecase. Dann gibt es natürlich andere Dinge, die sehr, sehr wenig und sehr, sehr selten benutzt werden. Ich muss sie aber trotzdem vorhalten, weil die Adminkonsole hat halt ihren Anspruch, dass es die Konsole sein soll, wo ich letztendlich jede Einstellungsmöglichkeit, die es gibt auch tatsächlich umsetzen kann. Sprich, ich kann es jetzt nicht herausnehmen aus der Konsole, aber es ist natürlich interessant für die Fragestellung wo platziere ich denn die verschiedenen Optionen oder wo findet der Benutzer was. Also Dinge, die oft verwendet werden, sollen natürlich jetzt möglichst nicht versteckt werden, sondern sollten prominent irgendwo dem Benutzer ins Auge fallen. Und Dinge, die ich nicht so oft verwende, kann man dann irgendwo in einer Menüstruktur womöglich entsprechend ablegen. Dafür sind diese Daten sehr, sehr sinnvoll und dafür nutze ich die dann auch.

R1: Spielst du diese Daten dann auch an die Entwickler zurück, die dann Optionen eingebaut haben von vor drei Jahren meinetwegen und immer der Default gelassen wurde?

I11: Ne, das meine ich nicht. Sondern ich gucke da immer wieder mal rein und es ist dann auch interessant zu sehen, welche Versionen der Konsole wird gerade verwendet von wie vielen Leuten. Also es ist dann auch vor allem für mich interessant, wenn ich eine neue Version veröffentliche, zu sehen wie schnell wird die letztendlich verwendet.

R1: Benutzt ihr eigentlich Konfigurierbarkeit auch um nicht-funktionale Eigenschaften, wie Performance zu tunen?

I11: Ja, also in meinem Falle jetzt nicht, aber ich weiß, dass der [Server], da wird es dann schon verwendet, da gibt es dann aber eher, das sind dann halt so technische Parameter oder Kommandozeilenparameter. Oder Einstellungen, die die JVM betreffen, was jetzt nicht in unserem Verantwortungsbereich liegt, aber das wird schon verwendet um auch performancekritische Dinge zu addressieren. Also es gibt ein Team soweit ich weiß, mit dem habe ich aber wenig zu tun, die machen eigentlich nichts andere wie Performance zu testen. Verschiedene Setups haben die zur Hand und testen dort letztendlich Performance vom [Projekt] und das wird auch sehr implizit betrieben. Also jede neue Funktion wird meines Wissens auch irgendwann mal, ist Teil von so einem Performancetest. Weil man natürlich verhindern möchte, dass man, wenn man baut ein neues Feature ein und das hat zur Folge, dass der ganze Server oder das ganze Ding dann auf einmal stillsteht. Dafür sind dann diese Performancetests nötig und da gibt es soweit ich weiß ein Team dafür, die sich darum kümmern.

R1: Stellt die Konfiguration von irgenwelchen Systemen, Tools, Infrastruktur vor Probleme?

I11: Ja, oft ist es schwierig Fehler, die verursacht von einer Konfiguration, also die von einem Konfigurationsfehler verursacht sind, erstmal aufzufinden. Das liegt so ein bisschen an der Natur der Sache, weil Konfiguration ist jetzt kein Code im klassischen Sinne. Wenn ich irgendwo einen Fehler im Code habe, dann fällt mir das entweder auf, weil das tatsächlich ein Syntaxfehler ist, dann sehe ich das in meiner IDE oder sehe das im Maven-Build, da ist irgendwas falsch. Wenn ich einen Buchstabendreher in der Konfiguration habe, dann wird sich da kein Compiler drüber beschweren, sondern das flutscht einfach durch und ich muss dann halt irgendwie später erkennen oder herausfinden, dass der Username, dass da irgendein Buchstabe fehlt. Das liegt einfach so ein bisschen in der Natur der Dinge und das hat jetzt Konfiguration, welches Format sie auch immer verwendet, also wenn das eine externe Konfigurationsdatei ist, dann ist es erstmal einfach ein Problem, dass Fehler, die da drinstehen einfach erstmal schwerer zu finden sind, wie jetzt Fehler, der durch Code verursacht wird.

R1: Wie unterscheiden sich denn Konfigurationsfehler von normalen Bugs?

I11: Ja, sie sind in der Regel einfach schwerer zu finden. Hängt dann auch ein bisschen vom Format der Konfigurationsdatei oder welches Format man da verwendet, welches System man da verwendet. Da gibt es meiner Meinung bessere und schlechtere Konfigurationsdateien. Aus meiner Erfahrung heraus komme ich mit Properties-Dateien einfach am besten klar, weil das ein sehr simples Prinzip ist und sehr einfaches Prinzip ist. Da gibt es Key und Value und das funktioniert eigentlich in der Regel ganz gut. Je komplexer das ganze ist, umso schwieriger finde ich das ganze. Also geht dann weiter, wenn man XML hat, kann man noch eine gewisse Struktur erkennen und mag ganz gut sein, (?58:11) JSON, was auch noch ganz lesbar ist, weil es noch ne (?58:16) Struktur ist. Mit solchen Formaten wie YAML komme ich jetzt persönlich nicht so gut klar. Ich bin es halt noch nicht ganz gewohnt, aber ich tue mich auch schwer da eine gute Struktur drin zu erkennen und gerade jetzt im Bereich von Kubernetes, OpenShift und dergleichen wird sehr, sehr viel in YAML-Dateien letztendlich ausgeladert und das ist was, was mich manchmal wundert, dass die Dinge noch so gut laufen, weil es eigentlich fast alles irgendwie irgendwo in einer YAML-Datei liegt und, ja ich möchte nicht derjenige sein, der diese ganzen YAML-Dateien letztendlich pflegen muss und bearbeiten muss und da sehe ich sehr, sehr viel potential drin, dass sich auch Fehler einschleichen. Weil meines Wissens gibt es da kein — beim XML habe ich immer noch sowas, wie ein Schema vielleicht, das dahinter liegt. Das mir dann sagt okay, da sind aber nur Zahlen erlaubt und du gibst da einen String. Oder da dieses Tag kann nur die und die Kinder haben, aber dieses Element ist einfach falsch strukturiert. Bei YAML habe ich sowas glaube ich gar nicht. Also ich wüsste nicht, wie das — weiß ich nicht, ob es sowas gibt. Das heißt, also wenn Konfiguration, dann möglichst simpel und möglichst verständlich, entweder als Properties-Datei oder dann halt mit ein bisschen Möglichkeit das ganze auch zu überprüfen, wie eben im Falle von XML.

R1: Was ist denn so mit der schwerwiegendste Konfigurationsfehler oder das schwerwiegendste Konfigurationsproblem gewesen an das du dich vielleicht erinnern kannst? Also schwerwiegend könnte sein seits Anspruch bis das gefixt ist, oder was Auswirkungen hatte auf—

I11: Ja, das sind sicherlich so ganz einfache und einfache Dinge. So ein konkretes Beispiel fällt mir jetzt glaube ich nicht ein, aber ich meine mal, dass man einfach so ganz blöde Fehler drin hat wie, dass man mehrere Konfigurationsdateien hat, eine für Staging, Development und Produktion womöglich und man zieht halt immer ständig die falsche an. Ändert Werte in der Staging-Umgebung und wundert sich, dass nichts passiert. Wobei man dann halt wiederum beim Start des ganzen Systems sagt verwende bitte die Development-Konfiguration, man ändert aber ständig in der Staging und wundert sich, dass nichts passiert. Das ist so ein typischer Fehler, der mir auch schon häufig unterlaufen ist. Das ist dann halt, man hat ja mehrere Dimensionen der Konfiguration und ändert halt nur eine Dimension, fasst die andere aber nicht an. Oder dann einfach ganz simple Dinge, dass man halt irgendwo einen Buchstabendreher drin hat oder, dass man eine Zeile auskommentiert in der Konfiguration, sich dessen aber nicht mehr bewusst ist und man erwartet einen bestimmten Wert, der dann aber nie da ist, weil die Option einfach deaktiviert ist. Das sind so typische Probleme, wo man dann oft das nicht sieht und erst vielleicht am nächsten Tag dann, wenn man wieder irgendwie so klaren Kopf hat, das dann auf einmal so ein Augenöffner ist. Wo man sich dann denkt „Oh man, ich suche hier seit Stunden irgendwie rum und das ist ganz einfaches Ding letztendlich.”

R1: Was sind die Ursachen für diese Probleme? Man hat keine Validierung?

I11: Genau. Ja, also ich glaube viele der Ursachen liegen so ein bisschen in der Natur der Sache, dass einfach Konfigurationen nicht so klar strukturiert oder nicht so weniger (?1:02:21) wie jetzt echter Programmcode. Beim echten Programmcode kann natürlich sowas auch passieren, aber nicht so oft und nicht so einfach, weil es da einfach mehr Möglichkeiten gibt Dinge zu überprüfen. Auch schon während der Buildzeit letztendlich Dinge zu überprüfen. Vielleicht ist das auch eine Möglichkeit das Problem zu addressieren, dass man vielleicht versucht Konfiguration auch Teil des Buildprozesses, auch als Teil des Builds versteht. Wenn man es schafft irgendwie beim Bauen der Software schon die Konfiguration zu validieren oder entsprechend zu überprüfen dann hilft das diese Fehler zu vermeiden. Alles, was möglichst früh in dem Prozess stattfinden kann, Validierung, Überprüfung und ?1:03:18) letztendlich hilft, denke ich mal, diese Art von Problemen zu lösen.

R1: Jetzt baust du ja auch so einen Konfigurationseditor. Validierst du eigentlich da auch die Werte, die der Nutzer eingibt?

I11: Ja, es gibt da entsprechend eine Überprüfung. Also das ist Teil der Konfiguration oder sagen wir mal, das ist ein Teil von der Metakonfiguration. Jede Konfigurationseinstellung i[n der Software] hat einen bestimmten Datentyp und kann auch bestimmte Regeln beinhalten. Zum Beispiel, wenn ich irgendwie das Connection-Pooling, wenn ich im Connection Pooling angebe wie viele maximale Connections möchte ich haben, dann ist das erstmal eine Zahl und kein String, dann hat das eine bestimmte Range. Das geht von 1 bis 100. Und diese Dinge sind auch Teil — es gibt so eine Art Management-Modell und das heißt eine Konfigurationseinstellung besteht nicht nur aus dem Namen der Konfigurationseinstellung, sondern da hängt auch noch mehr dran, wegen Datentyp, eine Validierung womöglich oder woher kommt dieser Konfigurationswert, also gibt es Querbeziehungen zu anderen Konfigurationswerten. Und diese Daten und diese Informationen nutze ich wenn ich meine Oberfläche aufbaue, dass ich dann entsprechend auch jede Eingabe überprüfen kann.

R1: Kennst du ein besonders schwer zu konfigurierendes Tool oder Framework und warum genau das?

I11: Ja, ein Beispiel ist halt Kubernetes, wo ich mich ein bisschen schwer tue mit diesen ganzen YAML-Dateien da Herr zu werden. Ich erkenne da keine Struktur dahinter. Also ich habe jetzt nicht so das Problem mit der YAML-Datei an sich, sondern mit den vielfältigen Konfigurationsdateien. Vielleicht arbeite ich auch noch zu wenig mit Kubernetes, aber ich erkenne da momentan noch kein Muster. Ich lese dann immer Codebeispiele und versuche das zu verstehen, aber und versuche dann immer ein Muster zu erkennen, dass sich Dinge ähneln, weil wenn man dann so ein Prinzip dahinter sieht, dass es immer nach Schema F läuft. Aber es gibt da so — also zumindest kommt es mir so vor — so unzählige Arten und Varianten und Versionen und Möglichkeiten Dinge zu konfigurieren. Ich sehe dann einfach immer nur noch es wird eine Ebene eingerückt, dann kommen ein paar Striche und eine Liste von irgendwas, aber was kann ich jetzt da reinschreiben? Kann ich da irgendwie irgendeinen beliebigen Wert reinschreiben? Also da tue ich mich sehr schwer sowas zu konfigurieren. Ja, da komme ich wesentlich besser klar mit irgendwie, mit einer Properties-Datei, wo ich weiß, okay und dann noch ein Stück Dokumentation, wo ich sehe die und die Werte gibt es und da ergibt es sich meistens schon aus dem Kontext, was ich da entsprechend konfigurieren kann.

R1: Bereitet dir denn eigentlich die Konfiguration von interagierenden Tools und Frameworks dir Probleme?

I11: Jetzt, wie zum Beispiel?

R1: Zum Beispiel, hat ein anderer Interviewteilmehmer gesagt, in Spring Boot kann ich zum Beispiel File Upload Limit eingeben und das bewirkt aber, oder es interagiert mit dem Tomcat-Server als Applicationserver, der auch so eine Attribut hat zur Konfiguration. Und die sind interagieren, aber er wusste das gar nicht.

I11: Ah, verstehe. Also das heißt so Konflikte, die dann auch auftreten können oder man kann die Dinge in zwei verschiedenen Systemen kann man das gleiche auf unterschiedliche Art und Weisen konfigurieren. Ja, das ist sicherlich ein Problem. Im Falle von meinen Projekten, die ich jetzt betreue, also im Falle von [meinem Projekt], ist es jetzt nicht so offen ein Problem, weil der [Server] eben als Einheit eine Konfiguration hat und da wird im wesentlichen alles konfiguriert. Das ist dann mehr ein Problem, wenn der [Server] dann mit Drittsystemen entsprechend kommuniziert und dann könnte es schon sein, dass es zu Überschneidungen kommt, dass man auf der einen Seite etwas konfiguriert, das Drittsystem aber dann wieder eine eigene Konfiguration hat und dann kann es zu Konflikten kommen, aber ich habe jetzt kein konkretes Beispiel dafür.

R1: Was sind denn so häufige Auswirkungen von Konfigurationsfehlern nach deiner Erfahrung?

I11: Ja, häufige Auswirkungen sind einfach, dass man dann, dass das System nicht so reagiert, (?1:08:08) nicht so sich so verhält, wie man das erwartet. Dass man aber nicht genau weiß, erstmal nicht genau weiß, dass das aus einer Konfiguration heraus entsteht, sondern, dass man möglicherweise erstmal an anderer Stelle sucht. Dass man erstmal sich die Funktion selbst anschaut, vielleicht dann schon merkt, dass es irgendwo eine Konfiguration ist, aber dann auch erstmal herausfinden muss, welche Konfiguration wird denn letztendlich damit verwendet. Das ist auch nicht mehr ganz trivial oder nicht ganz offensichtlich, was jetzt zum Beispiel der Wert 80 da einfließt oder wenn der Wert 80 einfließt, dann muss man erstmal nachvollziehen können wo stammt denn der her. Also wenn man dann eben so ein komplexeres Konfigurationssystem hat, das vielleicht mehrere Ebenen hat oder mehrere Möglichkeiten, wie man die Dinge konfiguriert, da muss man erstmal nachvollziehen können wo kommt denn jetzt dieser Wert letztendlich her und wer setzt den und in welcher Umgebung muss ich — oder wie muss ich das Ganze nachbauen oder da geht es dann auch so um die (?1:09:18) Reproduzierbarkeit. Was muss ich tun damit ich genau diesen Zustand bekomme und erstmal erkennen kann, okay jetzt habe ich diesen Fehler reproduziert und jetzt möchte ich wissen wo kommt der letztendlich her.

R1: Gibt es für dich einen Unterschied zwischen falscher und schlechter Konfiguration?

I11: Ja, ich denke schon. Also falsch ist — ja, falsch und schlecht liegen schon denke ich mal nahe beieinander. Ich meine wahrscheinlich eine falsche Konfiguration ist jetzt, wenn ich jetzt in meinem Beispiel die Anwendung, die ich habe, also meine Adminkonsole, die ist mehrsprachig. Das heißt es gibt sowas, wie Resource-Bundles, da liegen dann drin und die werden dann entsprechend übersetzt und dann habe ich (?1:10:13) eben in verschiedenen Sprachen. Ein schlechte oder falsche Konfiguration wäre es zum Beispiel, wenn ich mir eine Anwendung baue, die ich nur im englischsprachigen Bereich verwendet wird, ich aber auf Teufel komm raus jetzt irgendwie Dinge in drei, vier Sprachen vorhalte. Das ist einfach unnötig. Ja und Dinge, die einfach unveränderlich sind, die für immer und ewig so bleiben werden, da muss ich nicht eine Konfiguration hochziehen, weil das ganze macht es dann unnötig kompliziert und komplex. Das wäre einfach eine schlechte Konfiguration.

R1: Ja, den Konfigurationsfehler hast du schon rekapuliert, oder? Was dir jetzt besonders schwierig in Erinnerung war. Das ist das mit den Stages, ja?

I11: Ja, das mit den Stages zum Beispiel. Oder einfach auch Dinge dann auskommentieren womöglich man — es gibt ja auch sowas wie, wie viele Dinge, das ist auch noch so eine Ebene der Konfiguration, für wie viele Dinge gibt es Defaultwerte. Das heißt, das ist ja dann auch, manchmal ist es ja auch ein Feature oder es ist ja auch so, wenn ich jetzt zurückdenke an den Bereich (?1:11:41) oder Java EE. Das ist ja so ein, hat so eine gewisse Historie und da gab es ja in den vergangenen Versionen gab es eine sehr komplexe Konfiguration meiner Meinung nach. Viel auch XML-Dateien. Sehr kompliziert und sehr mühselig zu konfigurieren, so eine Java-EE-Anwendung und dann gab es irgendwann mal einen Schnitt und man sagte man hat jetzt sowas wie Convention over Configuration, war so dann das Stichwort. Das heißt man möchte weg von dieser ganzen Konfigurierbarkeit. Es gibt für alles eine Konvention und wenn man das nicht alles konfiguriert, dann gilt diese Konvention. Sprich man hat Defaultwerte oder man hat vernünftige Standardwerte, die man da angenommen hat, die für 80 % aller Fälle gelten und wenn man es anders haben möchte, dann kann man das machen, aber je weniger Konfiguration man hat, umso weniger Fehlerquellen gibt es auch. Und sprich (?1:12:37), also man hat eine Konfigurationsdatei, man kommentiert bestimmte Dinge aus, dann gibt es einen Defaultwert, der verwendet wird und man denkt aber nicht daran, dass man eben das auskommentiert hat. Das ist so eine Fehlerquelle bei Konfiguration von Systemen.

R1: Ist das also eher so Nachteil von diesem Convention over Configuration Trend?

I11: Ja, ich möchte das nicht unbedingt als Nachteil hinstellen, weil eigentlich ist dieses Convention over Configuration schon eine gute Sache. Je weniger Konfiguration man hat, umso besser finde ich eigentlich. Das heißt man sollte sich eben auch genau überlegen was möchte man denn konfigurieren und vor allem, was sind denn sinnvolle Defaultwerte. Wenn man eine Datenbankverbindung anlegt dann hat meistens (?1:13:27) sage ich mal 10 Verbindungen im Connection Pool oder die Größe des Connection Pools ist 10. (?1:13:38) das sind die Werte, passt für fast alle. Und dann macht es keinen Sinn diesen, dass man zwingend eine Konfiguration für die Größe des Connection Pools angeben muss. Dann sollte man eben einen Defaultwert entsprechend haben. Macht aber trotzdem Sinn das ganze konfigurierbar zu machen, aber nicht eben zwingend.

R1: Wie häufig treten denn Konfigurationsfehler bei euch in der Projektarbeit auf?

I11: Also jetzt in meinem Projekt sehr wenig sage ich mal. Was so den größeren Kontext angeht. Was den [Server] selber angeht, da denke ich mal schon sehr häufig. Da wenn man sich dann in den Mailinglisten umschaut sieht man dann schon immer wieder Beschreibungen von Usern, die dann halt irgendein bestimmtes Problem haben und sagen das und das Problem habe ich und hier ist meine Konfiguration. Weil die Konfiguration ist auch immer Teil des Problem meistens. Also wenn man sich so auf StackOverflow ansieht wie — oder irgendwelche Issues sich durchliest, dann ist ja immer im wesentlichen die erste Frage des Entwicklers wie sieht denn deine Konfiguration aus. Weil das ist nun meistens dann so, dass das eben einen wichtigen Teil der Beschreibung darstellt und auch der potentiellen Lösung dann.

R1: Wann treten denn typischerweise Konfigurationsfehler auf in der Projekthistorie? Also wenn du von Anfang deiner Entwicklung über Maintenance—

I11: Ja, typischerweise treten die dann oft auch zur Laufzeit auf, also während des Betriebs von der Anwendung. Und ganz schwierige Dinge, also schwer zu findende Fehler sind es dann halt dann, wenn man eine exotische Umgebung hat vielleicht, die man so am Anfang gar nicht damit gerechnet, dass sowas auftreten könnte. Das sind dann meistens die Fehler, die am schwierigsten zu finden sind. Ja, einfachere Fehler sind dann so, dass man dann Konfiguration in einer Art und Weise verwendet für die sie eigentlich nicht gedacht ist. Die könnte man dann wahrscheinlich schneller finden, aber oft treten solche Fehler halt leider dann zur Laufzeit auf, deswegen auch je mehr Konfiguration man überprüfen kann, umso besser. Das ist auch noch mal wieder ein Argument dafür, dass man man möglichst viele Dinge vielleicht beim Bauen der Software schon überprüfen sollte. Das ist nicht immer möglich, aber wenn möglich dann schon.

R1: Und wenn du jetzt den Lebenszyklus einer Software anguckst, ist es eher in der Entwicklungsphase oder dann erst wenn es beim Nutzer ist?

I11: Ja, leider erst dann wenn es beim Nutzer ist. In der Entwicklungsphase wäre es noch besser die Dinge zu erkennen, weil es dann natürlich auch viel einfacher ist die Dinge zu beheben, aber leider treten dann solche Dinge oft auch dann erst beim Kunden oder beim Benutzer letztendlich auf.

R1: Gibt es nach deiner Erfahrung Unterschiede zwischen fachlichen und technischen Konfigurationsfehlern? Also auch vielleicht im Hinblick der ganzen Fragen davor.

I11: Ich denke weniger, weil Konfiguration ist erstmal Konfiguration. Ob das jetzt für die technische Seite verwendet wird oder für die fachliche Seite spielt dann eigentlich nicht so sehr die große Rolle. Wie gesagt, man sollte bei jeglicher Art von Konfiguration einfach immer gut überlegen ist es, muss ich das konfigurierbar machen, ist es was, was wirklich nötig ist um die Software gut zu verwenden zu können und gibt es dafür eben einen vernünftigen Defaultwert, den ich setzen. Solche Art von Fragen sollte man sich dann einfach stellen, egal ob es jetzt technisch oder fachlich ist bevor man dann die Konfigurationsmöglichkeit einbaut.

R1: Okay, wie gehst du denn typischerweise vor um Konfigurationsfehler zu finden und zu beheben?

I11: Ja, ich versuche mir einfach möglichst viele Informationen vom Benutzer zu holen, bei dem der Fehler auftritt und versuche möglichst dann diese Umgebung möglichst so nachzustellen, nachzubauen wie sie der Benutzer, bei dem der Fehler auftritt, dann im Einsatz hat und dazu zählt eben auch die Konfiguration. Wie ist das verwendete, in meinem Fall der verwendete Browser, die verwendete Version der Software, wie wird die betrieben, in welcher Sprache, mit welcher Version des [Servers], also sprich das ganze nachbauen, nachstellen und dann, ja dann geht die eigentlich Fehlersuche los.

R1: Ist denn auch StackOverflow, Dokumentation lesen dabei?

I11: Ja, genau das auch. Also sprich, wenn es dann irgendwo, wenn der Fehler dann irgendwo in einem Toolkit oder Framework oder Bibliothek liegt, das man verwendet, dann muss man halt entsprechend da die StackOverflow-Einträge wälzen oder da wühlen und gucken, ob es irgendwo ähnliche Probleme gibt und damit man einfach möglichst das ganze nachvollziehen kann.

R1: Und Kollegen fragen, kommt das dann auch noch irgendwann in Frage?

I11: Ja, das ist auch auf jeden Fall hilfreich, hilft oft auch weiter. Hängt davon ab, wo das Problem so ein bisschen liegt. Also in meinem Falle, wenn ich jetzt an der Konsole arbeite, bin ich momentan so der einzige Entwickler, der daran arbeitet und dann läuft es mehr darauf hinaus eben StackOverflow da zu gucken oder auf GitHub in den Issues zu wühlen, ob es ähnliche Probleme schon mal gab, wie die gelöst wurden und welche Möglichkeiten es gibt die entsprechend zu lösen. Kollegen sind immer dann hilfreich, wenn man gar nicht mehr weiter kommt und vielleicht einfach mal einen Blick von jemand anderem braucht, der mal vielleicht gar nicht so viel damit zu tun hat. Oft hilft es auch schon, — es ist ja ganz oft so, das hat jetzt weniger mit Konfiguration zu tun, sondern wenn man dann das Problem schildert und jemand anderem erzählt, oft reicht das schon aus um selber dann eine Lösung dafür zu finden.

R1: Welche Strategien hast du denn um Konfigurationsfehlern vorzubeugen?

I11: Ja, also ein sehr wichtiger, oder eine gute Strategie Konfigurationsfehlern vorzubeugen ist, dass man es gar nicht konfigurierbar macht. Also sprich bezogen auf die Frage, einfach so die Sinnfrage zu stellen „Muss ich das konfigurieren oder nicht?” und dann eine andere Strategie ist vielleicht einfach sich ein gutes Strategie zu überlegen wie mache ich Dinge konfigurierbar. Es ist vielleicht einfacher Dinge dann irgendwie in einer Propertiesdatei konfigurierbar zu machen, als eine Datenbank dafür herzunehmen. Für eine Datenbank brauche ich viel mehr Infrastruktur und viel mehr Dinge um DInge dort abzulegen, die selber konfiguriert werden müssen. Also dann sprich, je einfacher es ist Konfigurationswerte oder Konfiguration zu pflegen oder zu zu verändern umso besser.

R1: Und so der letzte Teil praktisch: Verbesserungsbedarf. Was erwartest du denn eigentlich von einer guten Dokumentation über Konfiguration?

I11: Das ist auch ein sehr wichtiger Aspekt, ja. Also Konfiguration alleine ist eigentlich wenig wert, wenn die nicht gut dokumentiert ist. Und daran scheitern auch viele Systeme, das ist eine sehr gute Frage eigentlich. Also was ich mir auf jeden Fall erwarte von einer Dokumentation ist, wozu ist diese Konfiguration da, sowas wie welchen Datentyp hat diese Konfiguration, also was kann ich da letztendlich hinterlegen. Ist das ein Boolean, ist das eine Zahl, ist das ein Datum. Einfach so dieser Datentyp, weil viele Konfigurationsmechanismen sind erstmal, sind nicht typisiert sondern basieren auf Strings. Da kann ich alles mögliche reinschreiben. Das ist manchmal einfach, das liegt in der Natur der Konfiguration. Aber dann muss die Dokumentation sehr klar sein. Also dann muss genau dokumentiert sein, was für einen Wert kann ich denn da hinterlegen. Das ist einmal der Datentyp und dann vielleicht auch sowas wie eine Semantik. Also ich kann ja wegen mir eine Zeitspanne eingeben, aber welche Zeitspanne macht denn Sinn? Also wenn ich hier zum Beispiel eine Zeitspanne eingebe, sind das jetzt Millisekunden, sind das Sekunden, Minuten, Stunden? Es ist immer eine Zahl, aber diese Zahl hat eine bestimmte Bedeutung. Also auch das muss dokumentiert sein. Und dann muss es dokumentiert sein, ist es eine zwingende Konfiguration, ist es optional, muss ich die angeben oder muss ich die nicht angeben? Und dann das i-Tüpfelchen wäre vielleicht noch, welche Auswirkungen hat diese Konfiguration, hat die irgendwelche Seiteneffekte auf andere Werte oder hängt die zusammen? Muss ich dir nur angeben wenn ich einen anderen Konfigurationswert angegeben habe? Ist die dann zwingend, wenn ich ein bestimmtes anderes Flag gesetzt habe oder ist die immer optional? Also so die Zusammenhänge zu anderen Konfigurationswerten? Das erwarte ich mir von einer guten Dokumentation.

R1: Hast du denn ein Beispiel von guten und schlechten Dokumentationen?

I11: Ja, also eine gute Dokumentation ist denke ich mal schon die Dokumentation für den Wildfly-Application-Server, weil wir da dieses Meta-Modell haben für jeden Konfigurationswert gibt es irgendwie genau diese Angaben, die man machen muss: Zwingend, ist das optional, welchen Datentyp, dann auch so was für ein Wert ist das, ist das ein Millisekundenwert, ist das im Sekundenbereich und sowas. Das ist auch, über eine Webseite kann man das entsprechend abrufen, weil das eben automatisch generiert werden kann diese Art von Dokumentation. Ein schlechtes Beispiel habe ich jetzt keins parat, gibt es aber bestimmt wie Sand am Meer. Das ist immer dann wenn halt die Dokumentation fehlt, also wenn ich halt irgendwie, ich habe Properties-Dateien, die halt nun mal einfach string-basiert sind, aber ich weiß nicht was muss ich jetzt darein schreiben. Oder gerade ganz oft hat man halt hier so Zeitintervalle oder Zeiten, die man angibt und da stellt sich mir jedes Mal die Frage, ich gehe dann mal davon aus, dass das Millisekunden sind, weil viele Entwickler benutzen Millisekunden, weil das einfach, da müssen sie nicht groß rumrechnen, aber dann ganz oft ist es so, merkt man dann im Nachhinein, ah, was er eigentlich will sind Sekunden. Und dann ist es natürlich, so einen Fehler zu finden ist natürlich dann die Hölle.

R1: Welche Verbesserungen würdest du dir hinsichtlich von Konfiguration von Frameworks und so weiter wünschen?

I11: Ja, also einfach gute Dokumentation. Sich auf die wesentlichen Dinge beschränken. Nicht alles konfigurierbar machen. Und was man vielleicht meinte man müsste konfigurieren, sich auf das wesentliche beschränken und eine gute Dokumentation liefern. Also diese zwei Dinge, die würden schon mal 80 % der Schwierigkeiten oder der Probleme vielleicht vermeiden.

R1: Was würde dir helfen schneller Konfigurationsfehler zu identifizieren?

I11: Ja, da sind wir wieder bei der Idee, dass man möglichst viel zur Buildzeit überprüft. Also wenn man die Sachen deployt oder wenn man die Sachen baut, dann schon alles, was möglich ist zu überprüfen. Also wenn da irgendein Wert von 30.000 drinsteht, aber man meint damit aber Minuten und keine Millisekunden, dann könnte man schon mal einen dezenten Hinweis, zumindest so ein Warning ausgeben, dass man da vielleicht einen Wert drinstehen hat, der keinen Sinn macht.

R1: Und die schneller zu beheben? Also das fixen.

I11: Da ist es wichtig, dass man genau dem Benutzer als Feedback dann gibt wo steht dieser Wert, in welcher Datei, wo finde ich den und wo muss ich dann entsprechend was ändern. Also so ein bisschen Analogie zu wenn ich einen Syntaxfehler habe, dann kriege ich den Dateinamen, dann kriege ich die Zeile 23, womöglich auch noch die Spalte 25, da fehlt ein Semikolon. Dann weiß ich genau, was ich zu tun habe. Wenn ich ähnlich gute Fehlermeldungen bei Konfigurationsfehlern bekommen würde, wo ich dann sehr schnell dann finde erstmal Name der Datei, womöglich noch die Zeile und den Wert und aber nicht nur sagen da ist was falsch oder ungültiger Wert, sondern wie heißt der Konfigurationsparameter, wie heißt der Wert, wo finde ich den? Diese Angaben brauche ich alle letztendlich und dann kann ich auch den Fehler schnell beheben.

R1: Okay, letzte Frage, die wir haben, was würde die helfen besser Konfigurationsfehlern vorzubeugen? Außer weniger Optionen jetzt zu haben.

I11: Ja, das ist so die Summe der Dinge. Also da spielt dann vieles zusammen, von vielen Dingen, die wir jetzt so im Laufe der letzten Stunde besprochen haben. Also das Format der Konfiguration, die genaue Fehlermeldung, möglichst frühzeitig darauf hingewiesen zu werden. Auch eine gute Überprüfung und Validierung von Werten, die da eingegeben wurden. So die Summe der vielen Dinge, die, wenn die dann alle zusammenkommen und zusammengreifen, dann macht es auch Spaß Konfigurationsfehler zu beheben.