Startseiterupture de caténaire

Burgbergtunnelsanierung wird teurer – oder warum Code Review wichtig ist

Von / 28. Oktober 2019 / 28 Kommentare / Seite 2 von 2 / Auf einer Seite lesen
Mehr

Was es braucht ist vor allem Zeit, bzw. das Wissen das Code Review Zeit und Ressourcen spart. Wenn jedes Teammitglied sagt “keine Zeit!” auf die Bitte “schau’ auf meinen Code”, dann läuft etwas verkehrt. (Natürlich kann man mal keine Zeit haben, aber nicht immer.) Man kommt auf andere Gedanken, kann miteinander reden – hinterher gibt es weniger Wartungsaufwand oder hektisches Korrigieren von Fehler (wodurch meist neue Fehler entstehen). Ihr versteht schon … Und es braucht Kontext. Wie gesagt, jedes Teammitglied arbeitet an bestimmten Aufgaben. Also müssen EntwicklerInnen kurz beschreiben, worum es in ihrem Beitrag geht.

Natürlich hängt der Prozess vor allem von der Gruppengröße ab. Vier Leute in einem Raum können ganz anders miteinander handeln als ein Dutzend verteilt über Kontinente. Wenn die Angst vor Fragen dem Wissen um den Mehrwert gewichen ist und man sich kennt, können verschiedene Hilfsmittel gut den Review-Prozess erleichtern.

Zu guter Letzt

Das klingt jetzt nach Werbung für agile Softwareentwicklung, oder? Nein, darum geht es mir nicht. Sondern darum, dass Anfänger auch Designentscheidungen treffen, die sich kaum korrigieren lassen: Wie oft habe ich schon veröffentlichte Software gesehen, die mir mit der Frage vorgestellt wurde: “Wie geht das schneller?” Und meine Antwort musste sein: “Gar nicht.” Ganz einfach, weil selbstverständlich langsame Software schneller gemacht werden kann (fast immer), aber es muss jemand tun. Und wenn das Projekt schon (fast) abgeschlossen ist, gibt es einfach praktische Grenzen.

Überall zwischen Design und Radius/Durchmesser-Verwechseln kann Code-Review helfen. Und auch Nicht-ProgrammiererInnen unter Euch können das hoffentlich sofort nachvollziehen: Mal ehrlich, wer hat nicht einen Fehler in der Kategorie Quadratmeter mit Kubikmeter-Verwechseln schon mal selber gemacht?

Ich kenne wenige Projekte, bei denen im akademischem Umfeld Code Review und eine gute Gruppenkultur gelebt werden und viele bei denen das nicht der Fall ist. Hier geht es um vertane Chancen zur Ausbildung. Und um die Chancen auf dem Arbeitsmarkt anzukommen. Deshalb ist Code-Review in Unternehmen UND Unis relevant.

flattr this!

1 / 2
Stichworte: ,
Mehr

Kommentare (28)

  1. #1 rolak
    28. Oktober 2019

    Willkommen!

  2. #2 H.Wied
    28. Oktober 2019

    Code Review ist schwierig, wenn es nur wenige Fachleute gibt, die eine Steuerungssoftware verstehen, entwickeln und Fehler finden können. Bei Schiaparelli, dem Marslander 2016, trat ein Fehler auf “Offenbar kommunizierte das Radarhöhenmessgerät an Bord von Schiaparelli nicht richtig mit der Steuerungssoftware des Landers” (Rolf Densing, ESA)
    2020 ist mit dem ExoMarsRover eine neue Landung auf dem Mars geplant.
    Wünschen wir dem Team Alles Gute und keine Fehler!

  3. #3 SvenS
    28. Oktober 2019

    Willkommen.
    Das ganze erinnert an meine ersten Programmierversuche in C zu meiner Schulzeit. Ich sollte einen Zinsrechner schreiben. Es hat auch alles funktioniert, bis der Rechner um flexible Laufzeiten erweitert wurde. Zwei Wochen suchte ich nach dem Fehler, sogar abends am Stammtisch hatte ich das Notebook dabei und suchte nach dem Grund für die falschen Ergebnisse. Dann schaut ein Freund (Typ ich weiß nicht was ein Computer ist) über meine Schulter und fragt “Warum hast du da überall Punkte, aber an der einen Stelle ein Komma?”
    Seit diesem Moment war ich ein Verfechter des Open Source Gedanken und habe erlebt, dass Team nicht bedeutet für andere zu arbeiten sondern mit ihnen.

    • #4 Christian Meesters
      28. Oktober 2019

      Danke. 😉

  4. #5 schlappohr
    28. Oktober 2019

    Mal ehrlich, wer hat nicht einen Fehler in der Kategorie Quadratmeter mit Kubikmeter-Verwechseln schon mal selber gemacht?

    Beim Umgang mit Uhrzeiten verwende ich hin und wieder gerne Stunden zu 100 Minuten, weil damit viel einfacher zu rechnen ist.

    Die Notwendigkeit zu einer Review erkennt man recht schnell, wenn man integrierte Schaltkreise entwickelt. Die Schaltung wird mithilfe bestimmter Beschreibungssprachen entworfen, und der Code muss genau wie eine Software reviewed werden. Tut man das nicht und hat einen Fehler im Code, wird der Chip nicht wie gewünscht funktionieren. Mit einem Bugfix wie bei der Software ist es dann nicht getan. Man kann die Chips in die Tonne werfen (oder als USB-Kaffeewärmer verwenden) und muss nochmal durch die Fabrikation. Die Produktion eines Halbleiterchips geht üblicherweise in die Millionen.

    Klingt nach einem interessanten Blog. Ich werde mitlesen 🙂

    • #6 Christian Meesters
      28. Oktober 2019

      Danke.

      Die Notwendigkeit zu einer Review erkennt man recht schnell …

      Ich wünschte das wäre so 😉 edit: Es gibt halt versch. Welten.

  5. #7 Felix
    28. Oktober 2019

    Glückwunsch zum ersten Beitrag! Ich bin gespannt, was da thematisch noch kommt. Beruflich mache ich neben meiner Doktorarbeit Support für einen Bioinformatik-Cluster. Bei uns benutzen nur wenige Nutzer wirklich selbt geschriebenen Code (Jobscripts ausgenommen) und ich habe das Gefühl, dass viele Nutzer einfach nur froh sind, wenn ihr Problem gelöst wird. Die Qualität des Codes/Jobscripts scheint da dann zweitrangig zu sein. Wahrscheinlich ist meine Sicht aber beeinträchtigt, da ich nur Jobs von Leuten anschaue, die sich wegen Problemen melden.

    • #8 Christian Meesters
      28. Oktober 2019

      Danke.

      Ja, bei uns ist das ebenso: Nutzer interessiert meist die Anwendung bestehender Software (3rd Party) und die Zeit zum Paper. Nun, irgendwo muß man ja anfangen zu schreiben.

  6. #9 schorsch
    28. Oktober 2019

    ist ein Code-Review wirklich in der Lage, Fehler wie ‘Radius mit Durchmesser verwechselt’ oder ‘Quadrat- statt Kubikmeter verwendet’ aufzudecken?

    Wenn die Dokumentation oder der Quellcode-Kommentar auf den Radius referenzieren, der Code jedoch auf den Durchmesser, dann sollte ein aufmerksamer Prüfer den Fehler erkennen können.

    Dann bräuchte der Programmautor aber auch keine zwei Wochen, den Fehler selbst zu entdecken.

    Fehler, die auf falschen Grundannahmen beruhen, werden von einem reinen Code-Review m. E. eher nicht aufgedeckt.

    • #10 Christian Meesters
      28. Oktober 2019

      ist ein Code-Review wirklich in der Lage, Fehler wie ‘Radius mit Durchmesser verwechselt’ oder ‘Quadrat- statt Kubikmeter verwendet’ aufzudecken?

      Nicht per se, nein. Wesentlich ist Anfängern beizubringen, wie man guten Code schreibt und auch Kollegen, sie sich “über die Schulter schauen”. Gute Dokumentation einzufordern gehört dazu.

  7. #11 Christian Meesters
    28. Oktober 2019

    @all: Danke für die guten Wünsche.

    Ich werde mich in die ScienceBlogs WP-Einstellungen einfuchsen, damit das mit den Kommentaren besser funktioniert.

  8. #12 uwe hauptschueler
    28. Oktober 2019

    Der Fehler, bei dem o.g. Beispiel, könnte auch absichtlich gemacht worden sein um z.B. das Projekt schön zu rechnen oder unter eine Ausschreibungsgrenze zu kommen.

  9. #13 Karl Mistelberger
    mistelberger.net
    29. Oktober 2019

    Der Goldstandard des Code-Review sind Testläufe, für openSUSE Tumbleweed hier einzusehen: https://openqa.opensuse.org/tests/overview?distri=microos&distri=opensuse&version=Tumbleweed&build=20191027&groupid=1

    Während die Code Reviewer nach Fehlern suchen sind es die Praktiker, die die Fehler finden ohne danach gesucht zu haben. Als ich einen Pentium 90 kaufte war mir der Bug sofort aufgefallen. Die Software, die Daten, den Compiler konnte ich ausschließen. Es blieb nur der Prozessor als Fehlerquelle, was kurz darauf auch bestätigt wurde: FDIV-Bug.

    Aufräumen hilft aber immer. Nur sollte man es nicht übertreiben. Der Linux Kernel ist ein gutes Beispiel für adäquate Softwareentwicklung.

    Bei der Entwicklung im Team sollte man aufpassen. Man hüte vor den Leuten mit den guten Ideen, wenn die Arbeit dann von anderen erledigt werden soll. Dann sind diese Narzissten und Schaumschläger, die heisse Luft an das Management verkaufen.

    • #14 Christian Meesters
      29. Oktober 2019

      Oh, das ist gut: Das Code Review nicht das Selbe ist, wie autom. Testen und auch nicht nur darum geht Fehler zu finden, sondern eben auch den Stil zu verbessern, damit es zu besser wartbaren Code kommt, kam nicht rüber. Ich mache mal eine Notiz, zum den Stichworten – Danke!

  10. #15 Dr. Webbaer
    29. Oktober 2019

    Sog. Code-Review ist einerseits wichtig, weil “Code” immer ein Ziel hat, ein allgemein gesellschaftliches oder ein spezielles, das eines Unternehmens der Wirtschaft beispielsweise, und andererseits, weil es unterschiedliche Befähigung gibt gemeint effizienten “Code” zu entwickeln bzw. bereit zu stellen.

    Die Erstellung von “Code” folgt immer gemeinschaftlichem Interesse, bei besonderem Bedarf wird der Schreiber dieser Zeilen hier noch ein wenig zu ergänzen suchen.

  11. #16 MartinB
    29. Oktober 2019

    Huhu, neuer Blog.
    [Hektisches Winken aus dem Drachenland]

  12. #17 Joseph Kuhn
    29. Oktober 2019

    Willkommen auf der Plattform!

    Fehler der Art Radius/Durchmesser führen bei uns zur Einzahlung in eine Fehlerkasse, die bei ausreichender Füllung einen gemeinsamen Biergartenbesuch finanziert. Funktioniert wie die Beichte, man fühlt sich danach etwas besser.

  13. #18 Dr. Webbaer
    30. Oktober 2019

    Das Code Review nicht das Selbe ist, wie autom. Testen und auch nicht nur darum geht Fehler zu finden, sondern eben auch den Stil zu verbessern, damit es zu besser wartbaren Code kommt […]

    Ganz genau, Herr Meesters, Wartbarkeit und Weiterentwicklungsfähigkeit von Code sind zentral für den Erfolg von Code. (Code kann erfolgreich sein, sozusagen.)

    Die sinnhafte Verteilung von Code, der dann die fortlaufende Zusammenarbeit mit der Fachabteilung erleichtert, ist sozusagen das A und O der ingenieurshaft betriebenen Softwareentwicklung.
    Code darf in diesem Sinne auch “geschwätzig” sein, muss an Stellen, wo es nicht um Effizienz seiner Ausführung geht, vor allem (möglichst schnell) nachvollziehbar sein.
    Bestimmte Algorithmik ist zu kapseln, auszulagern sozusagen, soll nicht die Betrachtung des Codes belasten.

  14. #19 P. Berberich
    München
    30. Oktober 2019

    Meine Frage: Welchen Testlauf hätte man konkret bei dem beschriebenen Beispiel der Burgwegtunnel-Sanierung machen müssen, um den Fehler aufzudecken? Ich persönlich hätte die benötigte Betonmenge mit Papier, Bleistift und Taschenrechner oder Excel zunächst einmal grob geschätzt.

    • #20 Christian Meesters
      30. Oktober 2019

      Finde ich auch: Die Kollegen hätten vorher eine Überschlagsrechnung machen sollen. Unabhängig voneinander. Das kostet nicht viel Zeit. (Insofern hinkt der Vergleich, aber auch hinkende Vergleiche können ja zu etwas gut sein.)

  15. #21 Robert aus Wien
    Wien
    31. Oktober 2019

    “Die gute Verwendung einer Programmiersprache lernt man nicht in einem Kurs, sondern durch Anwendung.”

    Das stimmt zwar, ich bin während meines Studiums so gut wie nie in Vorlesungen für Programmiersprachen gegangen, sondern hab mich lieber an meinen Rechner gesetzt.
    Aber: Ich mache im Moment gerade etwas, was ich immer schon tun wollte: Ich lerne gerade C++. Und da gibt es einige Dinge, auf die man durch Anwenden der Sprache nie von selbst kommen würde, da hilft wirklich nur ein guter Kurs. (Ich lerne gerade nach einem C++ Primer und mache auch brav die Programmierbeispiele. Das Buch ist wirklich gut geschrieben und der Autor versteht auch viel von Didaktik.)
    Beispielsweise die Tatsache, daß der Compiler selbst manche Constructors definiert und das zu sehr merkwürdigen Effekten führen kann, wenn man es vergißt. Und leider sind auch die Ursachen dafür dann oft nicht so offenkundig – wenn man nicht über das notwendige Hintergrundwissen verfügt.

  16. #22 tomtoo
    31. Oktober 2019

    Der beschriebene Fehler hätte schon bei den Unit Tests auffallen müssen und spätestens beim user accept.. Weniger bei einem Code review. Letztlich geht es bei einem Codereview Hauptsächlich um Lesbarkeit und Verständlichkeit des Codes. Imo sind solche Fehler ein Hinweis auf schlechtes Testen, weniger ein mangelhafter Code review. Es kann nicht die Aufgabe eines Code reviewers sein Detailfehler eines Programmes zu identifizieren, dafür gibt es Tests.

  17. #23 Karl Mistelberger
    mistelberger.net
    31. Oktober 2019

    Auch Erlangen hat einen Burgbergtunnel. Züblin hat den Ausbau angeboten und schreibt:

    Im Zuge des viergleisigen Ausbaus der Bahnstrecke Nürnberg-Ebensfeld wird in Erlangen parallel zu dem alten, im Jahr 1844 eingeweihten Burgbergtunnel, eine zweite Röhre für den S-Bahn- und Fernbahnverkehr errichtet.

    Dieser neue zweigleisige Eisenbahntunnel hat eine Länge von 307 Metern, einen Innendurchmesser von 11,70 m womit sich ein Ausbruchsquerschnitt von 130 m² ergibt, was in etwa der Giebelfläche eines Einfamilienhauses entspricht. Das Ausbruchsvolumen beträgt ca. 60.000 m³.

    Der Tunnel wird im bergmännischen Vortrieb (Spreng- und Baggervortrieb) im mittleren Burgsandstein mit Ton- und Schluffstein und einer Überdeckung von 5 – 37,5 m, hergestellt.

    Die nach Fertigstellung des Vortriebs herzustellende bewehrte Innenschale hat eine Stärke von 40 cm und ist mit einer 1-lagigen Außenabdichtung mit Kunststoffdichtungsbahn ausgestattet.

    Die an beiden Tunnelenden angeordneten Portale werden als sogenannte wasserundurchlässige Betonkonstruktion in offener Bauweise hergestellt. Stützwände, Schallschutzwände und die Eisenbahnbrücke Schwabach runden das Bauvorhaben ab.

    Wer das obige erst einmal zu Papier gebracht hat weiß wovon er redet und macht auch keine dummen Fehler.

  18. #24 P. Berberich
    München
    31. Oktober 2019

    Hier ein Erfahrungsbericht einer erfahrenen Programm-Entwicklerin. Die Fehler habe ich natürlich alle nicht gemacht?!?

    https://stackoverflow.blog/2019/10/29/my-most-embarrassing-mistakes-as-a-programmer-so-far/?utm_source=Iterable&utm_medium=email&utm_campaign=the-overflow-newsletter&utm_content=10-29-19

  19. #25 Christian Meesters
    31. Oktober 2019

    Offenbar habe ich einen Nerv getroffen. Das ist gut. Leider etwas daneben mit ungenauen Formulierungen. Das ist mir klar gewesen als ich mich zum Blog entschloss: Meine Themen finden sicher immer Leute, die sich auch auskennen und sehr leidenschaftlich sind ;-). Aber es ist ein Blogthread, kein Buchkapitel.

    Ja, manche Themen hier liegen noch in meiner Schublade …

  20. #26 Karl Mistelberger
    mistelberger.net
    31. Oktober 2019

    > #14 Christian Meesters, 29. Oktober 2019

    > Oh, das ist gut: Dass Code Review nicht das Selbe ist, wie autom. Testen und auch nicht nur darum geht Fehler zu finden, sondern eben auch den Stil zu verbessern, damit es zu besser wartbaren Code kommt, kam nicht rüber.

    > #25 Christian Meesters, 31. Oktober 2019

    > Offenbar habe ich einen Nerv getroffen. Das ist gut. Leider etwas daneben mit ungenauen Formulierungen.

    Effektiver Code Review ist unmöglich, wenn es keine Verifizierung und Validierung gibt. Der Review steht dann auf tönernen Füßen und man kann ihn sich schenken. Ohne signifikante Beispiele ist die ganze Diskussion müßig.

    1. Vorbildliche Arbeit wird seit mehr als 70 Jahren von den Jungs und Mädels vom LANL geleistet: https://laws.lanl.gov/vhosts/mcnp.lanl.gov/references.shtml Seit dem Castle Bravo Test (1954) ist nichts mehr Unvorhergesehenes passiert.

    2. Nicht so gut sieht es bei Boeing aus: Da haben unbedarfte Ingenieure das MCAS an das gut funktionierende Speed Trim System angeflanscht.

    Die erste Version des MCAS war durchaus brauchbar, wurde sie doch von zwei erfahrenen Mitarbeitern der FAA begleitet und abgesegnet. Die beiden langweilten sich und waren schon längst woanders angestellt, als Boeing eine Revision des MCAS vorlegte. Die FAA schickte zwei Anfänger mit annähernd Null Ahnung zur Begutachtung. Das Ergebnis ist bekannt und beschämend.

    Bei der Validierung im Simulator sahen die Piloten keine Probleme bei einer fehlerhaften Aktivierung des MCAS und nahmen an, dass die Piloten im Flugzeug einen Stab Trim Runaway sofort erkennen und mit den mittlerweile berüchtigten Kippschaltern beenden würden.

    Die technisch versierten Piloten am Simulator hatten keine Ahnung von der heutigen Pilotenausbildung. Diese junge Leute hocken zum Teil nur am Steuer weil es Vorschrift ist. Ahnung haben sie kaum und wenn der Autopilot aufgibt fangen sie erst an zu suchen. Zum sinnvollen Reagieren aus dem Gedächtnis sind sie nicht in der Lage. Selber lesen ist mühsam. Eine ziemlich brauchbare Begleitung gibt es von Juan Browne: https://www.youtube.com/playlist?list=PL6SYmp3qb3uPp1DS7fDy7I6y11MIMgnbO

    3. Eine Verbesserung des Programmierstils richtet in dieser Situation überhaupt nichts aus. Andererseits freue ich mich, dass heute selbstverständlich ist, was durchzusetzen mich vor zwanzig Jahren viel Mühe gekostet hat. Wen ich hier rein gucke bin ich nur noch begeistert: https://github.com/openSUSE/zypper Alles was man wissen will steht jedem und überall zur Verfügung und kann sehr effizient durchstöbert werden. Der Programmierstil kommt bei SUSE nicht zu kurz. Hätte es schon damals git und github gegeben wäre die Einweisung der Doktoranden von TUBS und KIT (damals KfK) ein Kinderspiel gewesen.

    4. Interessanterweise waren Werksstudenten und Doktoranden die Pflegeleichten und die Angestellten die Problembären. Erstere kapierten sofort und machten selbständig weiter. Letztere verwendeten alle ihre Energie darauf die Untauglichkeit eines geordneten Software Konfigurations-Managements zu behaupten.

  21. #27 Christoph
    7. November 2019

    Spannendes Thema. Während meines Studiums hatte ich unter anderem auch eine Vorlesung zum Thema Software Quality Assurance. Code Reviews sind ein sehr wichtiger Faktor, mit dem sich schon viele Fehler ausmerzen lassen.
    Bin selbst auch in der Open Source Szene tätig und in unserem Projekt setzen wir auch auf Code Reviews, um sicherstellen, dass wir eine gute Qualität beibehalten. Und für weniger erfahrene Coder ist es eine gute Möglichkeit ihre Kenntnisse zu verbessern.
    Idealerweise erklärt man die man etwas besser macht.

  22. #28 Karl Mistelberger
    mistelberger.net
    27. November 2019

    völlig erratisches Kommentar – gelöscht