Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden

Crucible in der Praxis

Im Zuge der Vorstellung der Entwicklungstools von Atlassian hat­ten wir uns bereits mit Crucible beschäf­tigt. Im Artikel mei­nes Kollegen David wur­den dabei vor allem die Features von Crucible beleuch­tet. Hier soll es nun darum gehen, wel­che Erfahrung wir bei unse­rer täg­li­chen Arbeit mit dem Code-Review Tool von Atlassian gemacht haben.

 

Code Reviews ohne dedi­zier­tes Tool

Code Reviews kann man natür­lich auch ohne ein dafür dedi­zier­tes Tool wie Crucible (oder Gerrit, oder Review Board, oder …) durch­füh­ren. Bei uns läuft das häu­fig so ab:

Ein Lead-Entwickler schaut sich die von einem Entwickler com­mi­te­ten Änderungen am Quellcode an. Dabei hat er die IDE sei­ner Wahl offen um im Code navi­gie­ren zu kön­nen. Den zu begut­ach­ten­den Code ermit­telt er über ein Diff über das Tool sei­ner Wahl (z.B. einer Erweiterung für die IDE). Möchte er dann Feedback zum Code geben, schreibt er ent­we­der einen TODO-Kommentar direkt in den Code oder er nutzt dafür einen ande­ren Kommunikationskanal. Zum Abschluss des Reviews wird der Entwickler dann z.B. per Email über die Ergebnisse des Reviews informiert.

Ideal ist das aus ver­schie­de­nen Gründen nicht. TODOs im Code haben den Nachteil, dass oft ver­ges­sen wird diese zu ent­fer­nen, wenn das von ihnen beschrie­bene Problem beho­ben ist. Auch ist eine Diskussion am Code auf diese Weise äußerst müßig:

// TODO: I doubt this will work in production. Did you test the performance of this?
// Re: Had no problems w/ that on my machine.
// Re2: Ok. I was not precise enough: The problem here is the amount of users.
// I think there will be performance issues if there are more than just a few.
// Re3: Well I added some more users (100 now) and it still works fine.
// Re4: Well, by "more than just a few" I meant several thousands of users.
// Re6: Oops...
for (User user: getAllUsers()) {
loadGenerator.doSomeExpensiveStuff(user);
}

Ok, das Beispiel wirkt etwas gezwun­gen, aber ich denke es illus­triert das Problem ganz gut, vor allem wenn man bedenkt, dass zwi­schen jedem "Re" ein Commit liegt. Wird statt­des­sen ein ande­rer Kommunikationskanal ver­wen­det, ist es häu­fig recht umständ­lich die Problemstellen im Code zu benen­nen ("schau mal in Datei X auf Zeile Y"). Bei bei­den Ansätzen ver­liert man außer­dem schnell den Überblick über den Stand der Anmerkungen ver­schie­de­ner Reviews. Wurde schon auf meine Anmerkungen reagiert? Wo sollte ich noch­mal Feedback geben?

 

Code Reviews mit Crucible

Damit hät­ten wir also einige Werkzeug-bezogene Schwierigkeiten iden­ti­fi­ziert, auf die man bei der Durchführung von Code Reviews stößt. Schauen wir uns also mal an, wie Crucible damit umgeht.

Da wäre zum einen das Problem der Diskussionen am Code. Hier ver­eint Crucible die Vorteile der bei­den zuvor beschrie­be­nen Methoden. Kommentare wer­den direkt an den jewei­li­gen Stellen im Code abge­ge­ben und kön­nen auch direkt dort beant­wor­tet wer­den. Da dies aber nicht in der Quellcode-Datei, son­dern in einem exter­nen Tool geschieht, wird der Quellcode dadurch nicht "ver­un­rei­nigt". Weiterhin kön­nen Kommentare und Diskussionen auch auf Dateiebene oder sogar ohne direk­ten Bezug zu einem Artefakt erstellt wer­den. Zudem ist die Kommentar- bzw. Antwortfunktion recht intuitiv.

