[TYPO3-german] Ext/Core-Code-Anpassung

[Stephan Schuler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hallo zusammen.


Selbst den Core oder Extensions zu patchen ist immer eine heikle Sache, aus den genannten Gründen.

Wenn fremder Code erweitert werden soll gibt es da für mich eine recht strikte Reihenfolge:

Sofern ein Hook an einer halbwegs passenden Stelle vorhanden ist verwende ich diesen.
Wenn an der optimalen Stelle für meinen Eingriff kein Hook steht aber einige Zeilen darüber oder darunter versuche ich, meine Änderungen so zu formulieren, dass sie mit diesem existierenden Hook zurecht kommen.

Wenn das nicht funktioniert fahre ich gerne zweigleisig. Ich erweitere die bestehende Extension um einen Hook der meinen Ansprüchen genügt. Diese Änderung geht als Changerequest an den Originalautor.
Parallel dazu XCLASSe ich die betreffende Klasse und überschreibe dort die Methode die mir nicht genügt durch die von mir erweiterte Version deren Patch an den Autor ging.
Anschließend kann ich die Originalextension wieder in den Ausgangszustand zurückversetzen.

Auf die Weise bekomme ich (hoffentlich) in einer zukünftigen Version meinen Hook, solange das noch nicht er Fall ist verwende ich meinen eigenen (eben auch wenn die nächste Version meinen Hook noch nicht enthält) und kann trotzdem (halbwegs) sicher updaten.


Für mich sind XCLASSes nur minimal besser als Patches. Eine Klasse kann eben nur ein einziges mal ge-XCLASS-t werden, und wenn das bereits eine andere Extension tut kann ich da mit meiner nicht mehr ran -- sofern ich keine XCLASS der XCLASS machen möchte. Aus diesem Grund ist ein Hook (auch einer den ich erst als Changerequest anfragen muss) immer besser als eine XCLASS.


Man sollte übrigens im Rahmen einer gesunden Kundenbeziehung frühzeitig den Mut haben, seinen Kunden über seinen Fehlkauf zu informieren. Wenn ich auf eine unsauber manipulierte Stelle im Quellcode stoße muss der Kunde davon erfahren. Dann darf der Kunde entscheiden, ob er zukünftig mit der manipulierten Version weiterleben möchte oder die Situation von mir überarbeiten lässt.

Spätestens beim nächsten Update steht der Kunde dann vor der gleichen Frage mit einer zusätzlichen Option: Er kann dann wahlweise mit der alten (ggf. unsicheren) Programmversion weiterleben, kann mich mit einem Update unter Beibehaltung der Fehlsituation beauftragen oder mit einer Überarbeitung.
Aufwand und Preis davon steigen zunächst von links nach rechts. "Wir lassen es wie es ist" kostet nichts, "wir überarbeiten XX% eines recht umfangreichen Projekts" kann schnell teuer werden. Die Änderungen aus dem alten Quellcode zu extrahieren (diff) und in die neue Programmversion zu spielen (patch) ist auf den ersten Blick ein kostengünstiger Mittelweg. Wenn dann allerdings Nacharbeiten anfallen und der Vorgang alle paar Wochen zwecks Update wiederholt werden muss, rechnet sich dieser Mittelweg allerdings recht schnell doch nicht mehr.
Insbesondere muss dem Kunden klar gemacht werden, dass die Reimplementierung eines vermurksten Projekts um Updates durchführen zu können zunächst nichts mit dem Update an sich zu tun hat. Kunden dürfen auf keinen Fall den Eindruck gewinnen, dass das Softwareupdate das ich gerade anbiete im Bereich 10'000€ liegt. Wenn da (z.B.) eine ehemals in mehreren Wochen implementierte Shoplösung ein verstümmeltes tt_products verwendet sollte aus der Aufwandsaufstellung recht eindeutig hervorgehen, welcher Anteil auf "Aufräumarbeiten" und welcher auf das eigentliche Update entfällt. Ein "Update wie es monatlich kommen kann" für 10'000€ wird der Kunde bei mir so schnell nicht beauftragen, und vermutlich auch so schnell nichts anderes mehr wenn ihm nicht klar ist, dass nur ein geringer Teil meiner Kalkulation wiederkehrende Posten sind.


Zusammengefasst: Eigene patches grundsätzlich auf ein Minimum reduzieren, fremde Patches mit dem Kunden klären.


Grüße,



Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Internet: http://media.netlogix.de

- --
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: mailto:info at netlogix.de | Internet: http://www.netlogix.de/

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt

________________________________________


Von: typo3-german-bounces at lists.typo3.org [typo3-german-bounces at lists.typo3.org] im Auftrag von Oliver Klee [typo3-german-02 at oliverklee.de]
Gesendet: Samstag, 16. Oktober 2010 11:25
An: typo3-german at lists.typo3.org
Betreff: Re: [TYPO3-german] Ext/Core-Code-Anpassung

Hi,

Am 15.10.2010 12:52, schrieb Mario Batz:
> - Änderung von Sprachdateien

Besser per TS Setup machen.

> - Modifizierung ganzer Funktionen und Klassen
> - Original-Ordner/Dateien durch Symlinks ersetzen
> - etc.

Ganz böse - eben weil man dann (wie du schon geschrieben hast) nicht
mehr updaten kann.

Georg und Christian kann ich nur zustimmen - wenn's per Hook oder XCLASS
nicht geht, sollte man einen Patch an den Extension-Autor schicken bzw.
die Änderung bei ihm/ihr beauftragen.


Oli
- --
Certified TYPO3 Integrator | TYPO3 Security Team Member
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.0.0 (Build 2881)
Charset: Windows-1252

wpUDBQFMuYP/pp0IwsibV8MBCGVnBACcxZCKzOocLC1zU85WEwFIrXBx3U/D0jXf
mRskR04em25GSjSTePlkGxInCfFG3PAKIbKN/r8EEVq7M3gy5Mt1WfG5ln/wvuJB
43T2qK7+TddVi53de4sNhWTb8A+NXwXsFkWdQWM0Z5UWQYePmOQzZN23M6uSC+wE
siy7WOElvA==
=hqGO
-----END PGP SIGNATURE-----