Skip to content

Latest commit

 

History

History
466 lines (156 loc) · 39.7 KB

File metadata and controls

466 lines (156 loc) · 39.7 KB

R1: Was tust du denn fachlich in deinem Job? Bist du irgendwie Consultant, Tester, Teammanager, Developer?

I10: Also ich bin Berater, Tester und Softwareentwickler.

R1: In welcher Domäne arbeitest dabei? Also mit Domäne eher so ein bisschen, sagen wir Backend, Frontend, DevOps, Webentwicklung oder—

I10: Fullstack.

R1: Fullstack. Okay. Und was ist deine Rolle in der Softwareentwicklung? Also Projektleiter dabei, oder—

I10: Entwickler.

R1: Welchen Anteil an deiner täglichen Arbeit ist denn dabei die tatsächliche Softwareentwicklung, beziehungsweise Programmierung?

I10: Also wenn man so das Lesen von Tickets und so weiter das Zeugs halt einschließen, macht das sicherlich, wenn man mal jetzt testen halt abziehen, ungefähr 75 % aus.

R1: Wie viele Jahre hast du denn Erfahrung in der Softwareentwicklung?

I10: 7 Jahre.

R1: Seit wann bist du in deiner Organisation?

I10: Januar 2018.

R1: Und in deiner aktuellen Position als, ja, Berater oder so?

I10: Jetzt auch nur auf das Unternehmen bezogen, oder? Also Berater war ich auch schon vorher.

R1: Okay, seit wann?

I10: Berater bin ich seit September 2014.

R1: Und vielleicht noch so als abschließende Frage, generell mit welchen Frameworks und Tools arbeitest du für gewöhnlich?

I10: Also, Tools ist IntelliJ. Frameworks ist Spring, Spring Boot. Ansonsten nutzen Apache Tools. Also was es da hergibt, Apache POI, das ist lesen und schreiben von Microsoft Office-Formaten. Dann Apache Formatting Objects. Da geht es darum aus einer Objektstruktur Reports zu generieren. Das kann ein PDF sein oder XML oder was auch immer. Ansonsten Javers, das ist ein Tool um Objekt-Diffs zu machen. Also du hast einfach zwei Instanzen einer Klasse und kannst es da in dieses Tool reinwerfen und das berechnet dir ein Diff über den du dann wiederum navigieren kannst. So, das sind die, die mir spontan einfallen. Ansonsten wenn ich mal reingucke, was wir da so einsetzen: Wir nutzen JAXB um XML-to-Objekt-Transformationen zu machen. Also wir arbeiten auf XML-Daten und aus denen erzeugen wir uns ein Klassengeflecht, was dann im Grunde mit den XML-Daten instantiiert wird auf denen wir dann später arbeiten können. Ansonsten nutzen wir, naja gut, Vaadin als Webframework. Loggingzeugs nutzen wir SLF4j. Dann nutzen wir JGit, FasterXML, Apache hatten wir schon.

R1: CI/CD irgendwas?

I10: Ja, Jenkins, GitLab. Und dann nutzen wir noch FreeMarker als Library.

R1: Containerization?

I10: Wir nutzen Kubernetes für unser internes Deployment und zum testen.

R1: Gut, das war ja schon ausführlich. Jetzt geht es gleich los, Konfiguration generell erstmal. Was verstehst du denn unter dem Begriff Konfiguration?

I10: Ja, das habe ich mich auch schon gefragt, was ihr eigentlich von mir wissen wollt, weil das ja eigentlich verschiedene Ebenen umfasst mit Productline- und Variantenmanagementbackground bedeutet das eben für mich eine Produktlinie zu konfigurieren. Das heißt ich habe ein Modell, ein Featuremodell, was alle validen Varianten einer Produktlinie beschreibt und dann Konfiguration ist eben das Ergebnis einer gültigen Selektion von den Optionen, die mir eben die Produktlinie bereitstellt oder dieses Modell. Um das weiter spinnend auf all das, was ich jetzt halt so sehe, kann man natürlich auch seine Software und Frameworks und das alles eben auf verschiedenen Ebenen konfigurieren. Sei es jetzt in irgendwelchen YAML-Files oder XML-Files oder was auch immer. Und das ist eben sicherlich auch ein Bestandteil davon, dass am Ende — oder vom Bestandteil vom Thema Konfiguration und das ein fertiges Softwareprodukt eben so läuft, wie das angedacht ist.

R1: Wann konfigurierst du denn Software? Also welche Bindingtime sozusagen?

I10: Ist Compile- und Starttime.

R1: Wir haben bisher in den Interviews unterschieden zwischen fachlicher und technischer Konfiguration. Ist das bei dir denn auch der Fall? Beziehungsweise kannst du dir unter den Begriffen auch etwas vorstellen?

I10: Na gut, rein technische sind halt für mich so Dinge, wie zum Beispiel wir erarbeiten eine Webapplikation und da ist technisch für mich sowas wie auf welchem Port läuft die. Fährst halt deine Webapplikation hoch und sagst eben die soll jetzt auf Port 1234 laufen oder sowas. Das ist, wenn ich das mal so überlege, würde das glaube ich bei uns so einen Großteil dessen ausmachen, was wir sicherlich an Konfiguration tuen. Dann auch hinsichtlich welche Pfade werden verwendet. Dann auch noch hinsichtlich, dadurch, dass wir eine Webapplikation haben und die zum Beispiel auch Daten austauscht. Also ich kann zum Beispiel Daten hochladen und Daten runterladen. Und für das Daten hochladen gibt es dann halt im Hintergrund erlauben mir anzugeben, welche Filegrößen werden noch akzeptiert und welche Requestgrößen werden noch akzeptiert. Das sind halt so typische Dinge, die halt konfiguriert werden. Zumindest im Spring-Boot-Umfeld. Rein fachlich, lass mich mal überlegen, ne haben wir eigentlich. Also es gibt halt schon durchaus Dinge, die einen fachlichen Bezug haben, aber es geht jetzt halt nicht darum das fachliche Modell oder sowas selbst zu konfigurieren, sondern das hat immer einen technischen Bezug im Sinne von eine URL oder ähnliches oder wie eine URL aufgebaut wird oder ähnliches. Das hat für mich jetzt keinen fachlichen Bezug im Sinne von dieses fachliche Modell, was wir halt machen zu steuern und zu kontrollieren, sondern eher die Technik zu beschreiben, die es eben erlaubt in der fachlichen Umgebung zu arbeiten.

