Werden bei euch im Team Code-Reviews durchgeführt?

[hund555]

Hallo zusammen,

ich wollte einfach ein Gefühl bekommen wieviele Unternehmen Code Reviews durchführen. Diese Umfrage können also nur Softwareentwickler durchführen.

Bei meinen früheren AGs war das nicht der Fall. Hier muss alles auf den neuesten Stand angepasst und kontrolliert werden (Namenskonvention, Code Cleaner, Kommentare im Code entfernen, ...) 

[Parser]

wir machen keine, aber ich fände es gut wenn wir es täten ... 

[cmaker]

Das gehört dazu, leider machen es viele Klitschen nicht.

[kylt]

Am 23.7.2025 um 16:02 schrieb hund555:

ich wollte einfach ein Gefühl bekommen wieviele Unternehmen Code Reviews durchführen. Diese Umfrage können also nur Softwareentwickler durchführen.

Zusätzlich zu den hier im Forum gesammelten stimmen empfehle ich weitere Statistiken als Scale anzusehen.

Z.B. https://www.sonarsource.com/company/press-releases/sonar-record-growth-2022/ 

Zitat

Driven by developer value and enterprise recognition of the power of Clean Code - Sonar solution has scaled to 7 million users and 21,000 enterprise customers in 2022.

Oder Statista:https://www.statista.com/statistics/869106/worldwide-software-developer-survey-tools-in-use/ 

So können in CI / CD (2022, 44%) automatische Codereprüfungen wie sonarcqube eingebunden werdem. Zusätzlich werde explizite Coderview Tools (2022, 13%) gezählt oder auch Versionierungstools (GiT), die auch wiederum Codereview mit Pullrequest einsetzen.

 

Dann gibt es noch eine Statistik zu eingesetzten Testarten, die allerdings nur für Premium verfügbar sind.

https://www.statista.com/statistics/1450642/project-test-types/ 

Am meisten werden Unit Tests eingesetzt, was z.B. für dich - ich nehme mal an in ABAP - eher unüblich ist. 

Am 23.7.2025 um 19:23 schrieb cmaker:

Das gehört dazu, leider machen es viele Klitschen nicht.

Was mich zu dem Punkt wieder bringt, dass nicht nur in "Klitschen" gar nicht oder nur ein manueller Review statfindet.

Explizit im Bereich ABAP Entwicklung gibt es von gar keiner bis zu Codereview und Freigabe des Transportauftrages durch eine andere Person alles. Ich stelle dann immer gerne die Sinnfrage: Wenn - wie bei dir - alle Entwickler eh in jedem Bereich mitarbeiten sollen, ist eine gegenseitige Prüfung sinnvoll. Wenn, wie häufig üblich, dann pro Modul nur eine Person zuständig ist, dann ist es schon wenig effektiv dass die MM-Person die HR-Person reviewed - zumal Kompilierungsfehler die Anwendung beim Aktivieren blockiert.

[EdwardFangirlXxX]

Ja, machen wir. Für alle, also die Seniors kontrollieren meinen Code, und ich den ihren.

[trommel-ute]

Am 23.7.2025 um 16:02 schrieb hund555:

Diese Umfrage können also nur Softwareentwickler durchführen.

Wir sind keine Devs und machen trotzdem Code Reviews 🙃

Unser Flow ist: Commit schubst Pipeline an wo erstmal ne Hand voll Linter rumlaufen und am Ende ein MR/PR rauskommt, der per Regel solange nicht nach main gemerged werden kann, bis es nicht min. 1 Approval (bei KRITIS dann 2) gibt.

[Kotnascher]

Mein Code wird grundsätzlich nicht reviewt, da in unserem Team erwartet wird, dass Code und nicht Kot fabriziert wird. Zudem kann jeder durch ein gutes Testsystem seinen Code prüfen.

[Gurki]

In meinem vorherigen Unternehmen haben wir Code-Reviews gemacht. Fand ich auch teilweise gut. Mitunter versuchen sich da aber auch einige Entwickler "zu verdingen". Dann zählt nur deren Meinung und Stil wie man es zu machen hat. Empfand ich teilweise als zu anstrengend.

In meinem neuen Unternehmen machen wir keinen Code-Review. Wäre allerdings angebracht. Vielleicht kommt das ja noch.

[Whiz-zarD]

Codereviews machen wir nur, wenn jemand einen Bedarf hat.

Am 25.7.2025 um 10:56 schrieb kylt:

Ich stelle dann immer gerne die Sinnfrage: Wenn - wie bei dir - alle Entwickler eh in jedem Bereich mitarbeiten sollen, ist eine gegenseitige Prüfung sinnvoll. Wenn, wie häufig üblich, dann pro Modul nur eine Person zuständig ist, dann ist es schon wenig effektiv dass die MM-Person die HR-Person reviewed - zumal Kompilierungsfehler die Anwendung beim Aktivieren blockiert.

Ja, keine Codereviews einzuführen, hat nicht unbedingt was mit Klitschen zu tun, sondern überwiegend um Pragmatismus. Codereviews machen nämlich nur dann Sinn, wenn man wirklich gemeinsam an einer Sache arbeitet. Arbeitet eh jeder nur in seiner eigenen Ecke, ist es eher Zeitverschwendung. Man muss sich dann erstmal in das Thema einarbeiten und verstehen, was da entwickelt wurde. Dafür hat man aber weder die Zeit noch die Lust dazu. Also wird dann höchstens nur oberflächlich draufgeschaut, wenn überhaupt. Meist erlebe ich aber selber, dass es sich überhaupt keiner anschaut oder keiner was dazu sagen kann und was die "Optik" betrifft, dafür gibt es Coding Guidelines, die man mit statische Code-Analysen überprüfen kann.

[cmaker]

Am 29.7.2025 um 07:30 schrieb Whiz-zarD:

Codereviews machen wir nur, wenn jemand einen Bedarf hat.

Ja, keine Codereviews einzuführen, hat nicht unbedingt was mit Klitschen zu tun, sondern überwiegend um Pragmatismus. Codereviews machen nämlich nur dann Sinn, wenn man wirklich gemeinsam an einer Sache arbeitet. Arbeitet eh jeder nur in seiner eigenen Ecke, ist es eher Zeitverschwendung. Man muss sich dann erstmal in das Thema einarbeiten und verstehen, was da entwickelt wurde. Dafür hat man aber weder die Zeit noch die Lust dazu. Also wird dann höchstens nur oberflächlich draufgeschaut, wenn überhaupt. Meist erlebe ich aber selber, dass es sich überhaupt keiner anschaut oder keiner was dazu sagen kann und was die "Optik" betrifft, dafür gibt es Coding Guidelines, die man mit statische Code-Analysen überprüfen kann.

es geht auch um wissensverteilung, und evtl. Entdecken von Bugs, wenn der Code nicht zu überkompliziert geschrieben wurde.

[Whiz-zarD]

vor 1 Stunde schrieb cmaker:

es geht auch um wissensverteilung, und evtl. Entdecken von Bugs, wenn der Code nicht zu überkompliziert geschrieben wurde.

Wenn es aber ein Bereich ist, wo ich mich erstmal einarbeiten müsste, kann ich auch keine Bugs finden und ob ich das Wissen über den Code brauche, sei dann auch mal dahingestellt.