© kabzarchyk/Shutterstock.com
Eclipse Magazin
Codereviewprozesse und die Commit Stage

Zeig mir deinen Code!

In vielen Open-Source-Projekten hat sich ein sehr formalisierter Reviewprozess für Codeänderungen etabliert. Beigetragen haben dazu GitHub mit der Verbreitung von Pull Requests und Codereviewsysteme wie Gerrit.

Richard Attermeyer


Pull Requests unterstützen zunächst einmal manuelle Codereviews. Man kann über den Pull Request diskutieren und alle Erkenntnisse zusammentragen, um den Request zu bewerten. Es gibt kein formales Kriterium, wann ein Pull Request für gut befunden oder abgelehnt wird. Der Prozess ist recht flexibel.

Gerrit ist ein Codereviewwerkzeug, das den Prozess weiter formalisiert. Es kombiniert Feedback vom Continuous-Integration-(CI-)System, das besagt, ob der Code erfolgreich baut, und Einschätzungen von Reviewern zum Code. Beides hat zum Ziel, die Baseline stabil zu halten. Allerdings braucht dieser Prozess Zeit, und die Dauer bis zu einem Feedback über eine Codeänderung verlängert sich durch das manuelle Review. Dieser manuelle Reviewprozess eignet sich gut für bestehende Software mit relativ wenigen Codeänderungen pro Arbeitstag. Während einer Produktentwicklung entstehen aber viele Codeänderungen (neuer und umgebauter Code), sodass viele Teams es als unpraktisch ansehen, jede Änderung zeitnah vor einem Commit in den Master Branch zu begutachten. Stattdessen definieren agile Teams zum Beispiel, dass ein Codereview zum Abschluss einer User Story notwendig ist (Post-Commit Review).

Wenn aber auf diesen Reviewprozess verzichtet wird, steigt durch Continuous Integration auch die Gefahr von „Continuously Broken Builds“.

Wenn ein CI Build nicht erfolgreich ist, so bedeutet dies, dass sich im Hauptentwicklungszweig „schlechter“ Code befindet. Jeder Entwickler, der einen Merge seines lokalen Entwicklungszweigs mit diesem Code durchführt, holt sich Code in seinen Arbeitsbereich, der verhindert, dass er weiter erfolgreich die Applikation bauen kann. Er muss also seine Arbeit unterbrechen. Das Mindeste, was nun auf ihn zukommt, ist, diesen Merge zurückzurollen. Eventuell stellt der Programmierer das Problem auch erst nach einer umfangreicheren Merge-Sitzung fest. Wenn das häufig vorkommt, wird viel Zeit verschwendet, was auf Seiten der Entwickler zu Frustrationen führt.

Automatisches Codereview

Wenn wir auf das manuelle Codereview verzichten, dann können wir immer noch einen automatischen Review durchführen. Ein automatischer Review kann alles enthalten, was wir für notwendig erachten, um den Patch zu beurteilen: alle Arten von Tests, die wir für angebracht halten, insbesondere Unit und Integrationstests, aber natürlich auch statische Sourcecode-Analyse.

Aber auf dem Entwicklerrechner können höchstens die Unit Tests durchgeführt werden, denn der Build muss schnell ablaufen. Dar...

Eclipse Magazin
Codereviewprozesse und die Commit Stage

Zeig mir deinen Code!

In vielen Open-Source-Projekten hat sich ein sehr formalisierter Reviewprozess für Codeänderungen etabliert. Beigetragen haben dazu GitHub mit der Verbreitung von Pull Requests und Codereviewsysteme wie Gerrit.

Richard Attermeyer


Pull Requests unterstützen zunächst einmal manuelle Codereviews. Man kann über den Pull Request diskutieren und alle Erkenntnisse zusammentragen, um den Request zu bewerten. Es gibt kein formales Kriterium, wann ein Pull Request für gut befunden oder abgelehnt wird. Der Prozess ist recht flexibel.

Gerrit ist ein Codereviewwerkzeug, das den Prozess weiter formalisiert. Es kombiniert Feedback vom Continuous-Integration-(CI-)System, das besagt, ob der Code erfolgreich baut, und Einschätzungen von Reviewern zum Code. Beides hat zum Ziel, die Baseline stabil zu halten. Allerdings braucht dieser Prozess Zeit, und die Dauer bis zu einem Feedback über eine Codeänderung verlängert sich durch das manuelle Review. Dieser manuelle Reviewprozess eignet sich gut für bestehende Software mit relativ wenigen Codeänderungen pro Arbeitstag. Während einer Produktentwicklung entstehen aber viele Codeänderungen (neuer und umgebauter Code), sodass viele Teams es als unpraktisch ansehen, jede Änderung zeitnah vor einem Commit in den Master Branch zu begutachten. Stattdessen definieren agile Teams zum Beispiel, dass ein Codereview zum Abschluss einer User Story notwendig ist (Post-Commit Review).

Wenn aber auf diesen Reviewprozess verzichtet wird, steigt durch Continuous Integration auch die Gefahr von „Continuously Broken Builds“.

Wenn ein CI Build nicht erfolgreich ist, so bedeutet dies, dass sich im Hauptentwicklungszweig „schlechter“ Code befindet. Jeder Entwickler, der einen Merge seines lokalen Entwicklungszweigs mit diesem Code durchführt, holt sich Code in seinen Arbeitsbereich, der verhindert, dass er weiter erfolgreich die Applikation bauen kann. Er muss also seine Arbeit unterbrechen. Das Mindeste, was nun auf ihn zukommt, ist, diesen Merge zurückzurollen. Eventuell stellt der Programmierer das Problem auch erst nach einer umfangreicheren Merge-Sitzung fest. Wenn das häufig vorkommt, wird viel Zeit verschwendet, was auf Seiten der Entwickler zu Frustrationen führt.

Automatisches Codereview

Wenn wir auf das manuelle Codereview verzichten, dann können wir immer noch einen automatischen Review durchführen. Ein automatischer Review kann alles enthalten, was wir für notwendig erachten, um den Patch zu beurteilen: alle Arten von Tests, die wir für angebracht halten, insbesondere Unit und Integrationstests, aber natürlich auch statische Sourcecode-Analyse.

Aber auf dem Entwicklerrechner können höchstens die Unit Tests durchgeführt werden, denn der Build muss schnell ablaufen. Dar...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang