Fehler im Code finden (und vermeiden) // deutsch

[@JentaroYusong]

Wir gehen sehr ähnlich vor wie von dir im Video genannt. Generell arbeiten wir testgetrieben, das gilt auch für die Behebung von Bugs. Neben der technischen Fehlerursache versuchen wir häufig auch zu verstehen, wie es zu dem Implementierungsfehler kommen konnte; also wie wir solche Arten an Fehlern zukünftig verhindern können. Um Fehler besser Nachzuvollziehen nutze ich, falls denn notwendig, im Frontend (TypeScript, meist Angular) schlichtweg console.log. Auf Seiten des Backends nutzen wir Kotlin, hier greife ich auch auf den Debugger zurück, wo nötig. Generell ist beides aufgrund der hohen Testabdeckung glücklicherweise aber nur relativ selten von Nöten. :-)

[@thenativeweb]

[gr] Das hört sich insgesamt nach einem sehr guten Vorgehen an. Nicht nur nach den technischen Ursachen zu suchen, sondern auch zu hinterfragen, wie es überhaupt dazu kommen konnte, um zum Beispiel Missverständnisse ausräumen zu können, finde ich ebenfalls sehr gelungen 😊

[@ettoreatalan8303]

Ist Code, der selbst für eine(n) erfahrene(n) EntwicklerIn nur noch schwer verständlich ist, nicht ein Hinweis auf zu wenig Clean Code?

[@thenativeweb]

[gr] Ja, würde ich schon sagen. Denn wenn Code nur schlecht verständlich ist, ist er nicht so gut strukturiert, wie er sein sollte - und dann lässt sich das häufig etwas verbessern, indem man Clean-Code-Kriterien anwendet 😊

[@17plus9]

Vielleicht mal ein Video zu REPL machen.

[@thenativeweb]

[gr] Du meinst, zum Konzept der REPL, wie es zum Beispiel die Grundlage von Lisp darstellt, oder zur konkreten REPL einer bestimmten Programmiersprache?

[@17plus9]

@@thenativeweb Allgemein, aber kommt ja demnächst.

[@thenativeweb]

[gr] Morgen früh ist es soweit 😊

[@SeoOderNichtsein]

Ohne TDD ist eine komplexe Software mit mehreren Entwicklern meiner Meinung nach nur sehr schwer wartbar und mit steigender Komplexität auch immer schwieriger erweiterbar. Gerade bei monolithischer Entwicklung (Wie sie leider noch viel zu oft gemacht wird) kommt man irgendwann an den Punkt an dem jede Änderung oder Erweiterung durch interne Abhängigkeiten und asynchrone Prozessketten ggf. unvorhersehbare Folgen haben kann. Ohne Tests wird das immer eine Bananensoftware (Reift beim Kunden). Mir persönlich ist TDD aber nicht genug. Ich bin ein großer Freund von Tracing-Klassen und einem Debug-Mode. Und wenn ich den Debug-Mode über einen Parameter oder eine Methode aktiviere, dann erwarte ich, dass zwischen der Aktivierung und der Deaktivierung alle Aktionen in einer Datenbanktabelle protokolliert werden. Das bedeutet für mich alle Seiten-, API- und Methodenaufrufe mit allen Parametern. Bei Konstrukten mit mehreren verteilten Diensten in verschiedenen Containern oder bei asynchronen Abläufen hat sich diese Vorgehensweise schon mehrfach bezahlt gemacht. Wenn man das schon bei der Planung der Software und der Schnittstellen berücksichtigt, dann kann man einen Hash von Anfang bis Ende durchschleifen und hat alle Zwischenschritte von der Anfrage bis zum Ergebnis. Selbst bei Multithreading oder Queues oder komplexen auf mehreren Hosts verteilten Diensten kann man alles ohne Probleme einem Aufruf oder einem Task zuordnen. Berücksichtigt man dieses Prinzip bis in das Frontend hinein, dann hat man z.B. beim CQRS den kompletten Ablauf vom Klick eines Buttons bis zum asynchronen Ergebnis irgendwann. Und selbst wenn das ganze über mehrere Formulare oder Seitenaufrufe zwischen dem Client hin und her geht, hat man trotzdem noch eine eindeutige Zuordnung zu einem Prozess. Wenn man sich dann ein kleines Tool schreibt, dass diese Datenflut aufbereitet und über Filter und Sortierfunktionen leicht verständlich ausgibt, dann kann man schon in den Daten eingrenzen in welcher Klasse etwas schief gelaufen sein muss. Ein schöner Nebeneffekt dieser Vorgehensweise ist die Reproduzierbarkeit einer Benutzereingabe. Man hat ja jede Kleinigkeit in einer Datenbanktabelle und kann es automatisiert wieder ablaufen lassen. Also hat man einen komplexen Test für einen kompletten Ablauf, der über simple Unit- und e2e-Tests hinaus geht.