R1: Die nächste Frage ist eigentlich gibt es Interaktionen zwischen fachlicher und technischer Konfiguration. Da jetzt bei euch nicht viel fachlich ist, vielleicht ist das dann eher eine theoretische Frage oder vielleicht in deinem Consulting-Leben, hast du schon sowas gesehen, solche Interaktionen?

I10: Zwischen fachlich und technisch? Also wenn ich jetzt mal so auf der Hüfte schießen sollte, ja. Und zwar eigentlich eher im Produktlinienumfeld. Da gab es halt so Fälle, dass wir Dinge konfiguriert haben, die sich eigentlich auf Versionen bezogen haben und nicht auf Varianten um Mängel in der technischen Abbildung zu machen. Also das war eigentlich eine technische Abbildung um Versionen zu steuern, aber um Mängel zwischen Technik und fachlich umzusetzen.

R1: Kannst du das vielleicht noch mal, vielleicht ein Beispiel geben? Das ist jetzt schwierig nachzuvollziehen, was du meinst.

I10: Vielleicht passt das Beispiel auch nicht so gut oder was auch immer. Zumindest, wir hatten den Fall, dass, wir haben eine Produktlinie von der können wir eine Menge von Varianten ableiten. Dann kommen an einen gewissen Punkt an dem wir halt sagen, dass wir technisch gesteuert neue Varianten einführen müssen. Also konkret bezogen auf Versionen um die Fachlichkeit abbilden zu können. Dass wir eigentlich, naja, mehr fachliche Varianten haben als wir jetzt eigentlich hatten.

R1: Okay, also der Grund für die Konfiguration war dann technische Unzulänglichkeiten oder? Oder wollte man auf ältere Versionen zurückgreifen?

I10: Ja, man wollte sich halt ältere fachliche Sachen eben erhalten und musste das mit so einem technischen Kniff eben umsetzen, weil man sich eben nocht darauf einigen konnte, das rein fachlich abzubilden. Das war eher so aus der Problematik heraus, dass man sich eben nicht darauf einigen konnte zu sagen wir schalten jetzt halt quasi mal so alte Zöpfe ab, sondern man will halt altes und neues gleichzeitig unterstützen zu dem einen Zeitpunkt, den man jetzt gerade hat.

R1: Hast du denn vielleicht typischerweise auch mit der Konfiguration von einem monolithischen System zu tun?

I10: Also bei monolithischen Systemen fällt mir eben Linux ein. Das eher nicht, nein. Das ist in der Grunde immer ein Sammelsurium aus unterschiedlichen Bibliotheken, Frameworks, die wir einsetzen, die dann eben zusammenhängend konfiguriert werden müssen.

R1: Genau, gibt es eigentlich Interaktionen zwischen den ganzen Konfigurationen für Tools, Frameworks, Infrastruktur und so weiter?

I10: Ja, weiß ich zumindest ein konkretes Beispiel über das ich neulich mal gestoßen bin. Da geht darum um eine Interaktion zwischen Vaadin und Spring Boot. Also Spring/Spring Boot ist ein Framework für die Kontrolle von, also ursprünglich mal für Dependency Injection. Es bietet aber auch Möglichkeiten zur Unterstützung von, zur Entwicklung von Webapplikationen. Das heißt halt konkret, ich kann halt so Webcontroller bauen, die im Grunde hinter einer URL repräsentieren und hinter diesen Controllern kann ich zum Beispiel sowas einstellen wie Dateigröße. Also sowas, was wir vorhin hatten, sodass ich jetzt sagen kann ein Client kann auf diese Anwendung maximal Dateien einer gewissen Größe hochschicken. Sagen wir mal 100 Megabyte. Und kann halt auch Requests dahin schicken, die meinetwegen 200 MB groß sind für den Fall, dass ich zum Beispiel mehr als eine Datei da hochladen möchte. Jetzt bietet Vaadin als Webanwendung, bietet eben etwas ähnliches. Also bietet eben auch das, weil das eigentlich genau sowas eben kontrollieren will. Weil Vaadin ja auch im Grunde diesen Bestandteil von Webanwendungen jetzt eben abbildet. Sekunde, kurz überlegen. Ne, das war falsch und zwar ist es nicht Vaadin, sondern Tomcat im Hintergrund. Also nicht Vaadin sondern Tomcat. Und Tomcat macht jetzt eben genau das gleiche, weil das eigentlich jetzt den Controller selbst kontrolliert indem ich eben Dateiaustausch mache. Und da gibt es eben eine Interaktion zwischen dem, was ich in Spring und Spring Boot konfiguriere und dem was eben Tomcat hat. Und so schlagen jetzt die Konfigurationsoptionen von Spring/Spring Boot auf die von Tomcat durch. Ja, das ist das, was wir konkret dazu einfällt.

R1: Okay, vielleicht auch sowas Interaktion zwischen deiner CI/CD-Infrastruktur und deiner Software?

