Über verschiedene Möglichkeiten der Qualitätssicherung bei der Softwareentwicklung spreche ich mit Christian Kranert in der einhundertvierundsechzigsten Episode des IT-Berufe-Podcasts.

Podcast: Play in new window | Download (Duration: 1:15:19 — 31.8MB)

Abonnieren: Apple Podcasts | Spotify | RSS

Inhalt

Allgemeines zur Person

• Wie ist dein Name und wo arbeitest du (falls gewünscht)?
  • Christian Kranert, 31 Jahre alt, Nürnberg, ich arbeite bei der Head-on Solutions GmbH.
  • Wir entwickeln eine Software zum Cloud Management für Frisöre, Kosmetikstudios usw. für eine moderne Organisation: Terminbuchung, Kasse, Marketing.
  • Wir sind eine rein interne Entwicklungsabteilung.
• An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?
  • Die Software, die ich mit meinem Team der Head-on Solutions GmbH entwickle: studiolution.
• Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?
  • Ich war schon immer fasziniert von Computern und hatte mit 12 Jahren meinen ersten eigenen PC
  • Darauf habe ich schnell ein erstes Programm erstellt mit Visual Basic 6.
  • Ich habe mir nie erträumt, ohne Studium programmieren zu können.
  • Zum Einstieg habe ich „Hello World“ programmiert und danach einen Paint-Klon.
• Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?
  • Nach der Schule (die war nervig, weil ich schon wusste was ich will) habe ich die Ausbildung zum Fachinformatiker Anwendungsentwicklung gemacht.
  • Ich bin in der Automobilindustrie gestartet und habe bei der Brose Group eine sehr gute Ausbildung bekommen. Die hatten 200 Leute in der IT und ich konnte viele Abteilungen durchlaufen. Dort habe ich viel gesehen und gelernt.
  • Ich bin gestartet mit der SAP-Entwicklung, aber parallel habe ich mit .NET begonnen.
• Mit welcher/n Programmiersprache/n arbeitest du im Alltag?
  • Im Backend setzen wir auf C# in Kombination mit dem SQL Server.
  • Im Frontend setzen wir JavaScript ein, aber in Form von TypeScript. Für HTML/CSS nutzen wir SASS als Präprozessor.
  • TypeScript mag ich wegen der Typisierung.
• Was ist deine Lieblingsprogrammiersprache und warum?
  • ABAP habe ich in SAP zwar auch gemacht, aber C# ist meine Lieblingssprache. Ich mag die Typisierung und viele Features, die konsistent umgesetzt sind.
  • Java habe ich mir angeschaut für die SAP-Entwicklung.
  • Ich bin kein Freund der „religiösen“ Gefolgschaft von Programmiersprachen.

Qualitätssicherung bei der Softwareentwicklung

• Warum sollten wir uns überhaupt Gedanken zur Qualitätssicherung machen?
  • Das ist eine gute Frage, die man oft im Alltag beantworten muss, z.B. bei Diskussionen mit Kunden oder dem Chef.
  • Vergleich mit der Industrie: Teile müssen „perfekt“ sein, der Kunde soll am Ende glücklich sein.
  • Bei Software ist es genauso: das Release soll den Kunden zufrieden stellen.
  • Ansonsten muss man nachbessern und hat unzufriedene Kunden.
  • Die Behebung von Fehlern ist sehr teuer im Nachhinein.
  • Außerdem ist Kosteneffizienz und Mitarbeiterzufriedenheit wichtig für das Unternehmen.
• Welche Maßnahmen gibt es grundsätzlich zur Qualitätssicherung?
  • Wir setzen auf eine Art Stufensystem. Je früher Fehler behoben werden, desto billiger ist es.
  • Das beginnt beim Entwickler: wir haben eine Entwicklerselbstkontrolle, Stichpunkte, die die Entwickler:innen selbst durchgehen, z.B. Diff checken vor dem Commit. Das machen wir extra in einem externen Programm, damit eine andere Schriftart für eine andere Denkweise sorgt und Flüchtigkeitsfehler, vergessener Debugcode etc. vermieden werden.
  • Danach kommen die Unit-Tests, die die Entwickler:innen selbst schreiben.
  • Dann folgt ein Code Review durch eine andere Person.
  • Und zuletzt kommt noch ein manueller Test.
• Welche technischen Maßnahmen zur Qualitätssicherung gibt es auf Ebene einzelner Commits?
  • Die genannte Entwicklerselbstkontrolle.
  • Regelmäßige Routinen aus Checklisten sind auch in der Industrie gängig, dort haben wir das abgeschaut.
  • Das nimmt Komplexität aus dem Prozess und führt zu weniger „Mental Load“.
  • Wir haben auch weitere Checklisten, z.B. für Releases etc.