[@thenativeweb]

[gr] Ja, das stimmt - wobei ich nicht unbedingt so weit gehen würde zu sagen, dass das zwingend in einer Datenbank festgehalten werden muss, da das die Performance ja unter Umständen auch massiv beeinflusst. Aber generell alles mit-tracen, kann durchaus sehr hilfreich sein, und gerade das Nachvollziehen können, was auf Grund einer Eingabe passiert ist, ist oftmals Gold wert. Das geht ja auch in Richtung Event-Sourcing, zumindest in einem gewissen Sinne. Wer das übrigens auch schon so gemacht hat, war id.software in Doom: Auch dort wurden alle Eingaben protokolliert, so dass man sie replayen konnte - was unter anderem zum Debuggen recht praktisch war, was man von John Carmack zu dem Thema so hört und liest 😊

[@SeoOderNichtsein]

@@thenativeweb Wenn du es nicht in einer Datenbank ablegen würdest, wie würdest du es anders lösen, wenn es um verteilte und teils asynchrone und/oder parallele Prozesse auf mehreren Hosts geht? Das wäre doch auch mal ein cooles Video. Eventuell in Kombination mit dem Elastic Stack :)

[@thenativeweb]

@@SeoOderNichtsein [gr] Vielleicht war's blöd formuliert - was ich meinte war, dass sich die Anwendung nicht selbst darum kümmern sollte, sondern dass sie erst mal irgendwohin loggt, zum Beispiel auf die Konsole. Dass man das dann von dort abnimmt und irgendwohin weiterreicht, wo es persistiert wird, ist richtig und sinnvoll, man muss nur natürlich trotzdem aufpassen, dass das von der Performance her hinterherkommt 😉 Das Thema "verteiltes Logging", evtl mit ELK-Stack, wäre aber tatsächlich eine gute Idee 👍

[@christianhorauf9958]

Ich werde dafür angemeckert, das ich keinen Debugger nutze. Ich muss aber auch zugeben, das ich auch nur bedingt Ahnung davon habe wie ich den vsc Debugger anbinde. console.log kommt aber doch rinem Debugger gleich... Ich bin zwar nicht so gut, das ich auf console.log verzichten könnte würde aber folgenden sprich unterschreiben: wer einen Debugger benutzen muss, versteh seinen eigenen Code nicht.

[@17plus9]

console.log() ist ein Antipattern.

[@thenativeweb]

@@17plus9 [gr] Hm … also in Produktivcode würde ich das auch nicht haben wollen (deshalb ist es bei uns auch per Linter verboten), aber zur Fehlersuche finde ich es manchmal durchaus praktisch.

[@thenativeweb]

[gr] Was (theoretisch) an einem Debugger ein cooles Feature ist, ist so was wie Back-In-Time-Debugging, also dass man ab einem Breakpoint nicht nur vorwärts, sondern auch rückwärts steppen kann, um die Ursache zu finden. Praktisch braucht man das dann aber zugegebenermaßen doch eher selten. Was ich so oder so aber nicht in Ordnung finde, ist, dass Du dafür angegriffen wirst - letztlich muss doch jede Entwicklerin und jeder Entwickler die Werkzeuge für sich selbst entscheiden.

[@christianhorauf9958]

@@thenativeweb erst vor kurzem war ich an einem Projekt beteiligt, wo ich zum ersten Mal angular und ngrx im Einsatz hatte. Damit hätte man vermutlich auch backintime debugging machen können, der Hauptgrund, warum ich mich für Redux interessiere. Aber leider haben wir uns zum eben dazu entschieden quasi nur pro Unterseite den store upzudaten, so dass wir also bestenfalls diese Änderungen hätten nachverfolgen können, zum anderen hat der Technical Lead nicht erkannt, dass wenn wir uns diese protokolle vom user hätten schicken lassen, daß wir dann auch jeden bug der in zukunft irgendwann mal aufkommen mag hätten leicht debuggen können. Hast du vielleicht schon eine Folge über Redux gemacht und kann man mit den react hooks vielleicht auch den Redux Debugger nutzen?

[@thenativeweb]

@@christianhorauf9958 [gr] Das mit den Hooks kann ich Dir leider aus dem Stegreif nicht beantworten, aber zu Redux gab es schon mal zumindest eine halbe Folge: kzbin.info/www/bejne/pZPHfoSarthmgK8 Und ja, Deine Überlegungen waren genau richtig: Denn letztlich macht man da Event-Sourcing, und das wiederum kann man wunderbar unter anderem für Debugging verwenden 😊