I10: CI/CD-Infrastruktur und Software? Kurz überlegen. Ne, das kann ich nicht beantworten. Als ich selbst wüsste davon nicht, nein.

R1: Habt ihr denn einen — oder baust du deine eigente Infrastruktur zum entwickeln oder habt ihr dafür vielleicht ein Team?

I10: Die Frage bitte präzisieren.

R1: Baust du dir selber deinen Continuous Integration/Deployment Service oder Docker und den Jenkins bis es dann auf dem Testing-Stage und dann vielleicht Prod landet? Oder habt ihr da spezielle Abteilungen, die euch das vielleicht vorkonfiguriert hinsetzen?

I10: Es ist ein bisschen zweischneidig und zwar haben wir, wir haben Unterstützung durch unsere IT-Abteilung dafür. Die eben so grundsätzliches wie hier gibt es eben einen Cluster um dann eben deinen Kubernetes mit deinen Dockerimages dadrauf zu werfen. Es wird aber unterstützt von Entwicklern, die auch in dem Team mitarbeiten.

R1: Das sind aber andere dann, ja?

I10: Das bin ich nicht selbst, nein. Das sind andere Kollegen.

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

I10: Ja, ohne läuft nicht viel, ne? Wie gesagt, du kannst die tollste Anwendung der Welt haben, wenn du sie falsch konfiguriert hast, funktioniert sie eben nicht.

R1: Da du ja auch schon ein bisschen Einblick in der Forschung hast, wie würdest du denn vielleicht einschätzen, berücksichtigt denn die Forschung die Bedürfnisse der Praxis?

I10: Oh, weiß ich nicht. Kann ich nicht sagen. Also zumindest, was diesen Konfigurationsaspekt angeht, habe ich keine Ahnung in wie weit da schon was gemacht wird oder auch nicht. Also ich sehe jetzt eben was diese Bibliotheken schon machen und wie sie da eben arbeiten und falls ich da irgendwelche Probleme habe, da lande ich jetzt nicht in irgendwelchen Papers oder sowas, sondern lande ich eben in der Regel auf StackOverflow wo vielleicht unter Umständen die Leute, die Probleme beschreiben, die ich eben auch habe. Aber das heißt eben Handbücher lesen, Spezifikationen lesen.

R1: Okay, gibt es denn bezüglich des Aufwandes oder Stellenwert der Konfiguration Unterschiede in den verschiedenen Softwarelebensphasen?

I10: Kann ich nicht sagen, weil zumindest in den Projekten, in denen wir jetzt arbeiten, sind wir eigentlich nicht so Prototypen- und Entwicklungsphase. Das heißt hinsichtlich Maintenance, Testing oder halt spätere Betreuung kann ich nichts zu sagen. Ich war auch nie selbst in einem Projekt, wo das der Fall war.

R1: Wurdest du denn während deines Studiums oder Ausbildung darauf vorbereitet auf diesen Konfigurationsaspekt?

I10: Ganz pauschal: Nö.

R1: Sollte es denn unterrichtet werden?

I10: Also es wäre sicherlich sinnvoll sich mal damit auseinanderzusetzen, aber ob das jetzt halt ein großes Thema werden sollte und jetzt bin ich ja viel in dem Thema Doing drin und das halt zu machen und man lernt sicherlich einiges davon und was jetzt so die Aspekte davon sind, aber das jetzt in der Breite im Rahmen eines, was weiß ich, Softwareprojekts an der Uni oder Programmieraufgabe oder ähnliches dann zu tun — weiß ich nicht, geht glaube ich etwas zu weit.

R1: So, jetzt gehen wir zum zweiten Themenkomplex praktisch über: Wie arbeitet ihr sozusagen mit Konfiguration? Wäre die erste Frage, wie werden denn Konfigurationen bei euch verwaltet und dokumentiert?

I10: Also Konfigurationen sind bei uns, weil sie auch Bestandteil der Anwendung sind, so wie sie halt laufen werden, werden mit ins Git eingecheckt, ins Git-Repo. Sie werden, also das unterteilt dann wieder einen Teil dieser Konfigurationsoptionen, die wir da berücksichtigen, betreffen zum Teil nur unsere Anwendung, aber auch zum Teil dessen, oder die Bibliotheken und Frameworks, die wir halt da einsetzen. Die, die wir selbst einführen sind im Grunde nicht konfiguriert oder nicht dokumentiert. Falls doch es halt so Entscheidungen gibt, die jetzt halt nicht sagen wir mal intuitiv sind. Dann gibt es halt einen Kommentar dazu, warum, wieso, weshalb das so ist. So ähnlich wie man das jetzt bei Quellcode auch machen würde. Wenn der nicht selbsterklärend ist, dann gibt es dann eben auch eine Erklärung dazu, warum, wieso, weshalb der Wert so gesetzt wurde.

R1: Wo steht der Kommentar?

I10: Der steht neben der Konfigurationsoption direkt in der Konfigurationsdatei.

R1: Was ist denn der größte Vorteil von eurer Verwaltung?

I10: Konsistenz. Das heißt ich kann halt den Stand genauso wieder herstellen, kann den immer wieder so herstellen, wie ich ihn noch heute aktuell habe.

R1: Und der größte Nachteil?

