• Als Spam markieren
• Beitrag melden

• 
  Diese Gruppe Alles

• Archiv
• RSS-Feeds

• Kontakt
• Hilfe
• Impressum
• Datenschutz

Re: Joomla! Oder wie Mirgation nicht aussehen sollte

Torsten Zühlsdorff schrieb:
> Niels Braczek schrieb:
>
>> Komponenten verwenden Joomla! als Framework. Insofern gibt es da
für
>> diese Art von Extensions keinen Unterschied. Die beiden anderen Formen -
>> Plugins und Module - haben strenger definierte Schnittstellen.
>
> Gibt es eigentlich einen Mechanismus gleich welcher Art, der darauf
> achtet, dass diese nur die definierten Schnittstellen nutzen?

Nein, das nicht; Module und Plugins werden insofern "kontrolliert", dass
sie innerhalb von Funktionen aufgerufen werden, also (theoretisch) nur
begrenzten Zugriff auf Dinge außerhalb haben.

>> Zu 1 und 3 stimme ich dir zu; bei 2 kann ich das nicht, weil ich nicht
>> weiß, was du unter "weite Teile" verstehst und welche
Anforderungen du
>> an die Inline-Doku stellst.
>
> "Weite Teile" bedeutet bei mir in diesem speziellen Fall einfach ein
> Großteil dessen, was ich rein zufällig geöffnet
habe - etwa 15 Dateien.
> Der Rest war Induktion.

Ok.

> Meine typische Anforderungen an Inline-Doku:
> - vernünftige Erklärung der Klasse
> - vernünftige Erklärung der Methoden (ink. Parameter,
Rückgabewerten
> usw., was keine Beschränkung auf die Datentypen sein soll)

Einverstanden.

> - eine Prefixierung von Variablen, um auf ihren Datentyp schließen zu
können

Das ist Geschmackssache; ich mag das gar nicht. Ich finde, das stört die
Lesbarkeit des Codes erheblich. Allerdings verstehe ich die Motivation
dafür, das einzusetzen.

> - eine gute Benennung von Variablen, Methoden, Klassen und Konstanten
> - eine ordentliche Einrückung

Das finde ich ist im Großen und Ganzen gegeben. Es gibt nicht viele
Stellen, an denen gegen den Styleguide verstoßen wird; was irgendwie
fehlt, ist die (Nutzung der) Möglichkeit, die Einhaltung des Styleguides
zu prüfen und ggf. durch Umformatierung zu erzwingen.

>> Jeder Patch wird von wenigstens drei Leuten getestet, bevor er
>> freigegeben wird. Das ist zwar nicht so gut wie Unit-Tests, aber
>> durchaus geeignet, die Funktionalität des Codes zu
gewährleisten.
>
> Das hängt ganz stark von den Testern an sich ab. ;)
>
> Außerdem sind - meiner persönlichen Meinung nach - 3 Tester
bei einer
> Software, die unter einer Hunderschaft an Kombinationen von Umgebung und
> Konfiguration laufen kann, einfach nicht genug.

Ich teste unter Linux und Windows, jeweils mit 4 PHP-Versionen. Ich
mache das meist mit Skripten, die den Fehler mit der Fassung vor der
Behebung provozieren. Das sind zwar keine Unit-Tests, aber das
funktioniert ganz gut. Diese Vorgehensweise hat übrigens die
Joomla!-Crew zu den Unit-Tests inspiriert.

>>> Ich weiß,
>>> - dass verschiedene Joomla! Releases einige dutzend, manchmal sogar weit
>>> über 100, Bugfixes und Änderungen hatten
>>
>> Das ist eher normal und gilt wohl für so ziemlich jedes Projekt.
>
> Normal != Gut. Mal abgesehen davon, dass es überhaupt so viele Bugs
> gibt, ist das nicht sehr hilfreich. Die Gefahr bei einem Upgrade einen
> neuen Bug zu erliegen, ist deutlich zu hoch.

"Viele Bugs" könnte ja auch bedeuten, dass aufgrund der
Gründlichkeit
der Community besonders viele Ungereimtheiten gefunden werden.
Allerdings kann ich das nicht mit Fakten unternmauern ;-)

> Auch erschwert es bei einem
> neu auftretenden Bug die Suche nach dem Fehler - schließlich gibt es
> über 100 Änderungen. Und ich bezweifle sehr stark, dass
automatisierte
> Fehlersuchalgorithmen verwendet werden.

Da zweifelst du wahrscheinlich richtig. Zumindest habe ich nichts
Gegenteiliges gehört. Mit der Fehlersuche in Joomla! habe ich allerdings
nie Schwierigkeiten gehabt - im Gegensatz zu der in manchen Erweiterungen.