• Wo sind die Checklisten abgelegt?
  • Wir haben den DevBuddy, unsere interne Entwicklungsplattform für die Ablage. Dort haben wir auch mit HTML/JavaScript einen „Fortschrittsbalken“ gebaut, um ein wenig Gamifaction einzubauen.
• Wann und wofür verwendest du welche Tests: Unit-Tests, Snapshot-Tests, manuelle Tests?
  • Wir setzen kein TDD ein, die Mehrheit im Team glaubt nicht daran.
  • Aber unser Code muss immer mit Tests abgedeckt werden, auch wenn die Tests erst nach dem Code geschrieben werden.
• Warum setzt ihr nicht TDD ein?
  • Wir entwickeln agil und auch bei der Konzepterstellung wirkt das Team mit.
  • In diesem Prozess wird gerade zu Beginn viel am Code angepasst, daher hemmt TDD uns eher, z.B. bei Prototypen, bei denen der Test erstmal nicht implementiert wird.
  • TDD ist aktuell einfach nicht zuträglich, aber wir haben es auch nur einmal ausprobiert.
• Achtet ihr auf die Code Coverage?
  • Sie wird noch nicht automatisch ermittelt, geht aber mit Visual Studio ganz gut.
  • Bei der Line-/Branch-Coverage peilen wir 95% an. Durch wenig Boilerplate-Code schaffen wir das auch.
• Wie (gut) lassen sich Code Reviews in den Entwicklungsprozess integrieren?
  • Bei uns wird jede Zeile geprüft, alles braucht ein 4-Augen-Prinzip.
  • Direkt nach Implementierung folgt das Review, niemand darf länger als einen Tag entwickeln ohne Review.
  • Bei anderen Unternehmen wird oft nur über die Findings gesprochen und dann aber nichts gemacht. Wir erzwingen aber die Änderungen aus dem Review.
• Macht ihr das auch mit Checklisten?
  • Ja, aber sie dienen nur zur Einarbeitung neuer Kolleg:innen. Danach sind die Konventionen dann bekannt.
  • Alle Mitarbeiter machen ein Code Review, sogar Praktikanten bei erfahrenen Entwicklern. Das fördert die Teamkultur: viel und häufiges Feedback. Die Kritikfähigkeit wächst dadurch stark.
• Macht ihr Pull Requests? Oder wo/wie läuft das Review?
  • Das Review wird direkt auf dem Branch durchgeführt. Durch eine Verknüpfung zwischen Work Items und Commits geht das sehr gut.
  • Wir überlegen gerade, Pull Requests einzuführen, aber wegen der kurzen Zyklen hätten wir dabei wohl zu viel zu mergen.
• Wie sieht das Ergebnis der Reviews aus?
  • Die Findings werden im persönlichen Gespräch geklärt. Kleinigkeiten werden auch direkt von Reviewer gefixt, abhängig von Skill des Gereviewten (z.B. Flüchtigkeitsfehler).
  • Eine Diskussion über mögliche Alternativen geht persönlich besser und die Begründung ist enorm wichtig, da nur so ein Diskurs und eine bessere Lösung entsteht.
• Dann ist aber viel Zeit für Gespräche nötig, oder?
  • Kurze Wege sind dafür unbedingt nötig! Das Review muss beim Team akzeptiert sein und die Arbeitszeiten müssen zusammen passen.
• Dann kommen die manuellen Tests?
  • Unser Ziel ist die Automatisierung, aber komplett wegkommen werden wir nicht von den manuellen Tests. Sie decken Dinge auf wie Wording oder fachliche Fehler (z.B. negative Umsatzsteuer).
  • Manuelle Testfälle werden bei uns schon von den Entwicklern erstellt, da Tester den Code nicht kennen.
  • Jeder Entwickler ist verpflichtet, Tests zu formulieren, weil sonst Tests „verloren gehen“.
  • Ursprünglich haben wir das mit Excel gemacht, jetzt haben wir DevBuddy um ein Testtool erweitert mit Testrunner für ein wenig Gamification.
  • Das fördert auch die Kommunikation mit dem Kunden.
• Und dann sind wir schon beim Release?
  • Ja, danach kommt das Deployment, aber wir sind dann noch nicht fertig! Stichwort: Exception Logging.