I10: Es schafft kein zusammenhängendes Bild, weil Konfigurationen häufig eben auf verschiedene Dateien eben verteilt sind. Aber auch natürlich unterschiedliche Aspekte abbilden. Sei es jetzt, dass ich eben — unser Projekt besteht aus mehreren kleinen Teilprojekten. Da gibt es dann halt eine Konfiguration im Fall von Maven. Dann unsere Anwendung selbst ist dann eben Spring/Spring Boot. Dafür gibt es eine Konfiguration. Ja, also ich hatte das selbst noch nicht, aber es kann sicherlich, will es nicht ausschließen, Fälle geben, wo diese eben übergreifend sind. Korrigiere: Die sind auch übergreifend, das heißt wir machen in einem Aspekt, und zwar legen wir Profile an in Maven und diese Profile sind dafür gedacht das Deployment auf unterschiedlichen Systemen, zum einen bei uns, zum anderen auch beim Kunden zu steuern. Und da sind in den Profilen sind Konfigurationsoptionen hinterlegt, die wieder sich zum Beispiel auf die Spring-Boot-Applikation durchschlagen. Das betrifft zum Beispiel unter welchem Port wird ein System hochgefahren, unter welcher URL und sowas. Da gibt es halt Verbindungen und die sind, wenn man es nicht weiß, nicht so einfach zu sehen.

R1: Okay, da sind Interaktionen, Abhängigkeiten drin dann?

I10: Ja, genau.

R1: Und die werden dann auch von unterschiedlichen Stakeholders verwaltet oder die Werte geownt sagt man ja?

I10: Nein, also die Infrastruktur dazu hat ein Kollege aufgesetzt, mit Hilfe von anderen Kollegen. Stakeholder im Sinne, die natürlich Interesse daran haben, sind jetzt unterschiedliche Parteien, aber einfach nur aus dem Grunde, weil das System einfach oder unsere Anwendung auf unterschiedlichen Systemen laufen soll. Aber die Infrastruktur selbst betrifft halt nur eine Person.

R1: Habt ihr da spezielle Tools außer jetzt Git um Konfigurationen vielleicht zu verwalten?

I10: Nö. Es gibt halt die Dateien selbst, die kommen halt in unterschiedlichen Formaten. Es gibt so die application.properties von Spring. Das sind einfach nur so Key-Value-Stores. Dann gibt es halt die YAML-Files und dann eben, also YAML-Files für zum Beispiel GitLab-Steuerung und Continuous Integration und dann eben noch XML-Files zum Beispiel für Maven.

R1: Dockerfile wahrscheinlich noch.

I10: Genau, ja.

R1: Und eure Secret-Keys habt ihr nicht in einem Vault oder so extra?

I10: Wie bitte?

R1: Die Secret-Keys oder so, also confidential Sachen. Habt ihr nicht noch ein extra Tool dann?

I10: Nein.

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

I10: Also es gibt in dem Projekt selbst gibt es eine grundlegende Readme-Datei, die man eben aus GitLab heraus, es ist halt ein Markdown-File, mit dem man sich eben die grundsätzliche Struktur eben anzeigen lassen kann. Ansonsten folgt das Projekt, zumindest was den Maventeil angeht, halt standard Mavenstruktur. Wir haben ein Parent-Projekt und dann Childprojekten, das ist auch so den Entwicklern alles klar. Ansonsten ist es würde ich sagen taskgetrieben. Das heißt wenn eine Aufgabe besteht, gibt es eine Erweiterung zu machen, die auch Anpassung an den Konfigurationen notwendig macht. Dann wird das von dem Architekten oder den zugehörigen Entwicklern oder diejenigen, die sich auskennen dann auch an den Entwickler mitverteilt, der sich jetzt um diesen neuen Task kümmern soll.

R1: Wie findet diese Verteilung statt? Persönlich oder Email, Chat?

I10: Jira. Und persönlich.

R1: Was ist denn der größte Vorteil von dieser Kommunikation?

I10: Also im Falle von Jira, das man im Grunde wieder nachlesen kann, wie es halt entsprechend war und jeder halt für sich selbst, wenn er halt das Ticket bearbeitet das noch mal nachvollziehen kann. Wenn es eben persönlich ist, ist das in der Regel immer so ein 1-to-1 am Rechner, wo es jetzt darum geht konkret zu zeigen, wenn es halt ein Problem gibt darauf hinzuweisen. Aber ansonsten ist das eigentlich in Jira festgehalten.

R1: Was empfindest du dann als Nachteil, als größten vielleicht?

I10: Dass die Leute das vielleicht nicht durchgängig tun, das auch so zu machen. Und das lieber das eher so in einem 1-to-1 machen möchten oder auch sagen rufe ich mal schnell an und dann wird es halt im Nachgang nicht festgehalten.

R1: Werden bei Code-Reviews eigentlich auch bei euch Konfigurationsdateien gereviewt?

I10: Ja, es ist ein Bestandteil, dass man sich das mit durchsieht und wir gehen ja auch mittlerweile dazu über, dass man sich dann auch direkt das Deployment eben angucken kann und das dann eben auch auf einem Kubernetescluster zu sehen. Unabhängig jetzt von — also wenn der Continuous Integration durchgelaufen ist, man lässt dann eben seine Unit- und seine Integrationtests durchlaufen — dass man eben auch so einen Applikationstest machen kann. Also die Möglichkeit besteht. Besteht nun bei uns noch nicht sehr lange, aber es wird glaube ich noch nicht konsequent durchgezogen.

R1: Nach welchen Kriterien und zu welchem Zeitpunkt plant oder implementiert ihr denn neue Konfigurationsoptionen?

I10: Also nach welchen Kriterien? Naja, im Grunde ist das, haben wir ein Vorgehen, also wir arbeiten sprintbasiert nach Sprints, zusammen mit dem Kunden und der erarbeitet eben neue Storys und die werden von den Architekten so weit runtergebrochen, dass man die Story eben angehen kann. Da kann schon ein direkter Bestandteil sein, dass eben eine Anpassung oder eben Erweiterung hinsichtlich Konfiguration notwendig ist. Oder es ergibt sich dann eben raus mit Rücksprache, wenn der Entwickler angefangen hat an dem Ticket zu arbeiten.

