Latest / Coding Buddies | Tech & Dev-Mindset / Code Reviews: Wie du sie richtig machst

Transcript

Code Reviews: Wie du sie richtig machst · Coding Buddies | Tech & Dev-Mindset

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