• Wie behandelt/protokolliert ihr Laufzeitfehler?
  • Wir haben eine ganz einfache Methode: ein globaler Exception-Handler schickt Stacktraces per Mail an ein Postfach, das rotierend von Entwicklern beobachtet wird.
  • Das motiviert die Mitarbeiter, Fehler zu vermeiden/beheben.
  • Vorteile des Postfachs: man kann die Mails einfach weiterleiten und viele Infos transportieren.
  • Eigentlich war die Lösung nur ein Provisorium, aber inzwischen bleiben wir gerne dabei.
• Wie integrierst du Fehlersuche und Bugfixing in deine Arbeit?
  • Die Fehlerbehebung ist bei uns nur in bestimmten Phasen möglich, viele Fehler sind nicht „dringend“.
  • Teilweise beschäftigen wir uns wochenlang nicht mit Fehlern. Wir bündeln sie stattdessen und bearbeiten sie z.B. in separaten Sprints.
  • Wir legen den Fokus entweder auf Fehler oder die Entwicklung.
  • Fehler sind sehr teuer und müssen vermieden werden.
• Wer dokumentiert die Software und wann ist der beste Zeitpunkt dafür?
  • Viele Entwickler mögen Dokumentation nicht, aber sie ist das wichtigste Instrument, um Komplexität im Griff zu halten.
  • Wir entwickeln eine komplexe Anwendung mit vielen Teilen und Schnittstellen.
  • Daher ist Dokumentation enorm wichtig, weil man als Entwickler viel vergisst in 2-3 Monaten nach der Implementierung.
  • Das läuft bei uns auch im DevBuddy mit plain HTML, da unsere FullSTack-Devs damit gut klarkommen. Das ist selbst gestaltbar (Code-Highlighting, TOC etc.) und eine recht angenehme Arbeit. Außerdem befolgen wir die Idee des „eat your own dog food“.
  • Dokumentation muss schnell und kurzfristig erfolgen, da man sonst wieder viel vergisst. Die Dokumentation sieht anders aus, wenn sie erst rückblickend geschrieben wird.
  • Das zentrale Problem ist: Entwickler:innen werden dabei rausgerissen aus der Entwicklung (Flow), wenn sie sich zwischendruch und Dokumentation, Rechtschreibung usw. kümmern müssen. Das ist ineffizient durch einen nötigen Kontextwechsel im Gehirn.
  • Während des Codens werden daher nur Stichpunkte erfasst, damit es schnell geht. Die werden dann später ausformuliert.
• Welche Rolle spielen Best Practices und Pattern bei dir?
  • Im Rahmen des Produktkonzeptes wird das bei uns mitgemacht.
  • Wir bekommen nur lose Vorgabe aus dem Fachbereich, um das zu lösende Problem zu zeigen.
  • Die konkrete Lösung wird dann vom Team geschaffen und dabei wird die Architektur festgelegt.
  • Wir verwenden zwei Arten von Mustern: Design Pattern und Company Pattern, die wir selbst „gefunden“ haben für immer wieder auftretende Probleme.
  • Das kürzt die Kommunikation ab, denn jedem im Team sind die Pattern klar. Dadurch müssen nur nicht abgedeckte Bereiche diskutiert werden, wobei schon Namen von Methoden festgelegt werden usw.
• Wie gelangst du zu Konventionen, die vom gesamten Team mitgetragen werden?
  • Das Team legt die Pattern gemeinsam fest. Irgendjemandem fällt etwas auf und es gibt dann einen Impuls ans Team. Meist sind zwei verschiedene Lösungen für ein Problem der Anlass.
  • Beispiel: Es gibt viele Einstellungen in unserer Software, z.B. Default-Einstellungen vom Hersteller und Kunden-Einstellungen, die davon abweichen. Wie fragt man das im Code ab? Dieses Problem wurde nur einmal gelöst (das war gar nicht so einfach) und das Ergebnis ist unser Settings-Pattern, das seitdem fast überall genutzt wird und viel Erleichterung bringt.
• Welche Tipps zum Umgang mit wachsender Komplexität hast du?
  • Alle obigen Maßnahmen zahlen darauf ein, Komplexität zu vermeiden.
  • Komplexität ist eine große Gefahr bei großer Software. Sie wird schnell zu groß, die Entwicklung dauert dann länger und macht keinen Spaß mehr.
  • Unser Mantra ist: Keine unnötige Komplexität! Das gesamte Team muss Komplexität richtig hassen, auch im Kleinen, da sie schnell wachsen kann.
  • Beispiel: Schon ein ungünstiger Variablenname zählt dazu, lässt sich aber leicht beheben.
  • Diese Idee muss man tief im Prozess und im Team verankern.
  • Jede Erweiterung der Software führt zu mehr Komplexität.
  • Aussagekräftige Namen sind ein großer Hebel gegen unnötige Komplexität, denn sonst kann es zu aufwändigen Umbenennungen kommen.