R1: Okay, und ist dann das Kriterium so wir brauchen, wir müssen Testbarkeit herstellen oder diese Option soll immer — oder der Code soll rückwärtskompatibel sein, oder?

I10: Nein, das ist in unserem Fall nicht so. Das ist aber sicherlich auch ein Sonderfall, weil wir aktuell an einem Prototyp bauen und dass die Sachen, die wir machen müssen nicht rückwärtskompatibel sein.

R1: Und in deiner Consultingerfahrung, hast du da irgendwie sowas? Oder generell solche Art von Kriterien?

I10: Also ist es sicherlich ein Issue und ich weiß das eben aus anderen Bereichen, aus anderen Domänen. Das heißt wenn man sich auch allgemein mit dem Thema Konfigurationsmanagement beschäftigt. Aber dass ich jetzt halt von konkreten Fällen berichten kann, wo ich halt davon wusste, so weit war ich in den Themen nie involviert.

R1: Wie viel Aufwand betreibt ihr denn ihr denn in der Entwicklungszeit, wenn du das so grob abschätzen kannst, um Konfigurationsoptionen einzubauen?

I10: Also ich versuche mich mal so an Tickets zu erinnern, die ich selbst bearbeitet habe, wo es halt darum ging sowas Neues einzubauen. Ja, also das runterbrechen, die Tickets selbst, die ich in diesem Zuge mal bearbeitet habe für Konfiguration selbst, waren in der Regel nicht mehr als ein bis zwei Tage.

R1: Okay und wie viel Aufwand betreibt ihr um Sachen zu konfigurieren?

I10: Also selbst Konfigurationen zu erstellen?

R1: Ja. Die natürlich dann valide sind zum Beispiel.

I10: Also es ist nur eine Schätzung. Ich würde nicht sagen, also weniger als 5 %. Weil Konfiguration steht, wird auch nur dann angepasst, wenn sie, wenn es irgendwie Probleme gibt. Weil, was weiß ich, wie neulich diesen Fall, da hatte ich ein Beispiel, ich wollte eben eine größere Datenmenge zu unserem Server hochladen und das ging eben nicht. Es gab eine Fehlermeldung in der Oberfläche und da war mir dann klar, dass eben ich die Anfragegröße verletzt hatte zu dem, was da halt im Hintergrund war. Oder was im Hintergrund eben erlaubt war durch Spring und dann auch am Ende durch Tomcat. Und das war diese Interaktion von den ich vorhin gesprochen habe. Und nachdem ich diese Stelle erstmal gefunden hatte und dann auch gesehen hatte, dass es dort eine Interaktion gibt, war ich schon mal ein, zwei Stunden damit beschäftigt das eben zu fixen. Aber es ist jetzt keine kontinuierlich, ständig wiederkehrende Tätigkeit, weil wir eigentlich eher auf der fachlichen Seite arbeiten und unsere Konfigurationen eher technisch sind und ich dann weniger mit dem Konfigurieren selbst zu tun habe.

R1: Wie viel Aufwand betreibt denn, sage ich mal euer Team, um initial eine Konfiguration für Tools, Frameworks und Infrastruktur und so weiter einzurichten?

I10: Also es ist eigentlich — ich weiß nicht, ob es überhaupt schätzbar ist, weil das eigentlich eher, das Projekt hat halt von einem kleinen Kern gestartet, da war halt wenig Konfiguration notwendig und ist mit der Zeit immer weiter gewachsen. Das heißt am Anfang war noch gar nicht absehbar, dass, welche Konfigurationsoptionen jetzt in Summe überhaupt notwendig sind um das System als solches eben zu einer Produktionsreife zu bringen. Ja, weiß ich nicht. Ne, kann ich nicht schätzen.

R1: Wie viel Aufwand betreibt ihr denn, wenn, also wenn es Versionsänderungen gibt oder andere konfigurationsabhängige Änderungen? Zum Beispiel von Spring Boot Version 1 auf 2.

I10: Also Majorsprünge hatten wir bis jetzt nicht. Wir versuchen halt während wir die Entwicklung jetzt machen in Bibliotheken Versionen immer mit nach oben zu nehmen. Also es sind die meisten mit denen wir jetzt zu tun haben, sind halt immer nur so Patchreleases. Ich weiß es halt, bei Vaadin passiert das regelmäßig, weil die halt recht häufig eben neue Versionen rausbringen und da wird dann eben im Zuge eines neuen Releases wird dann eben die Version eben noch angepasst. Und da sind jetzt auch in der Regel nicht notwendig um dann Dinge rückwärtskompatibel zu machen oder ähnliches oder was auch immer. Das heißt wir versuchen halt dann immer so an dem Zahn der Zeit auch zu arbeiten um einfach auf dem neuesten Stand zu sein um nicht mit irgendwelchen älteren Ständen weiterarbeiten zu müssen, die man dann halt auf lange Sicht hinaus dann eben auch pflegen zu müssen. Ansonsten, ich weiß von unserem Architekten, der auch die Releases baut, der macht dann alle drei Wochen, nimmt der sich dann eben zwei, drei Stunden Zeit um das alles zu machen. Da sind dann eben noch weitere Dinge notwendig, weil im Hintergrund dann natürlich auch Tests laufen müssen und der dann erzeugte Artefakte dann in Repositorys hochlädt. Da sind dann eben abseits dessen, dass er jetzt irgendeine Konfiguration anfässt, weitere Dinge notwendig, aber das funktioniert eigentlich in der Regel recht gut.

