Code Reviews

1. Was hast Du Dir im Allgemeinen Gedacht? Was war, was Du Dir dabei gedacht hast, es so zu schreiben?
2. Abwägung von Alternativen, u.a. um eine Basis heraus zu arbeiten von Dingen die bekannt sind

Rest besteht aus klassischen Review-Themen:

1. Overall Quality,
2. wiederverwendbarkeit vs spezialisiert
3. Stil-einhaltung objektiver Kriterien(Variablenbenennung($i ist bs), Funktionsbenennung("doSomething" ist BS))
4. Allgemeine Prinzipien(Funktionen sollten nicht >100 LOC sein)
5. Flow (Lese, Ausführung, allgemeine Reihenfolge)
6. Erkennen von Patterns, aber nicht explizite Nutzung davon(es sollte niemals eine Sache geben, deren Name "strategy"|singleton|observer|… ist!)
7. Performance vs Lesbarkeitsabwägung in der behandelten Sprache in Produktiveinsätzen; OPCache z.B. entfernt Dir zu 98% des File-Loadings-Overheads(wenn richtig konfiguriert, können wir auch gerne durchgehen falls es dich interessiert), im Schnitt 50% der Funktionsaufrufskosten - das bedeutet aber nicht, dass man alles als Funktion machen muss, was länger als 3 Zeilen ist! Der Overhead wäre gigantisch!)
8. Do-one-thing-and-one-thing-only innerhalb einer Funktion, als Augenmerk bei Dir aktuell

Nach den 30-45 Minuten p.P. würde ich gucken dass wir uns Dinge heraussuchen, die unserer Meinung nach gut geschrieben aussehen, und dann jeweils erläutern, wieso es gut aussieht. Innerhalb dieser Diskussion könnten wir auch anderes Behandeln, z.B. andere Sprachen und Vor- vs Nachteile von Sprachkonstruktten erläutern, oder Methodiken im allgemeinen