KIF440:Clean Code (in der Hochschule)

Protkoll vom Clean-Code-Austausch-AK

Nachfolgeverantsaltung zur Einführungsveranstalltung <protokoll-link-dorthin>

Qualitatives Clean Code in der Hochschule - Sollte man das tun? (Vor-/Nachteile) - im normalen Lehrbetrieb - wartbarer/weiterentwickelbarer Code - ...

Vermittlung in der Uni:

• Uni Heidelberg
  • Python
  • zweites Semester angesprochen
  • stark Dozentenabhängig
  • ein ganzer Tag Programmierkurs (Pflicht) test-driven development (TDD)
  • wurde auch in der Klausur gefragt
• Uni FFM
  • auch Python
  • Einführung in die Programmierung: es gibt Abzüge für hässlichen Code - mit Guidelines zum dran halten
  • später wird nicht mehr so viel Wert drauf gelegt
  • In Projektarbeiten durchaus relevant
  • nicht TDD
  • Nachfrage Styleguide:
    • Ordentliche Var-Benennung
    • Vermutlich der orignale von den Entwicklern
    • TODO Frankfurt <Link>
    • Sinvoll? -> Schwer zu sagen, striktes Festhalten kann auch hinderlich sein - man kann es zusätzlich auch stark übertreiben, sehr subjektiv
    • Autoformat macht schon die meiste Arbeit
• HS Karlsruhe
  • Java Guides sehr sinnvoll
  • von Prof. zu Prof. unterschiedliche Anforderungen/Sonderwünsche/eigene Vorstellungen
  • JUnit Test sind Teil der Lehre
• Freiburg
  • Bei allen Veranstalltungen mit Abgabe gibt es Guides und Tests
  • Später wurden auch UnitTests eingeführt
  • Es gab Übungen zu TDD
  • Praktika und Abschlussarbeiten: Praktika ja, bei Projekten wird mehr Wert aufs Ergebnis gelegt
• HS RheinMain, Wiesbaden
  • In Softwaretechnik-VL kamen Tests vor
  • Damit gearbeitet wurde eher weniger
  • "TDD" etc. höchstens als Schlagwort auf einer Folie
  • "UnitTest" kommt im Modulhandbuch nicht vor
• Bremen
  • Clean Code Aspekte wurden angesprochen
  • in Vorbereitungen für Sotwareprojekt wurde es ausführlicher behandelt
• Freiburg
  • TDD wurde gemacht und es wurde gegen die Tests gecoded (gegebene Tests, löse die Fehler)
• HU Berlin
  • im Master gibt es ein passendes Modul
  • aber nur durch 'Eigenart' des Profs
  • spielt eher eine kleine Rolle
• Bonn (früher und leider auch heute)
  • Pascal als Einführung (mittlerweile Java)
  • Es war nicht interessant WIE der Code aussah
  • Wurde auch nicht besser
  • In Softwaretech wurden nur Patterns runtergebetet
    • keine (ordentliche) Versionskontrolle
    • kein Projektmanagement
    • keine Unittests oder ähnliche Vorgehensweisen (wenn überhaupt nur beiläufig)

Versionskotrolle Erfahrungen (GIT, 'Mail', 'Dropbox')

• Uni Bremen: GIT-Repos werden bei Übungen abgeben früher SVN
• Uni Paderborn: Einreichen gedruckt und per Mail, ST Praktikum mitlerweile GIT
• Uni Jena: Grundlagen Übungen in gedruckter Form und Präsentation mit Korrekturwünschen der Tutoren, in Projekten wird jede Woche der Code mit dem Prof evaluiert
• Bonn: in einigen Modulen gab es nicht gut umgesetztes SVN - z.B. Fremde Abgaben abpinseln, da frei verfügbar
• HS Karlsruhe: Abgabe per Betreuer / Vorlesung zu Basics Versionskontrolle (SVN) / Gitlab für Projektarbeiten vorhanden

Praktika/Projekte/Absschlussarbeiten

• Lübeck: Masterprojekt - Code soll wartbar und lesbar sein - Betreuer ist aber nicht ausreichend qualifiziert
• Jena: Praktikum - jedes Jahr die gleichen Abgaben - immer von Grund auf neu
• Kiel: es darf nicht die offizielle Lösung eingereicht werden. Es gab sehr gute, aber auch sehr schlechte Umsetzungen
• Regensburg(?): Webablikationen waren gut gelöst, auch professionel umgesetzt - i.A. sehr gemischt
• Karlsruhe: inzwischen auf GIT - auch mit Einführung "Ich stelle lieber SVN vor, GIT hat sich ja noch nicht so richtig durchgesetzt"
• Firmen sind oft sehr rückständig - oft auch Nostalgie von Profs, die Fortschritt in Lehre verhindern

Allgemein

• Man kann guten Code nicht erzwingen, v.a. bei faulen/schlechteren Studis - Systeme sind keine Garantie
• Mehr ein Katalysator für Studis, die gute Leistungen abliefern wollen
• Sehr stark von einzelnen Personen abhängig - eher wenig zentralisierung
• Aus Blick eines HiWis: Bei einem praxisnahen Lehrstuhl wird es dir eingetrichtert, ordentlichen Code zu liefern
• Software-Engineering: Wie oft wird das gemacht?
  • Bonn/Berlin: hauptsächlich nur ein paar UML-Diagramme zeichnen, aber keine praktische Anwendung des Gelernten in einem größeren Projekt
  • Freiburg: etwas arbeiten mit Scrum

Problem: viele kennen gute Softwareentwicklungskonzepte nutzen sie aber nicht. Kann man das ändern?

• ist gegen Tests coden sinnvoll (vor allem bei kleinen Projekten)?
• Code Reviews funktionieren in Bonn ganz gut
• Konzepte sind erst dann sinnvoll, wenn es sich um langfristige Projekte handelt; bei Uni-Aufgaben nicht wirklich sinnvoll
• Test sind i.A. super hilfreich