Bearbeiten von „KIF440:Clean Code (in der Hochschule)“

== Clean Code Einführung ==

Zu Beginn haben wir uns überlegt, was ''schlechten'' Code ausmacht und wie dieser zustande kommt.

=== Smells of Bad design ===
* Rigidity: Es ist aufwändig etwas am System zu ändern, simple Änderungen haben große Konsequenzen
* Fragility: Kleinste Änderungen führen zu Fehlern und Problemen
* Immobility: Teile des Codes könnten auch woanders nutzbar sein, sind aber in dieser Form nicht verwendbar
* Viscosity: Bei Änderungen ist ein Hack einfacher, als eine Änderung, die das bestehende Design erhält. Es ist einfacher den falschen Weg zu wählen als den richtigen
* Needless Complexity: Unbenutzte Methoden, Variablen, ..., Vorbereitung auf zukünftige Änderungen, die es nie geben wird
* Needless Repetition: Copy-Paste, weil nötige Abstraktionen fehlen. Problematisch z.B. bei Bugfixes etc
* Opacity: Code ist schwer zu verstehen

Wir haben uns ein Beispiel angesehen, wie es dazu kommt das Code "rigid" wird und mit welchen Methoden man das verhindern kann. Konkret ging es bei diesem Beispiel um das Prinzip der Dependency Inversion.

Anschließend haben wir uns mit Unit Tests und Test Driven Development beschäftigt.

=== Three laws of TDD ===

* Write no production code except to pass a failing test
* Write only enough of a test to demonstrate a failure
* Write only enough production code to pass the test

Und zusätzlich die folgende Merkregel:

* While the tests get more specific, the code gets more generic!

Wir haben dann anhand eines einfachen Beispiels das Prinzip von TDD ein wenig geübt und dabei auch über die Vor- und Nachteile diskutiert.

== Clean Code in der Hochschule ==

Austausch-AK als Nachfolgeveranstaltung zur Einführungsveranstaltung

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