• Wie gehst du mit Legacy Code um, der (noch) nicht den Qualitätsanforderungen entspricht?
  • Bevor wir die Software übernommen haben, wurde viel extern entwickelt. Seit 5 Jahren entwickeln wir nun inhouse, aber es ist noch viel Code von früher übrig, der nicht den Pattern entspricht.
  • Daran wird nicht weiter entwickelt, sondern er wird in die „neue Welt“ überführt, was eigentlich immer einen Rewrite bedeutet.
  • Auch alte Anwendungen müssen sich weiterentwickeln, da die Kunden neue Anforderungen haben.
• Refactoring oder Rewrite: Worauf achtest du bei der Entscheidung?
  • Rewrites machen wir eigentlich immer für nicht selbstgeschriebenen Code. Für der Erfolg ist aber wichtig zu wissen, wie man es grundsätzlich besser machen kann.
  • „Nur“ neu machen reicht nicht aus! Das ist kein Grund für einen Rewrite.
  • Ein Mittelweg ist auch möglich: nur ein Teil des Codes zieht um, wird refaktorisiert und Konventionen/Pattern werden eingeführt.
  • Reine Refactoring-Releases werden bei uns vermieden. Es muss immer der Mehrwert für den Benutzer erkennbar sein.
  • In den letzten 5 Jahren gab es max. drei Releases mit reiner Technik.
• Haben wir noch Themen vergessen, die wir unbedingt besprechen sollten?
  • Das Team ist am wichtigsten! Nach 13 Jahren ist das eine zentrale Erkenntnis. Nur gemeinsam kommt ein gutes Ergebnis raus!

Aus- und Weiterbildung

• Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen?
  • Wir sind IHK-Ausbildungsbetrieb, haben aber erst einen Azubi (FIAE) komplett ausgebildet.
  • Die dauerhafte Ausbildung ist aber in Arbeit, wir sind noch in der Findungsphase.
  • Meine eigene sehr gute Ausbildung bei der Brose Group (Fahrzeugteile) in Coburg ist jetzt auch mein eigener Anspruch.
  • Wir haben eine Kooperation mit der Hochschule Nürnberg. Jedes Semester haben wir Praktikant:innen für ein Praxissemester, wovon beide Seiten profitieren!
• Hast du Tipps für Ausbilder/-innen im IT-Bereich?
  • Viel Praxis! Kurze Theoriephase, dann früh ran ans echte Produkt! Es sollen alle Prozesse mitgemacht werden, insb. Code-Reviews usw.
  • Viele Erfolgserlebnisse gerade zu Beginn sind wichtig.
  • Feedback am Ende des Praktikums ist immer gut.
• Welche Quellen kannst du für die Aus- und Weiterbildung im Bereich Programmierung empfehlen und warum?
  • Das ist bei mir ein bunter Mix, für bestimmte Themen sind aber Bücher gut geeignet.
  • Das Buch Clean Code* hat mir am meisten gebracht.
  • Ich bin auch großer Fan von Videokursen, wie z.B. Pluralsight* und Rheinwerk*.
  • Wir haben Premium-Accounts bei Pluralsight für alle Entwicker:innen. Das ist auch hilfreich für Praktikant:innen.
  • Wir haben z.B. den Bedarf aus einem konkretem Projekt an VueJS direkt über einen Kurs auf der Plattform gelöst.
  • Am besten lernt man aber wohl „am lebenden Objekt“.
  • Auch die Effizienz durch die Kurse ist besser, als wenn Kolleg:innen das alles selbst erklären.

Abschluss

• Haben wir noch etwas vergessen?
  • Wir haben aktuell nur (männliche) Entwickler in unserem Team, aber diverse Teams sind sehr wichtig!
  • Wir hätten gerne mehr Entwicklerinnen! Also nichts wie los und bewerben!
• Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?
  • Am besten bei LinkedIn.

Literaturempfehlungen

Ein sehr empfehlenswertes Buch laut Christian ist Clean Code von Robert C. Martin*. Es ist sprachunabhängig und vermittelt viele grundlegende Techniken, um Code qualitativer zu machen.

*

Bei Pluralsight* hat sein ganzes Team Accounts. Dort kann man professionelle Videokurse zu zahlreichen Technikthemen (auf Englisch) absolvieren.

Auch beim Rheinwerk-Verlag* gibt es hervorragende Literatur und Videokurse (auf Deutsch).

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Christian Kranert bei LinkedIn
• studiolution
• Brose Group bei LinkedIn