[vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

Hallo Zusammen!

Nachdem ich wirklich viel Zeit in den Untiefen der MW verbracht habe und
mittlerweile auch ein paar Patches bis ins git steht es mir vielleicht zu
mich zu dem Thema auch mal zu äußern- meine 2cents, auch wenn einige Fragen
sicher reine Geschmackssache nennt.

2013/9/17 Patrik Karisch <patrik.karisch at gmail.com>

> Am 17. September 2013 14:33 schrieb Thorben Thuermer <r00t at constancy.org>:
> >
> > schon doctrine war schon immer overkill fuer das projekt...
>

Zunächst mal muß ich sagen, dass ich die Codebasis wirklich genial finde.
Die Struktur aus Controllern, Interpretern und Views ist auf den ersten
Blick zwar nicht ganz offensichtlich, funktioniert in der Praxis aber
wunderbar.

Ok, das ist jetzt wirklich Ansichtssache. Aus Programmierersicht
> nicht, denn mit puren SQL Statements (ob prepared oder nicht), kann
> ganz schnell ungut werden und führt zu Spaqhetticode. Ein ORM macht
> das OOP-Handling um einiges einfacher. Was die Anwendersicht betrifft,
> ist Doctrine nicht so inperformant. Vorrausgesetzt sind natürlich auch
> die richtigen Indizes.


Das sehe ich etwas anders. Doctrine hat gerade auf langsamen Plattformen
wie dem RasPi einige Probleme- so war es mir nicht möglich trotz Query
Caching wirklich performant zu bekommen.

Ich bin der Meinung Frameworks und passende
> Bibliotheken sind nie ein Overkill. Gut, aber das ist nur meine
> Meinung. Man sollte auch Bedenken, ein Framework bietet die
> Möglichkeit, dass sich das Projekt in größe Konzepte weiter entwickeln
> kann. Mit rein eigenen Code wird das schwieriger. Einarbeitungszeit
> für neue Entwickler ist dann immer recht hoch.
>

S.o.- der Code funktioniert und war für mich gut erweiterbar. Er ist aber
(dank Doctrine) auch nicht rasend schnell- einige Overheads kann mein
letzter Commit mildern.

Dazu kommt, dass die MW jetzt sehr lange stabil war- soweit ich sehen kann
gibt es sehr wenige Änderungen (und damit wohl auch Anforderungen).


> Ich finde ja eher MySQL für die Art von Daten ineffizient.
>

Solche Kommentare finde ich besonders schwer zu greifen. Es ist halt eine
Datenbank und relationale DBs eignen sich i.A. ganz gut für "die Art von
Daten". Aber dafür gibts ja das Potential weitere DBs zu unterstützen.


> > der bugtracker ist ohnehin tot - keine aktivitaet seit 2012-03...
>
> ja, da wäre es mal an der Zeit, einfach mal die Issues auf GitHub zu
> aktivieren. Ansonsten kann es auch einfach sein, das hier noch die dev
> Community fehlt? ;p
>

+1 für Issues im GitHub, idealerweile mit Mail an die Liste. Habe mit
ebenfalls schwer getan ich mit der Mailingliste anzufreunden.

2013/9/16 Justin Otherguy <justin at justinotherguy.org>

> Hi Patrik,
>
> Am 16.09.2013 um 21:07 schrieb Patrik Karisch:
>
> >> Anders formuliert:
> >> bitte testen und beschweren, wenn etwas kaputt ist.
> > Für das wären Unit-Tests und ein CI-Server gedacht ^^ -> travis-ci.org
> >
> > Zumindestens für die großteil einer Applikation.
> super Idee.
>
> Du hast den Job! ;-)
>
> Im Ernst: wenn du uns helfen kannst, das an den Start zu bringen - mich
> würd's freuen. Und ich wette: nicht nur mich :-)
>

Ich habe bereits einen Satz Unit Tests für diverse Meter- nicht schön aber
funktionieren. Ohne dieses Hilfsmittel hätte ich die Änderungen am Code
niemals machen können und habe damit Fehler in meinem, aber auch Unschärfen
in der Codebasis  entdeckt.
Entwickelt mit PHPUnit- bei Interesse bitte melden!

In diesem Sinne: ich würde mich freuen wenn etwas Schwung in die MW käme.
Primäres Ziel aus meiner Sicht wäre allerdings nicht Funktionalität,
sondern Performance und dazu Unittests als Basis für weitere Optimierungen.
Um ohne Tests arbeiten zu können ist die MW bereits deutlich zu komplex.

In diesem Sinne- Viel Spass beim Basteln!

vg
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20130917/c9a1e14f/attachment-0001.html>