QFQ

QFQ funktionen/reusable-reports Pro/Contra

Pro:
- weniger redundanz
- anpassungen nur an einem ort machen

Contra:
- zusätzliche QFQ Syntax
- Reports werden komplexer, zur Zeit ist jeder Report eine abgeschlossene Komponente für sich
- Funktionen verleiten dazu, general purpose code zu schreiben, der sehr viele conditionals hat. ala: "ich könnte hier eine Funktion schreiben die möglichst allgemein ist und alles abdeckt"

Grundsätzlich sehe ich grosse Vorteile von Funktionen/reusable-reports für Maintainer, die ein QFQ Projekt schon in und auswendig kennen. Aus eigener Erfahrung sehe ich für eine Person, die neu zu einem bestehenden Projekt kommt, eher Nachteile. Zur Zeit ist es für mich möglich, an einem mir fremden Tool eine Änderung zu machen, ohne Angst zu haben, dass dies unerwartete Konsequenzen hat. Wenn beispielsweie eine SQL Anfrage auf einem Report angepasst werden muss, dann kann ich diesen Report verstehen, ihn anpassen und den Report anschauen. Damit habe ich schon den grossteil aller Testszenarien abgedeckt. Wenn wir ein stabiles und wartbares QFQ Tool haben möchten mit Funktionen/Reusable-reports, dann müssen wir meiner Meinung nach auch unittests einführen, um diese Funktionen/reusable-reports zu Testen und ihr Verhalten zu definieren.

Um die Übersicht zu erleichtern, könnten wir die Funktionalität etwas einschränken.
Beispielsweise müsste jeder reusable-report in einem eigenen File sein, das in dem Ordner "reusable-reports" abgelegt ist.
Jdes reusable-report-file hat dann folgende Struktur:

- funktionsname
- funktionsargumente
- funktionsoutput (?)
- unittests
- funktion body

Grundsätzlich sehe ich grosse Vorteile von Funktionen/reusable-reports für Maintainer, die ein QFQ Projekt schon in und auswendig kennen. Aus eigener Erfahrung sehe ich für eine Person, die neu zu einem bestehenden Projekt kommt, eher Nachteile. Zur Zeit ist es für mich möglich, an einem mir fremden Tool eine Änderung zu machen, ohne Angst zu haben, dass dies unerwartete Konsequenzen hat. [...]

Ich bin völlig einverstanden, dass mit schlecht definierten Funktionen der Einstieg schwieriger werden kann - aber das kann kein Argument sein um Code-Duplication zu fördern. Es macht aber sicher Sinn, wenn wir uns überlegen, wie wir schlechte Funktionen verhindern und was den Einstieg vereinfachen könnte (z.B. einen Report, der alle Referenzen zu einer Funktion zusammenträgt).

Wenn wir ein stabiles und wartbares QFQ Tool haben möchten mit Funktionen/Reusable-reports, dann müssen wir meiner Meinung nach auch unittests einführen,

Ein stabile, wartbares Projekt braucht bereits jetzt Tests. Denn ohne Funktionen sind die Chancen viel zu gross, dass ich von den 3 Orten, an denen ich die gleiche Funktionalität brauche nur 2 anpasse. (Das gilt für neue Mitarbeiter an einem Projekt ganz besonders, insofern machen die Funktionen den Einstieg auch einfacher.)
Ich unterstützte aber natürlich sofort, wenn QFQ auch Unittests unterstützt.

Um die Übersicht zu erleichtern, könnten wir die Funktionalität etwas einschränken.
Beispielsweise müsste jeder reusable-report in einem eigenen File sein, das in dem Ordner "reusable-reports" abgelegt ist.

Ich glaube nicht, dass das Verteilen in einzelne Dateien einen relevanten Mehrwert bietet. (Es macht es aber sicher schwieriger den Überblick zu behalten wenn sich Funktionen gegenseitig aufrufen.) Ich würde mich eher an python-Docstrings (incl. Doctest) orientieren.
Für die Übersicht wäre wohl wirklich ein Tool hilfreich, dass mir zeigt, von wo eine Funktion überall aufgerufen wird.