R1: Was ist denn für dich der größte Faktor, der den Konfigurationsaufwand bestimmt?

I10: Der größte Faktor? Ich interpretiere das mal ein bisschen weiter, ja? Also das ist im Sinne so, wenn ich mir Bibliotheken angucke, die Konfigurationsoptionen bereitstellen, ist für mich der größte Aufwand genau zu verstehen, was diese Option im Rahmen des Frameworks macht und in wie weit sich das auf die Anwendung und wie ich das Framework benutze, zurückspiegelt. Das ist sicherlich das, sagen wir mal so, der größte Aufwand das eben dann Spezifikationen lesen oder auch andere Problemfälle im Netz bei Stackoverflow oder anderen Webseiten um eben zu verstehen in wie weit, ja welchen Effekt im Grunde die Konfiguration auf meine Anwendung hat. Das wäre jetzt sicherlich, ich habe gerade vergessen, wo der größte Faktor — ja.

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

I10: Also ja, schon. Ich wüsste es jetzt nicht in konkret meiner Anwendung, so wie ich sie jetzt eben da habe. Ich weiß, dass die Dinge zusammenhängen. Ich kenne deine Arbeiten dazu, aber konkret von den Fällen und Projekten, die mir spontan dazu einfallen, jetzt so erstmal nicht, nein.

R1: Dann haben wir jetzt den letzten Part, es geht um Konfigurationsfehler und -probleme und so weiter. Und die erste Frage, stellt dich die Konfiguration von Systemen, Tools und Frameworks vor irgendwelche spezifischen Probleme?

I10: Nur, wenn das zu einem Zustand führt in dem die Anwendung nicht läuft, also dass ich keine Konfiguration finden kann, wo ich sage das läuft. Wir hatten so einen Fall. Da ging es halt darum, in Vaadin so einen Fileupload zu realisieren und da konnten wir keine Konfiguration finden aus Spring, was im Hintergrund verwendet wird, und Vaadin, sodass wir einen Multifile-Upload realisieren konnten. Das ist im Grunde ein Bug, der ist auch bekannt. Ich verfolge den weiter bis es dann eben von den Frameworks ein entsprechend neues Release dazu gibt, sodass wir die Konfiguration so einstellen können, wie wir sie brauchen.

R1: Kannst du vielleicht eins der schwerwiegendsten Probleme, oder was bei dir die meiste Zeit in Anspruch genommen hat bezüglich Konfiguration, nennen?

I10: Das war zum Beispiel so ein Fall. Da war ich einen halben Tag mit beschäftigt um das eben rauszufinden, um Fehlerreports auf GitHub zu lesen und versuchen das genau so nachzustellen und nachzuvollziehen, ob das Szenario, was wir bei uns haben und wie wir eben Vaadin und Spring verwenden, genau zu dem passt, wie es eben dort in der Fehlerbeschreibung beschrieben war, sodass ich eben sagen konnte okay, wir können keine gültige Konfiguration dafür finden.

R1: Was sind deiner Meinung nach die Ursachen für Schwierigkeiten in der Konfiguration, die man haben kann?

I10: Naja, dass es Interaktionen gibt, die nicht unbedingt auffallen. Also wie dieses Tomcat-Spring-Issue, was ich vorhin hatte. Da war mir halt am Anfang nicht klar, weil ich erstmal nur wusste okay, der Einstieg dessen, das was ich halt baue, an der Oberfläche auch sehe, ist halt Spring. Dass das wiederum einen Effekt hat auf das, was im Hintergrund, also da wird halt ein Tomcat-Server und der ist für mich zumindest als Entwickler auch nicht transparent zu sehen. Dass es da noch einen Effekt hat, sich daraufhin durchschlägt, war mir von Anfang an nicht klar. Und das war ein Problem.

R1: Was ist denn ein für dich schwer zu konfigurierendes Tool oder Framework und warum genau das?

I10: Ein schwer zu konfigurierendes Tool?

R1: Oder Framework.

I10: Also ich kenne nur unabhängig von dem, was wir jetzt halt tun, halt Werkzeuge für die ich es halt für mich schwierig fand, da mich reinzuarbeiten und sie halt zu verstehen, weil sie halt eine Menge Optionen bieten. Aber ich kann das zumindest nicht für den aktuellen Fall sagen.

R1: Ruhig auch deine Consultant-Erfahrung generell oder von deiner Entwicklungserfahrung mal.

I10: Ach naja, es gibt halt immer wieder Fälle und Beispiele, wo ich halt von Systemen sehe, wo ich halt denke die sind schlecht gemacht. Ich weiß von einem Beispiel, da hat man im Grunde FeatureIDE genommen, erweitert und im Rahmen eines Unternehmens eingesetzt und sich dort für eine Produktlinie eine ganze Menge an Konfigurationsoptionen erzeugt. Und das waren halt mehrere tausend Stück. Und hat sich am Ende gewundert warum man denen nicht mehr Herr wurde, weil das halt kein Mensch konfigurieren konnte, weil da halt die Abhängigkeiten der Optionen untereinander nicht mehr kannte. Die waren halt nicht explizit modelliert und damit war es eben sehr leicht möglich fehlerhafte Konfigurationen zu erzeugen. Das ist ein Beispiel. Ansonsten gibt es halt in der Regel immer sehr, sehr große Werkzeuge und Dinge, die halt versuchen im Hintergrund die Dinge sehr schlau zu machen, Werkzeuge, die halt nicht nach außen gleich durchschlagen, sind für mich halt schwierig zu fassen. Aber das hilft euch wahrscheinlich auch nicht so recht weiter.

