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.