Quelle: https://www.atlassian.com/software/crucible/overview/screenshot-tour

Das zweite Problem, das den Überblick über die Anmerkungen zu einem Review betrifft, löst Crucible, indem alle Kommentare zusam­men­ge­fasst wer­den: Man erstellt immer erst ein Review in des­sen Kontext dann alle Diskussionen erfol­gen. Zu die­sen Reviews gibt es dann einen Workflow und ver­schie­dene Rollen (Ersteller, Moderator, Reviewer), die die am Review betei­lig­ten Nutzer ein­neh­men. Je nach Rolle wird von einem Nutzer in einem Workflow-Schritt Input benö­tigt, oder eben nicht. Diese Information kann man sehr leicht auf dem Dashboard überblicken.

Quelle: https://www.atlassian.com/software/crucible/overview/screenshot-tour

Beim Erstellen eines sol­chen Reviews wählt der Ersteller den zu begut­ach­ten­den Code aus und kann auch initial kon­krete Fragen oder Hinweise an die Reviewer stel­len. Hier sieht man schon einen wich­ti­gen Unterschied zu dem von mir ein­gangs beschrie­be­nen Ablauf: Nicht der Reviewer, son­dern der­je­nige der gere­viewt wird, hat die Initiative beim Erstellen des Reviews. Zwar ist es auch mög­lich, dass der Reviewer das Review selbst erstellt, aller­dings muss man dafür den Ablauf etwas ver­bie­gen, da der Moderator bei Crucible nicht gleich­zei­tig ein Reviewer sein kann. Hier trägt man dann am bes­ten den Entwickler ein, des­sen Code gere­viewt wird. Außerdem erschien mir für die­ses Szenario das Zusammenstellen des Codes weni­ger benut­zer­freund­lich, da die dazu zur Verfügung ste­hen­den Möglichkeiten nicht für die­sen Ansatz opti­miert wur­den. Hier fehlt z.B. die Möglichkeit alle Änderungen eines Nutzers ab einem bestimm­ten Zeitpunkt oder Commit aus­zu­wäh­len. Daran sieht man, dass Atlassian sein Tool für agi­les Vorgehen opti­miert hat: Alle Entwickler arbei­ten eigen­ver­ant­wort­lich an der Software und for­dern wenn nötig selb­stän­dig ein Review ein. Glaubt man dem all­ge­mei­nen Hype, sind sie damit auf der rich­ti­gen Spur. Auch ich muss sagen, dass mir die­ser Ansatz ganz gut gefällt.

Einen klei­nen Kritikpunkt habe ich aber noch. Bei dem zu Beginn des Artikels beschrie­be­nen Vorgehen habe ich erwähnt, dass zur Navigation im Code eine IDE ver­wen­det wird. Diese benö­tigt man mit Crucible nach wie vor, da in der Code Sicht keine Navigation mög­lich ist. Hier wäre eine web­ba­sierte Lösung ähn­lich wie bei Docjar oder grep­code eine tolle Erweiterung.

Zusammenfassend kann man sagen, dass Crucible eine gute Ergänzung für die Tool-Landschaft zur Softwareentwicklung ist. Vor allem die Möglichkeit Diskussionen direkt am Code zu füh­ren, ohne die­sen anpas­sen zu müs­sen ist eine wirk­li­che Hilfe bei Code Reviews. Da wir aller­dings gerade dabei sind Git und Stash zu eva­lu­ie­ren, stellt sich für uns die Frage, ob die­ses Feature mit den Pull Requests von Stash nicht schon aus­rei­chend abge­deckt ist. Wenn hier schon jemand Erfahrungen hat, wür­den wir uns über Feedback sehr freuen.

PS: Diese Woche wurde die Version 2.10 zu Crucible (und FishEye) ver­öf­fent­licht. Weitere Details gibt es im Produktblog von Atlassian.

Related Posts

Pin It on Pinterest