R1: Was sind denn für den Konfigurationsfehler und wie unterscheiden die sich von normalen Bugs?

I10: Also ich würde nicht sagen, dass die sich unterscheiden, weil, wie ich sagte, Konfiguration gehört halt zur Anwendung mit dazu und eine Anwendung funktioniert eben als Ganzes nur, wenn eben die Konfiguration auch dazu passt. Jetzt irgendwo einen falschen Wert einzutragen, der eben variabel parametrierbar ist und dazu führt, dass die Anwendung nicht das tut, was sie soll, ist für mich ein Bug und für mich dann auch nicht davon zu unterscheiden zu dem, wenn ich zum Beispiel einen Algorithmus falsch implementiert habe.

R1: Selbst wenn der Wert eher die Infrastruktur betrifft?

I10: Na gut, das würde ich jetzt ausschließen. Ja okay, Environment ist ein guter Punkt, weil ich das Environment selbst nicht immer vollständig kontrollieren kann.

R1: Welche Auswirkungen von Konfigurationsfehlern sind denn eigentlich häufig nach deiner Erfahrung?

I10: Naja gut, so ein Beispiel wie dessen, dass ich — ich entwickel unter Windows und das System wird unter Linux getestet auf einem Setup und läuft aber unter einem zweiten Setup. (?43:33) dass halt, sagen wir mal, die Umgebung, wie zum Beispiel in Java, wie werden halt Pfade interpretiert, Slash, Backslash oder wie wird die Anwendung standardmäßig auf dem System, mit wie viel RAM wird das Ding hochgefahren oder ähnliches. Das schlägt sich halt durchaus durch, auch auf die Anwendung hinein. Wenn ich sie nicht explizit setze, muss ich eben mit dem Leben, was mir halt die Umgebung, also in dem Fall Windows oder Linux selbst, eben vorgibt. Das ist ärgerlich, weil etwas aufwändiger und schwieriger zu finden und man braucht halt ein recht gutes Verständnis um das zu sehen.

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

I10: Nein.

R1: Kannst du das begründen?

I10: Läuft in der Regel für mich auf das gleiche hinaus: Die Anwendung tut nicht, was sie soll.

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

I10: Also Bauchgefühl, einmal pro Sprint.

R1: Und sind die — okay, ihr seid sowieso gerade in der initialen Phase. Du kannst wahrscheinlich nicht abschätzen, ob das weniger oder mehr wird in der Maintenancephase, oder?

I10: Nein. Nein, kann ich nicht.

R1: Vielleicht noch von den älteren Projekten noch, mehr aus den Gedanken, gibt es generell Unterschiede bei diesen ganzen, weiß nicht, Häufigkeiten von Konfigurationsfehlern und so weiter, zwischen fachlicher und technischer Konfiguration?

I10: Also da kann ich es nicht sagen, weil ich da eher als Berater tätig war und nicht so Einblick in die Entwicklungsartefakte habe. Ich kriege das bisweilen so Anekdoten zu hören, dass es eben Änderungen an der Umgebung gab und dass dann halt Testfälle nicht mehr liefen oder ähnliches. Aber in wie weit die jetzt technisch oder fachlich bedingt waren kann ich nicht sagen.

R1: Ein bisschen hast du schon gesagt, aber vielleicht noch mal im (?46:30) oder strukturierter: Wie gehst du denn typischerweise vor um Konfigurationsfehler zu finden und zu beheben?

I10: Also in der Regel (?46:40), dass irgendwie eine Funktion nicht geht. Also ich habe halt eine Exception oder einen Error in meiner Anwendung. Die meisten Fehler mit denen ich jetzt zu tun hatte, hingen damit zusammen, dass entweder vom Webserver dann eine Fehlermeldung kam. Was weiß ich, ein 500 oder ein 404 oder ähnliches oder ein 401 zum Beispiel. Und ich dann anfangen konnte damit und dann eben zu wissen hey, ich habe zum Beispiel eine fehlerhafte Anfrage gestellt, dann halt zurückzugehen und dann halt weiter das abzufrühstücken. Ich mache es in der Regel dann halt so, dass ich halt unsere Logs durchgehe oder dann auch im Falle der Fehlermeldung selbst mir den Stacktrace anschaue um dann eine Debuggingsitzung zu starten um das eben runterzubrechen. Für den Fall, dass ich schon sehr, dass ich halt aus den Stacktraces eben herauslese, wie für den Fall, dass ich lade größere Dateien hoch als mir das Backend erlaubt, da konnte ich aus dem Stacktrace zum Beispiel herauslesen, dass dort eine Anpassung in der Konfiguration notwendig war, weil ich bei der initialen Umsetzung eines Features für den Dateiupload involviert war und dann wusste, dass ich dort eben Änderungen machen kann.

R1: Und wenn du hast ja auch vorhin gesagt, du liest dann auch mal bei StackOverflow und so weiter nach. [Zustimmung von I10] Gespräche mit Kollegen auch?

I10: Ja.

R1: Was ist so die Reihenfolge da? Also zuerst, du hast gesagt Logdateien, Stacks und dann?

I10: Also Fehlermeldung selbst durchgehen, Stacktrace, Debuggingsitzung — Debuggingsitzung, Stacktrace parallel zu online schauen — und in der letzten Instanz ist dann einen Kollegen dazu fragen.

R1: Habt ihr spezifische Strategien um Konfigurationsfehlern vorzubeugen?

I10: Nein.

R1: Was erwartest du denn von einer guten Dokumentation bezüglich Konfiguration?

