Codereviewprozesse und die Commit Stage

Zeig mir deinen Code!
Kommentare

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.

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.

Lesen Sie den kompletten Artikel im Entwickler Magazin 6.14

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -