Hallo, Clean Code (2020)

Abschied vom Aufräumen des Codes

• Ein Kollege checkte den Code, den er die ganze Woche geschrieben hatte, spät am Abend ein.
• Implementierung einer Funktion zum Anpassen der Größe von Formen auf der Canvas eines Grafikeditors.
• Der Code funktionierte, war aber repetitiv.

Am nächsten Morgen...

• Der Vorgesetzte bat um ein persönliches Gespräch und forderte dazu auf, die Codeänderungen zurückzunehmen.
• Zunächst war es ein Schock, doch schließlich wurde klar, dass die Entscheidung des Vorgesetzten richtig war.

Phase

• Die Fixierung auf "sauberen Code" und das Besessensein von der Beseitigung von Duplikaten ist eine Phase, die viele Entwickler durchlaufen.
• Wenn man unsicher in Bezug auf seinen Code ist, ist es verlockend, das eigene Selbstwertgefühl und den professionellen Stolz an messbare Dinge zu knüpfen.
• Sobald man Abstraktion gelernt hat, möchte man jedes Mal Abstraktion einsetzen, wenn man wiederholten Code sieht.

Meinung von GN⁺

• Entscheidend ist, dass das Streben nach der "Sauberkeit" von Code nicht das eigentliche Ziel ist, sondern eine Art Abwehrmechanismus im Umgang mit komplexen Systemen.
• "Sauberer Code" hilft Entwicklern zwar als Orientierung in unbekanntem Terrain, doch man darf sich nicht nur daran festbeißen und muss auch lernen, loszulassen.
• Dieser Text bietet Entwicklern eine interessante Perspektive darauf, wie wichtig Zusammenarbeit und Pragmatismus beim Schreiben und Warten von Code sind.

[GN⁺]

Hacker-News-Kommentare

• "Clean Code" braucht ein Rebranding

  • Das Ziel von Clean Code ist es, Code einfacher und leichter wartbar zu machen
  • Der Wert von Software liegt in ihrer Fähigkeit, sich im Laufe der Zeit verändern zu können
  • Wenn Refactoring die Wartung erschwert hat, dann war das kein Clean Code
  • Dass nicht mit dem ursprünglichen Entwickler über das Refactoring gesprochen wurde, ist ein separates Problem und hat mit Clean Code nichts zu tun

• Code-Duplizierung kann manchmal gut sein, ist aber kein Beleg dafür, dass Clean Code schlecht ist

  • Wenn man 10 Zeilen wiederholter mathematischer Berechnungen durch eine Funktion ersetzt, kann der Code dadurch sauberer werden
  • Pull Requests sollten geprüft und abgelehnt werden, wenn sie die Standards nicht erfüllen
  • Eine Haltung, die die Bedeutung von Clean Code ignoriert, führt am Ende zu einer Codebasis, an der niemand arbeiten möchte
  • Die Lehre daraus ist, dass bessere Kommunikation und mehr Zurückhaltung nötig sind

• Ein Kollege schreibt viel Code per Copy-and-Paste

  • Refactorings sollten zur Review eingereicht werden
  • Wenn ein Vorgesetzter direkt eingreift und anweist, die Änderungen zurückzunehmen, ist das ein schlechtes Zeichen
  • Die Lehre ist nicht, dass Copy-and-Paste besser ist als das Schreiben von Funktionen

• Wahrscheinlich hat die Clean-Code-Version schmutzigen Code ersetzt

  • Man braucht Lehren darüber, wie man im Team arbeitet

• Bei Codeänderungen ist ein Review durch Kollegen nötig

  • Man muss erkennen, dass es an guten Prozessen fehlt
  • Code-Refactoring sollte nur dann durchgeführt werden, wenn es nötig ist

• Im Finanzbereich hat man es oft mit ähnlichen, aber unterschiedlichen Produkten zu tun

  • Es ist wichtig, übermäßige Abstraktion zu vermeiden und dennoch Clean Code beizubehalten

• Sprachen wie Haskell maximieren Abstraktion auf Sprachebene

  • Dadurch wird projektspezifische Abstraktion minimiert, allerdings sind die Lernkosten hoch

• Das Verschieben wiederholter mathematischer Berechnungen in eine separate Funktion ist ein Beispiel für Clean Code

  • Resize-Funktionen zu refactoren, die nur wie die Bildung einer Schnittstelle aussehen, ist falsch

• Eine Erklärung zu schlechter Abstraktion

  • Das Problem ist, zu entwerfen, ohne die künftige Nutzung ausreichend zu berücksichtigen

• Rob Pike sagte: "A little copying is better than a little dependency"

  • Das DRY-Prinzip fügt manchmal Abstraktion hinzu, aber wenn die Abstraktion nicht hinreichend orthogonal ist, verschlimmert sie das Problem eher