I10: Also wenn sie in irgendwas vom Standard abweicht. Also Standard ist das eben, was ich aus Spezifikationen, Handbüchern herauslesen kann. Wenn es dort in irgendeiner Form konkret abweicht oder sich halt auf einen Fehler oder auf ähnliches bezieht, dann würde ich es an der Stelle, wo die Konfigurationsoption eben definiert worden ist, auch gerne sehen. Und deren Quereffekte auf weitere Konfigurationen, die wir innerhalb der Gesamtanwendung haben, eben auch.

R1: Also wenn jetzt zum Beispiel, müsste jetzt Spring Boot dokumentieren, dass es auf die Konfiguration von Tomcat Auswirkungen hat?

I10: Ja. Im konkreten Fall habe ich auch so gemacht, dass ich halt darauf hingewiesen habe, dass es eben zwei Fälle gibt. Also es betrifft im Grunde, im Falle von Spring Boot gibt es halt so eine application.properties, wo man eben verschiedene Einstellungen zum Verhalten von Spring Boot halt definieren kann. Und daran sind auch die Sachen, Konfigurationsoptionen involviert, die zum Beispiel für den Tomcatserver auf dem dann wiederum Spring läuft, eben im Hintergrund gemacht, auch mit drin stehen. Und an der Stelle hätte ich gerne gesehen, dass das zusammenhängt. Vielleicht habe ich es übersehen, aber ich musste mir das erst selbst erarbeiten. Und in unserem Fall ist das jetzt intern so dokumentiert, dass es da eine Interaktion zwischen diesen beiden Fällen gibt. Das sind drei Konfigurationsoptionen. Zwei beziehen sich auf Spring, eins bezieht sich auf den Tomcat-Server. Und dort gibt es dann eben von mir einen Kommentar dazu, der eben genau das umfasst, dass diese beiden miteinander interagieren.

R1: Hast du vielleicht ein Beispiel von einer guten Konfiguration, wo du vielleicht schonmal sowas gelesen hast oder so. Also von einer guten Dokumentation über Konfigurationsoptionen oder—

I10: Müsste ich nachschlagen, habe ich nicht spontan parat.

R1: Ja, welche Verbesserungen würdest du dir denn eigentlich wünschen hinsichtlich Konfiguration von Frameworks, Tools, Infrastruktur und deren Interaktion?

I10: Also dass sie explizit schon auf solche Fälle hinweisen. Denn im Grunde, also wenn es solche Interaktionen gibt — dann ist das halt schwierig jetzt sicherlich zu sagen, weil niemand genau weiß, wie sein Framework in welchen Umfängen jetzt das halt irgendwo eingesetzt wird und da kann es halt Interaktionen geben, die der Entwickler des Frameworks halt nie vorhersehen konnte, weil es einfach eine Kombination aus Frameworks oder sowas gibt, die er nie auf dem Schirm hatte. Kann es ja durchaus geben. Aber wenn es halt in manchen Fällen so bekannt ist und bekannt sein kann, wie, weil es ist einfach sagen wir mal, wie in diesem — ich weiß, wir bemühen das sehr oft —, aber wenn wir jetzt sagen wir nehmen dieses Tomcat und Spring Beispiel, dann hätte ich das schon gerne gesehen, dass es da zu sehen ist, weil im Grunde Spring auf Tomcat aufsetzt und dass es dort dann eben auch leicht widersprüchliche Konfigurationen geben kann, das hätte ich schon gerne gesehen.

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

I10: Weiß ich nicht. Also die Bibliotheken mit denen ich zu tun habe, die sind in der Regel was das angeht halt schon dokumentiert. Also, was diese Optionen machen. Wenn jetzt halt irgendwas nicht geht oder funktioniert, dann alle möglichen Fehlerfälle abzudecken und sagen ey, hast du vielleicht schon daran gedacht oder jenes könnte vielleicht unter Umständen helfen um halt noch ein bisschen außerhalb des Scopes zu denken und zu arbeiten. Heißt aber am Ende natürlich, dass es mehr Dokumentation gibt, die ich am Ende auch lesen muss. Aber vielleicht ist das so vielleicht eine Idee oder ganz sinnvoll. Ich meine, ich kenne es halt aus Handbüchern zu Haushaltsgeräten, da steht ja auch so drin, wenn du dieses und jenes siehst, wie hier leuchtet irgendwas, dann checke mal das und das und jenes. Das kann halt unter Umständen sicherlich schon helfen um dann vielleicht so ein bisschen so Denkanregungen zu geben und da fällt mir zumindest jetzt spontan nichts ein, dass ich sowas schon mal gesehen hätte. Für den Fall, dass irgendwas nicht geht und dass irgendwas nicht klappt, das wird immer erst dann sichtbar, wenn man halt, was weiß ich ich, von StackOverflow von anderen Leuten eben darauf hingewiesen wird, dass man vielleicht irgendwas falsch macht.

R1: Und jetzt zum Beheben, gibt es da was, was dir was helfen würde?

I10: Ne, nur die Zeit und lesen zu verstehen, warum, wieso, weshalb ich das Framework, Bibltiothek jetzt eben falsch verwende und was sich eben bei uns tun muss, dass das halt (?54:22). Für mich ist halt eine Zeitfrage.

R1: Und jetzt als letzte Frage, was würde dir helfen um deinen Fehlern vorzubeugen?

I10: Weiß nicht. Also wenn ich daran denke, dass die Webseiten haben in der Regel schon Dokumentation, die halt einem in der Regel halt so eine Empfehlung von der Standardkonfiguration machen. Wenn ich davon abweiche, dann ist es natürlich mein Problem und ich muss mich halt darum kümmern, dass es halt zueinander passt. Also fällt mir zumindest jetzt spontan nichts ein, was jetzt im Sinne von vorbeugen helfen könnte.