Oder oder fragst dich dann nach einer halben Stunde, was gucke ich mir eigentlich an? Weißt du Coding Buddies, Dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich Willkommen Halli Hallo, da sind wir wieder, die Coding Buddies Dein Podcast rund um die Softwareentwicklung schön, dass du wieder eingeschaltet hast. Mein Name ist Tino und an meiner Seite wie immer der fantastische Fabi, den ich jetzt begrüßen mag Fabi, herzlich willkommen, was geht ab Hallo Tino.
Was geht ab? Ich hab gehört, das ist jetzt mal ne irgendwie, die Einleitung ist anders gewesen bei dir, die war neu. Bist du verwirrt? Also kannst du trotzdem weitermachen oder müssen wir neu starten? Lass neu starten. Nein. Nein, ich find es gut.
Also mich hätte es jetzt angesprochen, wenn ich jetzt diesen Podcast habe, frischen Wind reinbringe weißt du, wollen wir mal frischen Wind reinbringen, weil wir nähern uns ja und jetzt kommt es, ich hab nämlich gesehen, wir nähern uns der 100. Folge es dauert noch ein bisschen liebe, zuhören, Liebe zuhören. Es dauert noch n bisschen, aber bald aber bald. Ich bin gespannt, Einstein, ich bin gespannt was dann passiert ab 9 und. 90 ist. Schluss. Ja genau die würden hier rauskommen.
Na gut, Spaß beiseite, ich hab n cooles Thema mitgebracht, oh da würde ich auch direkt reinstarten, weil da bin ich mal gespannt wo wo es uns hintreibt bei diesem Thema und was so unsere Points am Ende sind dazu ich hoffe keine Paint points. Und zwar geht es darum, dass wir ja schon öfter über Codequalität gesprochen haben, über Peer Programming, Test Driven Development, über verschiedene Praktiken.
Und darin gibt es eigentlich immer so n Teilbereich, den wir noch nicht richtig beleuchtet haben, und zwar das Review im Speziellen, in unserem Fall das Code Review und darüber würde ich gerne mit dir heute sprechen.
Was ist ein Code Review? Warum macht man Code Reviews und wie es deiner Meinung nach so ablaufen könnte, das ist ja hat ja auch was subjektives, kann man schon mal vorwegnehmen, aber was so quasi aus unserer Erfahrung heraus so Best Practices sind, dass wir das heute mal einfach beleuchten, ja finde ich gut, ist auch tatsächlich finde ich ein sehr sehr spannendes Thema, weil ich zum Beispiel.
Sagen wir mal am Anfang. Dachte ich mir im Code Review ist halt Code Review. Du guckst dir halt Code an und sagst dann OK, ich Merch sozusagen die Änderung rein oder nicht oder was auch immer ne aber dass da eigentlich noch viel viel mehr dahinter steckt oder dass man da sehr viel ins Detail gucken sollte, könnte und da halt auch wie gesagt Best practices da sind, das war mir auch ne, also vor einigen Jahren nicht bewusst so. Und deswegen finde ich das gut.
Also ich glaube, dass das wie auch bei mir beispielsweise auch so ein paar Sachen, wenn man darüber mal ein bisschen nachdenkt, auch einem dann klar wird, so okay, das Macht schon Sinn, wenn man es nicht schon weiß. Ja, du hattest ja jetzt schon so ein bisschen angefangen zu definieren, was ein Code Review ist. Vielleicht sollten wir da mal ganz, ganz vorne anfangen, quasi für denjenigen zuhören und Zuhörer, die vielleicht noch kein Code Review gemacht haben oder sich darunter nichts
vorstellen können. Also am Ende kann man sagen, es ist eigentlich ganz formal gesehen ein Prozess. Prozess ist auch so ein tolles Wort, jetzt sind sie alle abgeschreckt, aber ganz so schlimm ist es nicht im Prinzip,
wie du meintest mit Änderungen. Ich habe einen Entwickler der eine Änderung in der Software einbaut und der Prozess des Reviews dahinter ist, dass dieser Entwickler sagt Okay ich habe eine Änderung vorgenommen und andere Entwicklerinnen oder Entwickler aus dem Team. Gucken sich diese Änderung an, reviewen sie also quasi die Änderung und geben dann quasi ein Feedback dazu. Genau.
War ganz verallgemeint. Theoretisch kann es also ein Feedback ist immer erstmal gut an der Stelle und das Resultat von so einem Code Review kann ja am Ende sein.
OK, du hast Änderungen am Code gemacht und die lasse ich zu als 4 Augen Prinzip. Diese dürfen rein in den Code, so wie sie sind, also sozusagen alles super, oder es gibt vielleicht so ein paar Anmerkungen, Verbesserungsvorschläge, dass man erst sagt, vielleicht wäre es gut, wenn wir das erstmal vorher angehen oder du das noch mal ausbesserst und dann mergen wir es rein in den Code. Oder dann wird es halt in die Code Basis integriert.
Genau, denn so ein Review kann halt auch zyklisch sein, das heißt es kann mehrere Runden haben, das heißt es kommt die Änderung ich Review, das habe eine Anmerkung dazu, Hey. Zeile XY da wäre das und das zu beachten. Magst du das nicht vielleicht noch anpassen oder wie wäre es mit der und der Änderung statt der die gerade drin ist? Dann geht das zurück, dann so ja hast du recht, das können wir cooler machen, ich änder das um und du kriegst es noch mal.
Guckst es dir an und sagst ja jetzt Mensch wirklich tutti ne so können wir das jetzt reinhauen und dann ist das Review im Prinzip abgeschlossen, wenn Entwickler A der die Änderung gemacht hat sagt. Das ist meine Änderung, so würde ich es machen. Das ist richtig so. Mal ist grün für ihn und der Reviewer sagt Okay ja, für mich ist das auch Grün. 4 Augen Prinzip wie du gerade meintest. Jetzt kann die Änderung in die Codebasis integriert werden.
Genau also prinzipiell, und das kann man ja vielleicht auch noch mal bisschen weiter fassen, ist natürlich ein Code Review an sich ein Prozess sozusagen, wie man sozusagen Code reviewed, wie man dann entscheidet, ob, wie du es gerade beschrieben hast, auch vielleicht in einem gewissen Zyklus dann. Der Code dann integriert wird in die Codebasis oder nicht.
Man muss dazu sagen, dass natürlich n Code Review auch im weiteren Sinne ist, natürlich auch für Anfänger geeignet oder Anfängerinnen im Bereich der Softwareentwicklung, weil es natürlich nie verkehrt ist. Auch wenn jetzt kein Code irgendwo integriert werden sollte, aber auch mal zu sagen, OK, ich hab hier Code geschrieben und könnte vielleicht irgendjemand mal den ich kenne diesen Code angucken und mir Feedback darüber geben, also so ne Art Code Review zu
machen. Und das zählt auch irgendwo unter Code Review. Meiner Meinung nach ist aber natürlich nicht im Arbeitskontext dann zu sehen, logischerweise ja. Das ist auch ein sehr guter Punkt, weil ganz früher zur Studienzeit, sage ich mal, habe ich unterm Code Review auch eine gewisse falsche Vorstellung gehabt. Also mir war zwar klar, was der Sinn dahinter ist, aber wie es eigentlich gelebt werden sollte, war mir nicht so klar, oder ich habe es mir falsch vorgestellt,
weil man. Darf das jetzt nicht vergleichen mit der Schulzeit zum Beispiel, dass ich sozusagen ne Änderung mache, was n Test ist. Und ich hab jetzt n Test geschrieben und jemand geht mit n Rotstift drüber und sagt falsch richtig falsch falsch, das ist ja kein Review am Ende, sondern Review ist ja so gesehen ein Dialog zwischen.
Der Person, die es geändert hat oder Neues hinzugefügt hat und der Person, die sich das anguckt und ja überprüft, aber nicht im Sinne von nee, nee, nee, sondern noch mal ne Meinung dazu gibt und n Feedback halt ja, also kurz gesagt Review ungleich Korrektur ja genau das ist schön gesagt, genau weil genau ja da kann ich nichts hinzufügen, super. Und da kann man auch an der Stelle auch noch mal sagen, dass wir ja auch das Format Review The Code, aber Rescue the Code
bei uns haben. Das heißt, du Liebe Zürerinnen oder lieber zürer, du kannst uns auch Code zukommen lassen, wir haben dann immer so bestimmte Runden, die wir starten, wo man dann, wo ihr dann oder wo du uns Code zukommen lassen kannst und wir reviewen das Ganze dann geben, dann konstruktives
Feedback und. Machen daraus auch dann noch ein paar Videos für die gesamte Community so viel mal da am Rand, denn das ist schon ein wichtiger Punkt, um mal darauf einzugehen, warum macht man überhaupt Code? Reviews ist ein wichtiger Punkt halt auch ja, dass man daraus lernen kann, also dass du wissen verbreiten und bereitstellen kannst und so im Prinzip als gesamtes Team auch dran wächst und vor allem auch als Entwicklerinnen und Entwickler.
Also diejenige Person, die die Änderung vorgenommen hat, ist es ja immer gut n Feedback zu bekommen, weil man ist manchmal auch einfach im Tunnel, man verläuft sich vielleicht n bisschen oder es muss, wir gehen ja nicht mal davon aus, dass es falsch ist, was entwickelt wurde, aber dass man vielleicht einfach zu kompliziert gedacht hat, dass man etwas refactern könnte, noch dass man vielleicht ein 2 Edge Cases nicht betrachtet hat, das sind ja alles so.
Punkte für ein richtig gutes Feedback, was einen selbst ja weiterbringt. Dann am Ende, und das ist zum Beispiel ein großer Punkt, auch an dem Review, es geht ja wie gesagt nicht um richtig und falsch an der Stelle. Genau. Zusätzlich hat es natürlich auch
den Charme oder das warum. Dahinter ist natürlich auch, dass man möglichst durch so ein 4 Augen Prinzip eben auch Fehler frühzeitig erkennen kann und vielleicht dann auch in diesem Zuge eben auch technische Schuld vermeiden kann, das heißt es muss ja nicht immer nur ein Fehler direkt sein, aber
vielleicht auch. Wenn man mitkriegt, Oh guck mal hier, da wurde vielleicht irgendwas aus einer anderen Perspektive, vielleicht vielleicht nicht zukunftssicher gecoded beispielsweise, dass man zum Beispiel sagt, Ja, wenn wir das so lassen, dann ist das vielleicht so ne Art Workaround erstmal und funktioniert, aber vielleicht sollten wir es vielleicht in diesem Zuge direkt schon richtig machen, hat man sicherlich auch schon mal erlebt, da war ich schon mal auf
beiden Seiten in meiner Karriere.
Dass ich quasi gesagt habe, ja, guck mal, lass das erstmal so machen, dann so. Nee, lass lieber richtig machen und irgendwann habe ich dann auch so Momente gehabt, wo ich gesagt habe, lass uns das doch gleich richtig machen, so was hilft natürlich auch, das ist natürlich auch wichtig bei einem Code Review und gerade weil du auch jetzt zum Beispiel Team angesprochen hast, Tino ist es ja auch so, dass man zum Beispiel dann guckt, dass man innerhalb des Teams vielleicht
auch so eine gewisse Konsistenz des Codes dadurch hat, die man einhalten kann, so einen gewissen einheitlichen Stil und. Aber das ist auch ein bisschen Geschmackssache. Das ist Floating, würde ich sagen.
Ja, also das mit dem Stil finde ich, ist auch ein cooler Punkt, weil es heißt ja nicht, dass jetzt der Reviewer sein Stil drauf drückt und sagt, Nee, so machen wir es nicht, wir machen es so, aber durch regelmäßige Reviews und auch in beide Richtungen gehen wir jetzt davon aus, du hast jetzt mehrere Entwickler und jeder Review mal und jeder wird auch mal gereviewt logischerweise, dann entwickelt sich halt so ein.
Konsens an Stil auch wie das Projekt an sich Code technisch aufgebaut ist, weil man entwickelt ja irgendwie so einen gemeinsamen Nenner dann, das stimmt, das ist ein wirklich sehr cooler Punkt. Ich würde gerne noch mal kurz auf dieses Fehlerthema eingehen, Qualitätssicherung auf jeden Fall, auch Fehler, die durchrutschen werden dadurch natürlich gefunden, also wahrscheinlicher gefunden, als wenn es kein Review gibt, logischerweise.
Aber wobei es auch hilft, wenn man Fehler mal so definiert, dass man sagt, es ist in sich richtig entwickelt und es tut was es soll. Aber vielleicht geht es an den Anforderungen vorbei oder an der Vision des Produktes, das einfach oder einfach klar wird, dass der Reviewer zum Beispiel eine andere Sicht der Dinge auf die Funktionalität hat oder auf das gewünschte Feature und dann hast du ja auch schon einen richtig guten Punkt. Also vielleicht zu spät, aber
noch nicht zu spät. Ne, also klar wäre es vor der Entwicklung besser gewesen, aber spätestens beim Review würde man dann ja auch sehen, ey warte mal. Irgendwie hab ich mir das anders vorgestellt, wie das Feature an sich funktioniert, lass uns noch mal drüber reden und das ist dafür dann auch halt n sehr guter Punkt. Ja, definitiv. Das auf jeden Fall.
Aber wenn wir jetzt mal weiter gucken und sagen, OK, wir haben jetzt schon herauskristallisiert, warum ist so n Review wichtig, warum macht man sowas?
Und bevor wir jetzt wirklich in so ein richtiges Review einsteigen und sagen okay, was sind denn zum Beispiel gute Schritte dafür, wie man effektives Code Review durchführen kann, kann man irgendwie vielleicht das ganze auch schon vorbereiten, dass man sagt, bevor überhaupt so ein Review startet, was kann man da vielleicht schon im Vorfeld machen, sage ich mal so im Sinne von der Vorbereitung.
Also ich finde. Ein wichtiger Schritt bei so einer Vorbereitung. Der ist, der ist nicht pro Review, der ist so allgemein finde ich noch, und zwar, dass man sich einfach mal überlegt, was ist mein Ziel von diesem Review. Ich habe anfangs zum Beispiel auch Reviews gemacht, wo ich einfach nur gesagt habe okay, ich gucke auf die Änderung, bin halt wild durch die Changes durchgescrollt habe gesagt ja hier.
Sagen ja hier, das könnte man vielleicht noch ein bisschen anpassen, das könnte man vereinfachen, aber einfach so wild drauf los, ohne irgendwelche Strategie, irgendwelche, also irgendein Plan im Kopf halt, und deswegen finde ich es ein so ein wichtiger Punkt, sich mal wirklich klare Ziele zu definieren, zum Beispiel was ich eben angesprochen hatte, was ist meine Erwartung, was die Software jetzt anders macht und ist diese Erwartung erfüllt,
könnte ein Punkt im Review sein. Also deckt es sich mit meiner Erwartung. Wenn nicht, habe ich halt einen Diskussionspunkt. Wäre jetzt so der Erste für mich, dann finde ich es halt immer gut sich zu überlegen, was möchte ich, was erwarte ich von der Codeänderung an sich vom Handwerk her so was wie ist es verständlich, erwarte ich, dass es wartbar ist, also dass dass der Change an sich gut
erweiterbar ist. Wartbar ist auch verständlich ist so. Projektstandards hatten wir drüber gesprochen, ist auch ein guter Punkt, dass du sagst, habe ich Punkte oder Standards im Team in meinem Projekt, die ich da einfach erwarte und darauf achte, ob die missachtet werden, da können wir später noch mal drauf eingehen, weil sowas lässt sich auch sehr gut toolbasiert abdecken, aber das wäre für mich halt auch so ein Punkt und natürlich was auch nicht
verkehrt ist. An der Stelle ist, dass man natürlich auch eine. Geeignete Umgebung wählt ne, also dass man jetzt zum Beispiel nicht sagt, ich hab ich programmiert, was meine IDE und sag dann zum Beispiel sowas wie ich ich ich schick dir jetzt mal n Pfeil guck mal bitte über den Code, also dass du zumindest sowas wie changes siehst.
Logischerweise ist n no brainer, aber ich sag es jetzt trotzdem einfach mal und auf der anderen Seite kann man dafür natürlich auch Tools nehmen, die sozusagen diese dieses Review und den Approven, also sozusagen den den Code approven sozusagen, dass man ihn auch hinterher wirklich rein. Integrieren kann in die Gesamtbasis also die Änderung, dass man dafür halt auch eben irgendwas nutzt, was das ganze anleitet, wie zum Beispiel irgendwie Github, git lab oder
was es da noch alles so gibt. Also gerade diese Repository Unterstützung, die so was ja eigentlich immer anbietet. Logischerweise ist ein No brainer wie gesagt, aber soll auf jeden Fall nicht vergessen werden. Ja, was heißt no brainer? Also ja, heutzutage ja, man sollte auf jeden Fall Tool basiert arbeiten. Weil das einfach mittlerweile so gut funktioniert, dass es
Quatsch wäre, es nicht zu tun. Aber grundsätzlich kannst du es ja auch manuell machen, bloß dann ist es eigentlich vorprogrammiert, dass da irgendwann was durchrutscht oder der ganze Prozess halt enorm verkompliziert wird. Na gut, aber wenn wir jetzt mal davon ausgehen, dass wir sagen, was, also, wie würdest du jetzt zum Beispiel an so einem so einem Code Review rangehen? Angenommen?
Du kriegst jetzt ein Code Review ne und jemand sagt Ey Tino, kannst du mal bitte meinen Code reviewen wie würdest du da jetzt so was wären deine Schritte um das sozusagen effektiv zu gestalten? Ja, also ich fange eigentlich in der Regel damit an, dass ich mir einen Überblick verschaffe. Es klingt so zu trivial, aber das ist, gerade weil ich es ja vorhin schon angesprochen hatte, dass ich früher einfach so wild drauf los gereviewt habe. Versuche ich mir mittlerweile
einen Überblick zu verschaffen. Das heißt, ich gucke mir erstmal an, wieviel Changes gibt es, gucke mir grob an wo die Changes sind, also gerade wenn ich selbst Teil des Projekts bin, also der Projekt logischerweise ja, sondern aber vielleicht auch von dem Teil der geändert wurde, ich sag mal vielleicht so ein Teilbereich der Software, ich muss ja erstmal gedanklich mich drauf fokussieren, wo bin ich in der Software, ja das finde ich ist für mich immer sehr hilfreich und das meine ich auch
so mit Überblick verschaffen. Und das heißt, da zählt erstmal zu logischerweise eine Beschreibung des Pull Requests zu lesen, also Pull request jetzt, ich Krieg ein Pull request und soll das Review bevor wir es genehmigen, weil wir jetzt gerade schon bei zum Beispiel github waren und diesen ganzen Prozessen und Tool basierten Unterstützung, dann lese ich die Beschreibung und dann will ich da schon mal verstehen worum es geht, das ist mir schon mal wichtig, wenn da
nicht wirklich was drin steht in so Beschreibung finde ich schwierig also. Es muss nicht unbedingt da sein.
Man kann mir auch die Nachricht schreiben, sozusagen kannst du das bitte reviewen das und das ist erledigt worden, vielleicht noch n Ticket hinterlegen wär auch nicht schlecht, toolbasiert wirst du wahrscheinlich ne Verlinkung haben, aber ist n anderes Thema. Aber ich würde jetzt einfach, ich verstehe das quasi so, dass du jetzt, wenn du jetzt, sagen wir mal du hast ein Code review, das du machen sollst und da sind jetzt 10 Files drin, dann sagst du jetzt nicht okay ich guck mir
einen Code an, Pfeil 1. Guckst du das alles durch, weil 2 guckst durch weil 3 bis 10 und fertig, sondern du sagst okay erstmal was ist die grobe Beschreibung, die grobe oder die grobe Description sozusagen von dem was da überhaupt geändert wurde, wie zum Beispiel? Sagen wir mal neues Features reingekommen, dass du weißt okay Pass auf, irgendwie hat sich jetzt die Funktionalität verändert dahingehend, dass die Software jetzt zum Beispiel das und das neu kann.
So und danach guckst du dir dann sozusagen die entsprechenden Files an und weiß aber erstmal, kannst erstmal den Kontext einordnen und dann fängst du überhaupt erstmal an zu sagen okay, jetzt gucke ich mir das ganze an und dann fängst du bei file 1 einfach an oder wie geht's dann weiter? Na ja, also noch mal kurz eingehackt dazu, das ist für mich halt an der Stelle einfach aus der Erfahrung her sinnvoller, das ganze Top Down zu machen.
Das heißt ich geh ganz grob an das Feature ran und guck es mir wirklich von außen an und Zoom dann sozusagen in die Changes rein, weil. Ja, weil andersrum so bottom, wie ich es früher gemacht habe, ist einfach nur so file ja hier, weil dann bewertest du nur diesen sage ich mal den Change an diesem einen Pfeil und kannst dich völlig drin verlieren. Das heißt du kannst vielleicht diese einzelnen Changes auf den Codezeilen sozusagen ganz gut bewerten, sage ich mal.
Aber das Gesamtpaket hast du gar nicht im Blick dann oder oder fragst dich dann nach einer halben Stunde, was gucke ich mir eigentlich an, weißt du? Deswegen finde ich diesen Top Down Ansatz kann ich nur zu raten wesentlich effektiver auch am Ende und was gucke ich mir als erstes an ist eine sehr gute Frage, kann ich gar nicht so pauschal beantworten. Was ich aber sagen kann ist, dass ich sehr gerne in einem Projekt arbeite, was eine gute Testabdeckung hat, nein, dass
ich davon gehen wir. Aus, dass das immer so. Davon gehen wir jetzt aus. Genau. Dass ich mir die Changes an den Tests angucke als erstes, das finde ich halt sehr hilfreich, auch wegen diesem top down Ansatz, dass ich sage, OK, ich hab jetzt gelesen die Beschreibung gelesen, ich weiß was gemacht werden sollte, dann gucke ich in die Tests, schaue mir zum Beispiel an, sind neue Tests dazu gekommen. Wurden Tests geändert?
Das würde für mich bedeuten, dass sich Funktionalitäten an anderen Stellen geändert haben oder angepasst wurden, dass ich halt einfach so einen Überblick schon kriege. Was ist passiert in dieser Entwicklung?
Also wenn wir jetzt davon ausgehen, dass zum Beispiel in den Tests auch wirklich, sage ich jetzt mal, die Anforderungen irgendwo abgebildet sind, weil dann weißt du ja zum Beispiel der Best Case ja genau, weil dann ist ein neuer Test Case hinzugekommen und du siehst, OK, dieser Test hat eine gewisse Anforderung und. Dafür gibt es erstmal einen Test. Punkt 1 Check und dann irgendwann logischerweise sich dann auch die Änderung oder den neuen Code der dazu gekommen ist.
Für das entsprechende für die entsprechende Anwendung an für den entsprechenden Anwendungsfall dann sozusagen, dass du dir das dann anguckst. Genau, ja, und dann kannst du halt sag ich mal, abhängig von den Tests dir die entsprechenden Änderungen im Source Code an sich angucken. Ja und so. Finde ich, kann man das ganz gut
strukturieren. Ich würde jetzt nicht behaupten, dass es die beste Art und Weise ist, aber es ist die Art und Weise, wie ich es persönlich am Strukturiertesten finde und wo ich am besten den Fokus behalte. Ja, finde ich auf jeden Fall auch gut. Also ich gehe da total mit, weil erstmal ein Kontext sozusagen den Kontext sehen, verstehen was passiert hier Neues das. Dann zu gucken, OK welche Tests
wurden geschrieben? Gibt es überhaupt Tests dafür, was natürlich auch irgendwie ne Anmerkung sein könnte oder n Feedback sein könnte gucken OK, da ist n Test. Es wurde was geändert, dann erschließt sich ja auch schon n bisschen wo hat sich vielleicht was geändert, also gedanklich schon und man hat auch ne gewisse Anforderung die sozusagen in den Code dann in vom Test also in den Test gegossen wurde und dann natürlich auch in den Code
fließt. Und wenn man dann das so betrachtet, finde ich auf jeden Fall gut und dann wäre jetzt so die nächste Frage, was guckst du dir dann im Code an, was sind deine Punkte wo du sagst, das ist jetzt das, was im Code irgendwie relevant für dich ist. Das ist also, da habe ich auf jeden Fall keinen festen Ablauf, bin ich ehrlich, aber. Bestimmt n paar Punkte die du auf jeden Fall irgendwie.
Ja, ja, ja, ja, auf jeden Fall. Ich überleg nur gerade, ob ich vielleicht doch irgendwie im Unterbewusstsein so n festen Ablauf hab, aber ich glaub es ist doch dann noch n bisschen durcheinander alles also wär wahrscheinlich nicht schlecht so erstens zweitens drittens viertens zu haben, aber gefühlt läuft funktioniert das so nicht, weil ja jeder Change den du dir anguckst auch anders ist. Dir fallen Sachen unterschiedlich schnell auf, auch definitiv, aber was auf jeden Fall. Logisch.
Ist, dass man nach Logikfehlern sucht. Ja, aber jetzt nicht gezielt so hä. Ich find da n Fehler und er hat was falsch gemacht, sondern dass du jetzt deine Erwartung von dem Test noch mal mit der Implementierung abgleichst. Und natürlich sollten die Tests grün laufen, bevor ich sie bevor ich es review, also ne bevor ich jemand was reviewen lasse, muss ich natürlich als Entwickler oder Entwicklerin dafür sorgen, dass auch alles grün läuft und
nicht hier. Ich hab was implementiert, funktioniert nicht, Review das und am besten kriegst du es noch, also so läuft es ja auch nicht. Trotzdem lass ich die Tests auf meiner Umgebung auch gerne mal laufen. Warum nicht?
Also ich hatte auch zum Beispiel schon mal den Fall, dass die Tests alle Grün gelaufen sind und aber trotzdem n logikfehler dabei war, dass man sozusagen, wenn man und das finde ich aber sehr schwierig, und das kann man auch eigentlich nicht unbedingt immer erwarten, dass man sowas immer sieht. Das war eher Zufall, aber ich fand es interessant, weil ich hab mir den Test angeguckt, wie du es gerade auch beschrieben hast. Und dachte mir so OK, aber wieso, wieso ist der Test so geschrieben?
Ich versteh diese Überschrift nicht, die also der die Beschreibung des Tests klang für mich wie umgedreht, wie wie bitte, also wie als müsste da true rauskommen anstatt false OK so und dann hab ich mich immer gefragt was ist denn, was soll das? Und dann hab ich halt das wenigstens mal angemerkt im Code Review und gefragt ist es richtig so, dass das genau in die Richtung sozusagen beschrieben ist? Und da kam dann zurück, Oh nee, hab ich falsch umgedreht sozusagen und im Code auch
umgedreht. Das heißt, der Test ist natürlich ne, also wenn du n Test false erwartest und die sag ich jetzt mal n logischen Ausdruck zurückgibst der false gibt, dann ist der Test natürlich grün. Obwohl du aber eigentlich true haben wolltest und das ja ich sag mal aber das. Ist genau der Punkt den wir vorhin hatten dass du bei so einem Review ja auch dann merkst ob die Erwartung der Funktionalität einfach abweicht ja was ja in dem Fall der der Fall war ja ja weil klar wenn du
sag ich mal. Der Developer hat an der Stelle ja nichts falsch gemacht, er hatte halt einfach ne falsche Erwartung von der Funktionalität an dem in dem Punkt erstmal oder ist halt aus Versehen verdreht ne oder aus Versehen aber auf jeden Fall war das ja nicht so, ich implementier es falsch und adaptier den Test so, dass er grün ist.
Das wäre natürlich fahrlässig, aber das war ja nicht der Fall da. Ja, aber das bringt mich zum Beispiel auch zu einer Sache, die mir auch immer, also die für mich immer sehr wichtig ist, wenn ich n Code Review
durchgehe. Weil du hast ja, du guckst ja dann diese Changes an, ne, also du hast jetzt zum Beispiel sagen wir mal du hast ne n Pfeil mit 100 Zeilen und die Changes umfassen, aber jetzt zum Beispiel nur sagen wir mal 10 Zeilen, weil da wurde etwas verändert, das heißt man guckt sich natürlich nicht die ganzen 100 Zeilen an, logischerweise, weil davon können wir ausgehen, die wurden ja auch schon mal gereviewt irgendwo, aber man guckt sich dann halt die weiß
nicht diese sagen wir mal 10 Zeilen change an und das ist dann natürlich aber auch wichtig, finde ich. Dass der Code irgendwie auch lesbar ist. Also wenn ich jetzt diesen Code angucke und mir denke, hä, was soll da jetzt eigentlich genau passieren?
Also vielleicht hast du eine Funktionsbeschreibung, die dir sagt okay das und das soll passieren, aber du kannst aus diesem Code irgendwie gar nicht herauskristallisieren, wieso da irgendwie was gemacht wird, dann kann man das natürlich auch noch mal irgendwie challengen und vielleicht noch mal in Rücksprache mit dem Autor oder der Autorin des Codes gehen. Weil es halt zukünftig einfach wahrscheinlich dann.
Schwer wartbar sein wird, wenn du als Reviewer frisch quasi schon Probleme hast, den Code zu verstehen, kann man auch davon ausgehen, dass der eigentliche Entwickler oder Entwicklerin ihn in 5 Wochen auch nicht mehr versteht. Ja, auf jeden Fall. Klingt immer n bisschen fies, aber das ist auch eigene Erfahrung. Das ist so irgendwann, man kommt immer mal an den Punkt, wo man sich denkt, was hab ich damals eigentlich gecoatet, was passiert da? Normal.
Und dann ist das halt einfach schon der das erste Anzeichen, dass man da noch mal drüber reden sollte und das noch mal refectern sollte auf jeden Fall. Ich find das beste Beispiel dabei ist immer so kidblame gucken, OK stich. Selber drin, verdammt verdammt. Aber das ist n guter Punkt. Lesbarkeit ist das erste was auch ins Auge sticht das. Ist wirklich ein Punkt, der sofort auffällt, wenn du sagst, so ah nee, das das ich fühle das gerade nicht so so wie das
Gecoded ist. Das ist denn schon ein gutes Anzeichen, so dass man da noch mal drüber reden sollte, auch zum Beispiel Redundanzen ist so ein Thema, das kann auch relativ schnell auffallen beim Reviewer auf Entwicklungsseite geht das schnell mal durch, gerade wenn du so ein Flow bist, dass du nicht merkst okay, das habe ich jetzt hier redundant verwendet, das könnte man noch mal vereinfachen oder zusammenfügen. Das ist auf Review Seite dann immer.
Man hat halt so einen frischen Blick einfach, das ist ja auch der Grund, warum das so effektiv sein kann, weil du einfach noch mal ganz frisch auf diese Änderung drauf guckst. Ich wollte es gerade sagen, dafür gibt es das ja genau, also das ist auf jeden Fall ein Punkt und was dann so als letztes dazu kommt bei mir sind denn auch so Geschichten wie gibt es irgendwelche Schwachstellen im Code?
Im Sinne von ist vielleicht irgendwas nicht abgedeckt, fehlt sogar da noch irgendwas, weil mir irgendwie so ein Edge Case einfällt, der nicht behandelt wurde. So mögliche Sicherheitsschwachstellen ja ja im Worst Case sogar sicherheitsschwachstellen ja aber auch Performance Issues kommt ist immer so ein bisschen projektabhängig, aber es ist nie verkehrt auf die Performance zu achten, dass man zum Beispiel sagt, Ja Pass auf, das ist keine Ahnung von der Komplexität, nicht so geeignet.
Gerade das kriegen wir besser hin, wir erwarten da große Datenmengen, auch vielleicht im Zuge des Speichers, dass man sowas denn da halt auch berücksichtigt, gerade wenn man schon ne Idee im Kopf hat, die sich so herauskristallisiert beim Reviewen, dass man sagt, wie wäre es, wenn wir es vielleicht so und so machen, da könnte man noch was rausholen, da muss man natürlich immer noch abwägen, ob sich das lohnt oder ob es trivial ist. Und so macht keinen Sinn, so
braucht man nicht. Aber anmerken kann man es ja definitiv. Das sind also die Punkte. Hast du da noch was? Also mir fällt gerade auch nicht mehr spontan irgendwas ein, was jetzt so was was für mich jetzt zählt, wenn ich den Code durchgehe. Also wir hatten jetzt gesagt irgendwie überprüfen auf logikfehler, Lesbarkeit halt checken, gucken ob es irgendwie vielleicht Redundanzen gibt und auch. Vielleicht auf im optimalen Fall auch auf Performance oder
Sicherheitsaspekte achten. Das finde ich, ist halt natürlich schwierig, das ist vielleicht noch so, sind noch die schwierigeren Sachen, weil da musst du auch vielleicht wirklich dann drin stecken in der Materie, richtig stark und vielleicht auch das große Ganze auch sehen. Also wenn du jetzt zum Beispiel gerade neu irgendwie in in Projekt rein kommst, dann ist es vielleicht nicht unbedingt möglich direkt Sicherheitsaspekte zu checken wie zu Schwachstellen oder so, weißt du.
Durchaus möglich, dass es dann noch nicht so funktioniert, aber sind auf jeden Fall gute Punkte und ich find halt so. Angenommen man findet jetzt irgendwas ne ich find du hattest ja eben gesagt Redundanzen ne, also man muss ja irgendwie n Feedback geben, ne also zum Beispiel man man hat dann
irgendwie. Man kann ja bei solchen Automatismen, wie zum Beispiel, die wir vorhin meinten, über bestimmte Tools, kannst ja zum Beispiel Kommentare dann schreiben, also so eine Art von Feedback geben.
Es empfiehlt sich, finde ich, auch immer persönliches Feedback noch mal zu geben und dann halt ist es natürlich immer das schönste, aber es kommt natürlich auch auf den zeitlichen Aspekt drauf an, können wir auch noch gleich noch mal drauf eingehen, aber was ich interessant finde ist Feedback sollte halt konstruktiv sein, also gerade der Punkt wenn du sagst ja Redundanz ist da und du findest das als Reviewer so, dann kannst du dich ja hinstellen sagen sag mal ist dir
das nicht überhaupt nicht aufgefallen, dass dass der Code redundant ist? Es richtig dumm von dir, weil du brauchst ja nur Steuerung f zu machen und schon siehst du, dass da redundanter Code ist. Was ist mit dir so?
Das ist natürlich nicht die feine Art, weil wie du schon meintest, du bist im Flow. Du codest gerade, vielleicht arbeitest du auch an 2 verschiedenen Files und hier fällt es in dem Moment nicht auf und genau dafür ist ja dieses Code Review da, dass man es halt mitkriegt und darauf quasi hingewiesen werden kann und das ist halt unglaublich wichtig, finde ich zu sagen, nicht so was wie das hast du falsch gemacht, das ist völliger Quatsch, das ist blöd so jemanden zu blamen,
darum geht es ja gar nicht, es geht ja wirklich darum zu sagen. Das könnte man für n besseres gelingen machen. Beispielsweise ne, dass man irgendwie auf ne freundliche Art und Weise hinweist und sagt, OK, also man kann ja auch zum Beispiel Fragen, war das jetzt sozusagen gewollt, dass es so
ist? Oder wäre es vielleicht anders, dann doch vielleicht schöner, ne, also manchmal kann man es ja auch als Frage formulieren, weil ich finde, man ist oftmals in dieser Situation, dass man halt so judged weißt du, dass man halt so sofort so sagt? So, das ist nicht so gut, ich
würde es so machen, weißt du? Aber das ist ja eigentlich auch nicht die feine Art, weil manchmal siehst du das ja auch gar nicht, dieses Gesamtbild dahinter in dem Moment oder den Kontext, den sich der andere Entwickler oder die andere Entwicklerin, der Autor, die Autorin des Codes an dem Moment gemacht hat, also vielleicht manchmal Fragen, ist es so
gewollt oder so ne, also. Dass man vielleicht auf eine freundliche Art und Weise hinweist oder halt ein konstruktives Feedback gibt und sagt, EY ist mir auch schon mal passiert, aber guck mal, da hast du zweimal das Gleiche, das würde ich wahrscheinlich zusammenfassen. Also jetzt, um das Beispiel aufzugreifen. Es ist ja halt auch oftmals so. Also warum dieser positive Ton so wichtig ist. Du Reviewst das und siehst nur die Änderung, aber du siehst nicht den Prozess dahinter, wie
diese Änderung entstand ist. Und manchmal wirken Änderungen erstmal vielleicht nicht optimal. Nenn ich es mal und dann ist es aber halt besser quasi es so zu formulieren. Das Feedback, dass man fragt könnten wir das nicht vielleicht so und so machen, weil es kann ja sein, dass es einen absolut spezifischen Grund gab, warum es in dem Fall so gemacht wurde. Auch bei Redundanzen vielleicht, dass der Umbau einfach riesig wäre, um das irgendwie
zusammenzufassen. Nur als Beispiel ne, dass man gar nicht dir das Ausmaß dahinter gesehen hat als Reviewer. Man sieht halt nur diese Änderung, denkst du kannst du, kannst du das nicht irgendwie vereinfachen kannst? Also das könnte man doch weißt du, man hat so ne erste Idee, ja dann machst du das und das und dann ist es vereinfacht so, aber das geht vielleicht gar nicht.
Also das heißt, in diesen Dialog treten ist halt viel wichtiger als zu blamen, weil im Worst case blamest du das und sagst so ja hier nee, das ist Quatsch, das kannst du so machen und dann kriegst du zurück. Ja dann versuch mal will ich sehen, weißt du, wenn du erstmal auf dieser Tonebene bist, so mit dem Finger auf jemanden zu zeigen ganz ganz schwierig, weil das Review es geht dabei um den Code und nicht um den Code oder die Coderin also du du reviewst ja nicht die Arbeit, also die
die Arbeitsweise sage ich mal. Der Entwicklerin oder des Entwicklers, sondern die Änderung an sich. Es geht um die gemeinschaftliche Codebasis, um das gleiche Projekt, alle sind da bestrebt, dass es gut wird, und da werden Änderungen gereviewt. Finde ich auf jeden Fall nicht, dass du sagst. Ja, weil es ist ja nicht deine Aufgabe zu bewerten, ob Person A ein guter Entwickler oder eine gute Entwicklerin ist. Darum geht es ja gar nicht.
Du bewertest halt nicht die Person, sondern den Code am Ende so und ich ich finde das auch immer. Wichtig, dass man an der Stelle erstmal ey, das sind ja im Normalfall sind das deine Teamkollegen oder Teamkolleginnen. Das heißt, warum sollte man jetzt irgendwie da irgendwie, sag ich mal, passiv aggressiv irgendwas kommentieren oder oder so das Feedback geben, das zum einen und zum anderen. Ist es ja auch so, dass. Du mit gewissen Vorschlägen auch.
Vielleicht. Wie sagt man so neue Blickwinkel für andere Eröffnest, weißt du, dass ja, wie du schon am Anfang auch meintest, diesen Wissenstransfer gibst und es ist nie gut, wenn man zum Beispiel sagt, Ich weiß, dass ich jetzt zum Beispiel der Senior Software Developer in diesem Team bin und der andere ist jetzt zum Beispiel Junior und deswegen kann ich mich über ihn setzen, so ist an sich menschlich auch
nicht schön und deswegen. Immer auf Augenhöhe miteinander kommunizieren, niemanden runter machen und wirklich wertschöpfend sage ich jetzt mal das ganze kommunizieren nehmen. Das hast du schön gesagt, das ist echt wirklich ein sehr, sehr wichtiger Punkt. Ja, wenn ich so darüber nachdenke, ist das wirklich so der der Key Point dahinter, weil
wie eingangs erwähnt ist. Es ist n Dialog irgendwo der stattfindet und man liefert mit dem Review Diskussionspunkte und da muss man auf Augenhöhe quasi drüber diskutieren und nicht die
Rolle einnehmen. Jetzt kann ich dich bewerten und jetzt machst du mir schön 1 reingedrückt und jetzt kriegst du richtig n Review um die Ohren, so weißt du wenn du in dem Modus bist, dann funktioniert, dann wirst du keinen Benefit mehr aus diesem Prozess ziehen, sondern dich einfach nur noch in einer Art Teufelsspirale abwärts bewegen, ne. Und dann war es das. Irgendwann. Dann will keiner mehr mit dem
anderen arbeiten. Der eine will nicht mehr reviewen und dann bist du halt wirklich am Ende, sozusagen, dann ist das Ding gescheitert in meinen Augen. Ja, das ist ja auch von der Seite, die den, also diese Seite, die das Feedback annimmt, muss natürlich auch. Und wenn das Feedback schön ist, dann ist es ja auch viel einfacher zu sagen, Hey stimmt, das ist ne gute Idee. Das das werd ich mal mitnehmen so.
Aber wenn du jetzt n blödes Feedback bekommst, dann kommst du vielleicht auch viel schneller in diese in in irgendeinen Rechtfertigungsmodus sagst vielleicht so nee ich will das aber gar nicht so willst das ja gar nicht annehmen, also dann ist das wie du meintest, das ist dann eigentlich gescheitert und deswegen sozusagen die Seite dieses Feedback gibt ist immer wichtig konstruktiv zu bleiben und die Seite die es annimmt auch vielleicht mal zu sagen OK stimmt hast du recht gehabt so
die Seite ist ja auch wichtig ne. Was halt auch extrem entscheidend ist, ist halt, dass man dieses Feedback halt sehr spezifisch macht.
Ne, also jetzt nicht so spezifisch, dass du sagst du was schreib mit, du machst jetzt das das und das, darum geht es ja auch nicht, aber dass du halt konkrete Beispiele oder alternativen Aufzeigst, das kann ich mal an einem Beispiel aus dem Studium erklären oder so ne Erfahrung die ich gesammelt hab, ich hatte mal n Kurs. Da sollten wir, das war so eine Art Projektarbeit, aber jetzt jeder für sich, also jeder hatte so ein Mini Projekt und man musste, dass das Semester über
entwickeln und das war nachher auch Zulassung für die Prüfung, das heißt, du musstest das erfolgreich abschließen, das heißt, es gab ein Übungsleiter, der das abgenommen hat und entschieden hat, so Art auch als Review, ist das jetzt Grün oder rot, also darf diese Person zur Prüfung gehen oder nicht und. Das war eh alles schon ziemlich schlecht spezifiziert.
Man hat sich die ganze Zeit gefragt, was soll ich hier eigentlich machen und dann hatte ich eine Lösung, die für mich okay war und die auch funktioniert hatte und dann ging das ins Review. Man hat sich das dann angeguckt, der Übungsleiter hat drauf geschaut und hat am Ende gesagt ja nee, mach das mal noch mal. Das ist irgendwie das, das muss anders gemacht werden so und ich dachte mir. Was ist das für ein Feedback? Mach es noch mal.
Erstmal absoluter Frust der sich entwickelt, ne, also denkst du so okay warum sollte ich das noch mal machen? Ich habe jetzt ewig dran gesessen, es funktioniert doch es ist vielleicht nicht perfekt aber es funktioniert und auf der Nachfrage hin was ich denn machen soll oder anders machen soll kam nur denk anders und dann stehst du da und denkst dir denk anders geiles Review ich denke anders was willst du eigentlich du bist ja kurz vorm Ausrasten. Was in dem Moment? Denk anders.
Geiles, also wirklich bestes Review meines Lebens. Denk anders bis morgen und dann hab ich halt irgendwas umgeändert und dann war es irgendwann okay so weißt du. Aber das ist halt so. N perfektes Beispiel, wenn dir was nicht schmeckt in dem Review, dann sei spezifisch und sag und also wirklich nicht schmeckt im Sinne von wenn du ne andere Erwartung hast, dann rede da drüber, sei spezifisch was du dir anders vorstellen könntest. Keine Ahnung.
Nehmen wir ein Beispiel. Irgendwer hat eine Codeänderung gemacht, hat da verschiedene Schleifen verwendet, Iteriert da drüber und du selbst. Hast du die Vorstellungen? Das könnte man doch mit einer Art Map Funktion umsetzen, das würde einfach schlanker sein, man würde schneller verstehen was da passiert, das wäre ja spezifisch zu sagen, hey wollen wir das da nicht vielleicht mit einer Map Funktion lösen, dann kann man ja drüber diskutieren aber vielleicht zu sagen.
Unspezifisch die Schleifen da, nee, mach das anders. Ja, ja, du. Kannst das ja auch auf.
Du kannst es ja auf die andere Seite packen und sagen, genauso bringt es nichts, wenn du zum Beispiel sagst, ja, das sieht gut aus, also wenn du wirklich was hervorheben möchtest und du sagst, es sieht gut aus so, dann sag doch, warum es gut aussieht oder logischerweise mindestens, dann sollte man vielleicht auch nachfragen, warum ist es jetzt gut, warum findest du es blöd, was auch immer, wie kann man es verbessern oder was auch immer ne. Das ist halt definitiv wichtig,
da in beiden Richtungen spezifisch zu bleiben beziehungsweise Begründungen zu bringen, ne? Oder versetzt kann durch die andere Person damit einfach nichts anfangen, ne? Genau. Beim Feedback finde ich einen Punkt noch. Ich weiß nicht, ob der jetzt so richtig klar rausgekommen ist,
der mir aber wichtig ist. Gerade wenn ich Feedback erhalte, also mein Code gereviewt wird, finde ich eine Art Priorisierung auch sehr wichtig, dass man halt einfach weiß, was sind Punkte, die wirklich wichtig sind, wo man auf jeden Fall drüber diskutieren sollte und was sind vielleicht so kosmetische Anmerkungen. Gerade wenn es so in Projekten auch Zeitkritisch wird.
Klar, es sollte niemals so weit kommen, dass du sagst, schnell, schnell, schnell, aber jeder kennt das, dass du halt, sag ich mal, erstmal über Punkte redest, die wirklich wichtig sind, beispielsweise was hattest du vorhin gesagt, Sicherheitslücken ja klar, wenn ich irgendwie ne Sicherheitslücke finde, dann sollte das ganz oben stehen und dann redest du später darüber, ob man die 3 Zeilen vielleicht noch mal vereinfacht. Ob man Early Return nutzt oder nicht.
Ja, also weißt. Du, genau das ist halt auch noch
ein wichtiger Punkt, definitiv. Und ich ich finde, bevor wir jetzt vielleicht das ganze noch abschließen und vielleicht zu einem Fazit kommen, würde ich gerne auch noch mal so ein paar Best Practices auch noch mal ansprechen oder vielleicht zusammenfassen oder wie man das auch immer jetzt in den Kontext bringt, also was zum Beispiel wichtig ist und worüber wir auch, was wir jetzt auch noch nicht so richtig thematisiert haben, was ich jetzt mal kurz sagen möchte.
Ist, dass es durchaus wichtig ist, dass so ein Code Review nicht unglaublich groß wird. Also angenommen du hast jetzt vielleicht du entwickelst jetzt einen ganzen Monat an irgendeinem neuen Feature oder mehreren neuen Features, machst jetzt sozusagen einen, forderst dann einen Review an bei irgendjemandem sagst kannst du das mal eben durchgucken, so, dann hast du vielleicht was weiß ich 3000 Zeilen vielleicht mehr, was auch immer und sollst das dann durchgucken also.
Da sitzt du ewig dran und da muss man halt auch sagen, Best Practice ist, dass man wirklich kleine Changes hat. Also wirklich, wir reden jetzt hier von einem aller maximal höchstens 500 Zeilen, so am besten weniger so, weil keine Ahnung. Wenn du jetzt zum Beispiel sagst, so ein Review kostet dich vielleicht eine Stunde, das ist auch finde ich wirklich. Mehr als das darf es gar nicht dauern. Ist dürfte wirklich lieber, lieber lieber deutlich kürzer sein.
Also ich finde zum Beispiel ein Review von 10 Minuten ist eine gute Sache ungefähr, also das muss dann aber auch, und das ist ein Trade off, dass du natürlich sagst, ich gucke mir das aber auch genau an, weil kein Review bringt dir was, wenn du so kurz das ganze Überfliegst, was aber gleichzeitig das mit sich bringt, wenn wenn du einen richtig großen Change hast. Ich finde, da gibt es so einen tollen Spruch.
So gibt mir ein Code Review von von 1000 Zeilen und ich finde finde nichts, keine Anmerkung kein Fehler gibt mir ein Review von 50 Zeilen und ich finde 3 Fehler oder Anmerkung oder was auch immer, weil du dir einfach in diesem kleineren Code Review einfach dafür nimmst du dir lieber mehr Zeit und vielleicht hast du bei einem riesen Code Review auch die ersten 50 Zeilen, die du ordentlich durch guckst und danach überfliegst du das nur noch. Dann sagst du noch, ja komm hier
okay na noch ein Test hier. Tests wurden wohl geschrieben, super Sache, also irgendwann fehlt dann auch die Aufmerksamkeit und deswegen ist es sehr sehr wichtig Best Practice kleine Änderungsgrößen sage ich jetzt mal in einen Code Review reinzuholen. Ja, gehe ich absolut mit. Lieber halt öfter ein Review und kleinere Änderungen reviewen
als. So batch mäßig hier, das sind die Änderungen meines letzten Monats Review mir das mal am besten bis heute Nachmittag, weil ich würde es echt gerne einpflegen, weil die Features sind überfällig, absoluter worst case weil 11 ist halt klar und das ist auch wirklich die Take Home Message am Ende liebe Zuhörer lieber Zuhörer ein Review durchzuführen ist unglaublich ermüdend aus meiner Erfahrung und ich glaube aus Deiner auch das heißt? Es ist nicht einfach, ein bisschen drüber lesen.
Wenn ja, dann mache ich es nicht richtig, wenn ich einfach nur so durch gucke und mir denke, ja, sieht ganz cool aus, dann habe ich es nicht gereviewt all all die Punkte, die wir angesprochen haben, erfordern eine hohe Konzentration und einen absoluten Fokus und diesen Fokus kannst du nicht ewig aufrecht halten, diesen Fokus kannst du auch nicht aufrecht halten, wenn du durchs ganze Projekt gehst, weil einfach. Tausende Änderungen da drin sind und deswegen bin ich da ganz bei
dir. Ich kann es zeitlich überhaupt nicht festlegen wo ich mitgehe, mehr als ne Stunde ist super anstrengend, also das das hat keinen Benefit mehr am Ende, mindestens kann ich auch nicht sagen es ich hab auch Reviews gehabt die waren sehr klein also sehr schnell aber auch wichtig weil man denn über n paar Sachen gesprochen hatte. Ja das das ist sind Erfahrungswerte und ich finde da muss man sich im Projekt halt auch.
Unter den Teammitgliedern einigen, wie es für alle am produktivsten ist, aber als Richtwert, je größer, desto weniger findest du diesen Satz. Also diesen Spruch, den du gesagt hast, hab ich auch schon mal gehört und der ist einfach
super zutreffend. Und da kannst du halt zum Beispiel auch noch weiter als Best Practice mit rein nehmen, dass es um Zeilen zu minimieren, die man potenziell reviewed, keine Kommentare, die nicht also zum Beispiel auskommentierter Code kommt einfach nicht mit rein, wird nicht. So zum Beispiel auch so was wie du hast, wenn du ein Feature beispielsweise hast, dann sind das und und du du committest
nicht. Oder du fragst in dem Review nicht 2 Features gleichzeitig an, sondern das sind dann 2 Reviews beispielsweise und genauso wie du meintest es ist nicht einfach nur drüber gucken. Ich würde aber auch erwarten und das ist finde ich auch eine persönliche Best Practice, also vom Mindset her, dass wenn du gefragt wirst als Entwickler oder Entwicklerin ey kannst du mal ein Code Review bei mir
machen. Dann finde ich, das ist es irgendwie auch die Aufgabe, auch zu sagen, ja, ich mache das und dann gucke ich mir mit einer gewissen Sorgfalt dieses diese Changes an. Ja, ein sehr guter Punkt. Man sollte schon das Mindset haben, sich verantwortlich dafür zu fühlen, weil es zahlt ja in die gesamte Code Basis rein, also auch in deinen Code, das heißt das was du entwickelt hast
und man. Will dir als Team zusammen dieses Projekt tragen und die die Software und dementsprechend ist es auch in deiner Verantwortung, dass die Änderung von anderen Personen genauso umgesetzt sind oder wie wie soll ich sagen, also nicht nicht als Kontrolle, aber du möchtest ja gewährleisten, dass die Codequalität oben bleibt und wenn es dir dann egal ist beim Review und was da reinkommt. Dann könnten ja, böse gesagt Leute einfach irgendwas da rein
hauen. Du guckst drüber, denkst dir ja, wird schon passen so und die Codequalität sinkt und genauso ist es auch andersrum. Ne du erwartest ja auch von deinen Kolleginnen und Kollegen, dass sie deinen Code ernsthaft reviewen, weil du man wächst ja da dran, man wird ja besser. Wie gesagt, Diese dieser Wissensaustausch ist so essentiell dabei, dass es schade wäre, wenn dann die Leute sagen, so ja hier, komm durchgewunken. Ja.
Und da ist halt auch das haben wir sehr oft, immer dieser Druck im Projekt, diese, diese, dieser Anfang vom Ende. Manchmal, wenn dann die Leute sagen, ja, komm ist egal, Wink es bitte einfach schnell durch, das muss jetzt rein, dann muss man aus der eigenen Verantwortung sagen, Stopp, ich weiß, das tut jetzt weh, wenn wir uns die Zeit nehmen, aber wir müssen uns die Zeit nehmen. Ja, und dann ist halt die Frage, wenn diese Code Reviews zu hochfrequent reinkommen.
Dass du eigentlich irgendwann gar nicht mehr in der Lage bist, selber Code zu schreiben, weil du eigentlich nur noch am Review
bist von anderen. Dann bietet sie sich vielleicht doch an, irgendwie ne andere Art und Weise der Entwicklung zu haben, wie zum Beispiel auf per Programming überzugehen, wo du halt permanent n Peer Review hast und eigentlich diesen diese bei der Entwicklung des Codes schon immer 4 Augen drauf gucken, dann kannst du dir am Ende so n. Sag ich mal n großes Code Review in Anführungsstrichen intensives Code Review. Besser gesagt kannst du dir dann
auch einfach sparen. Genau, weil du das in Kürze. Hast genau weil du das bei der Entwicklung schon hast und darüber kann man auch nachdenken. Liebe Zürin lieber Zürer, wenn dich das Thema per Programming interessiert, da haben wir auch schon mal ne Folge drüber gemacht, also hört auch gerne. Der absolute Verfechter von als letzten Punkt noch mal hervorgehoben, wirklich ganz, ganz, ganz wichtig, das Lob nicht vergessen. Hebe guten Code einfach auch mal hervor, das finde ich ist
wirklich wichtig. Also was ist ein Review wo drin steht? Ich habe keine Anmerkung im Vergleich zu, habe keine Anmerkung das ist richtig geil gecoded also wie auch immer das formuliert ist. Also mir gefällt wirklich gut wie du das da und da umgesetzt hast. Das ist doch einfach viel mehr Motivationsfördernd als einen genehmigt. Auf jeden Fall genehmigt. Punkt.
Gerade wenn einen vielleicht wirklich auch was stark beeindruckt, ne, also man kann ja auch wirklich mal sich was angucken und sagen, Wow, das ist echt cool gemacht so, da wäre ich nicht drauf gekommen, richtig geile Lösung, spätestens dann sollte man da definitiv mal n Lob raushauen, ist ja auch Wertschätzung genau also würde ich einfach mal sagen sind wir ich bin durch Tino ich hab ich bin auch durch nichts mehr zu
sagen. Also wie gesagt, Code Reviews sind wichtig, sind essentiell, sollten auf jeden Fall durchgeführt werden, vielleicht aber auch in einer gewissen Art und Weise auch ein per Programming, wenn es zu sage ich jetzt mal zeitaufwendig ist und das hilft einfach um Qualität zu erhöhen und auch sozusagen den Wissensaustausch und wichtig ist natürlich geht respektvoll miteinander um, also dann würde ich sagen. Sind wir am Ende dieser Folge?
Es hat mir wieder sehr viel Spaß gemacht, dieses Thema Code Review mit dir zu diskutieren, auch schon wieder etwas länger Tino, aber es war notwendig das Thema und liebe Zuhörer lieber Zuhörer, wenn dir die Folge gefallen hat, dann lass auf jeden Fall mal eine Bewertung da, das würde uns super freuen und wenn du spannende Themen hast zum Thema Code Review du da irgendwie schon gewisse Stories zu erzählen hast, lass uns auch gerne auf unserer Podcast Mail zukommen, genauso wie wenn du
sagst ey. Der Podcast ist cool. Ich würde die gerne unterstützen die beiden, dann hast du auch die Möglichkeit mit einem kleinen Link, den gibt es auch in den Shownotes, genauso wie auch die Links zu einer anderen Plattform und natürlich auch unsere Podcast Mail guckt da gerne mal rein und ich würde sagen, wir hören uns in der nächsten Folge wieder deine Coding Buddies. Gemeinsam besser also. Das ist auch die.