>> Logisch. Mit Bugfixes *können* Bugs auftauchen. Ohne sind da mit
>> Sicherheit welche. Was soll das also aussagen?
>
> Das die Wahrscheinlichkeit neuer Bugs mit der Anzahl der Bugfixes steigt
>   und es sinnvoller ist, weniger Bugs, dafür noch besser getestet,
zu
> beheben. Oder grundlegend über den Entwicklungsprozess nachzudenken
-
> aber das ist bei Open-Source-Projekten immer außerordentlich schwer.

Das leuchtet mir nicht ein. Warum soll es besser sein, ein einfaches
Problemchen nicht mal eben zu lösen, sondern es von Release zu Release
mitzuschleppen? Selbst wenn (was bisher eher selten vorkam) so ein Fix
nicht (ordentlich) funktioniert, ist damit kein neuer Bug hinzugekommen.

>> Dass die Zahl der Bugs aber ständig sinkt, sieht man, wenn man
den
>> Tracker beobachtet. Also kann die Vorgehensweise so verkehrt nicht sein.
>> Sie kann durch Unit-Tests noch verbessert werden, und das wird ja auch
>> getan.
>
> Ihr kennt die absolute Zahl der Bugs? ;)

Sicher, sie ist PI/E mal so groß wie die Zahl der Einträge im
Tracker ;-)

>>> - Extensions setzen auf den Kern auf
>>
>> Gib mir das bitte nochmal etwas verboser. Ich bin mir nicht sicher, was
>> du damit meinst.
>
> Ich habe dich nur zitiert. :P Du hast behauptet, dass Extension zum Teil
> direkt auf den Joomla!-Kern aufsetzen.

Zumindest nicht mit dem Begriff "auf den Kern aufsetzen". Ich verstehe
nicht, was du mit diesem Begriff meinst; so wie ich ihn verstehe, kann
ich daran nichts Verkehrtes finden.

>>> Ich
>>> könnte auch bemerken, dass es keine Nomenklatur gibt.
>>
>> Was meinst du damit? Eine Namenskonvention gibt es:
>> http://docs.joomla.org/Coding_style_and_standards#Naming_Conventions
>
> Ok. Dann verbessere ich mich auf: Die Namenskonvention sieht keine
> Variablenprefixierung vor. Ich persönlich empfinde es als
> außerordentlich wichtig, den Datentyp am Variablennamen ablesen zu
können.

Ich finde Konstrukte wie bolState grausam; ich bevorzuge isConnected -
nur um mal ein Beispiel zu nennen, aus einer Erweiterung, die ich gerade
nutzbar mache.

>>> Oder das an vielen
>>> Stellen im Quelltext Konstanten hätten verwendet werden
sollen.
>>
>> Beispiel?
>
> $Id: application.php 9764 2007-12-30 07:48:11Z ircmaxell $
>
> Zeile 154:
> [..] user->get('gid') < '23' [..]
>
> Da die gid (?) "23" offensichtlich eine Besonderheit ist
(Verschwörung!
> ;) ), fehlt eindeutig die Erklärung, warum dem so ist. Die
> Methodenbeschreibung sagt lediglich "Display the application." - der
> Quellcode enthält keine weitere Beschreibung. Wofür
steht also 23?
> Das ist ein typischer Fall von bösen[tm] Zahlen im Quellcode.

Stimmt. ADMINISTRATOR wäre sprechender. Auf den Bezug zu den Illuminaten
war ich noch gar nicht gekommen ;-)

>> Das dachte ich ja auch, aber API-Dokumentation und Inline-Dokumentation
>> sind nicht identische Begriffe. API-Dokumentation ist vorhanden und kann
>> unter docs.joomla.org eingesehen werden.
>
> Wo ist für dich der Unterschied zwischen API- und
Inline-Dokumentation?
> Für mich ergibt sich das eine aus dem Anderen.

Nicht zwingend. Inline-Dokumentation muss sich nicht (nur) auf das API
beziehen. Das API kann unabhängig davon auch extern dokumentiert sein.
Aber es ist mir klar, dass im Idealfall die API-Doku so vorliegt, dass
eine IDE sie für Hints verwenden kann. Damit ließe sich eine
externe
Doku auch viel schneller produzieren. Das ist zugegebenermaßen nicht
gegeben.

MfG
Niels

--
| http://www.kolleg.de   ·   Das Portal der Kollegs in Deutschland |
| http://www.bsds.de   ·   BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla!
Content Management |
------------------------------------------------------------------

Antworten