Hallo Team, Weil heutiges Meeting abgekürzt war und ich keine Zeit um Pakete zu reden hatte, schreibe ich jetzt diese E-Mail. Ich habe während letzter Woche sehr viel auch außerbetriebliche Zeit ins Thema investiert. Ich möchte nicht das einfach so liegen lassen, da es für mich sehr wichtig ist. Ich rücke das Thema auch vor, weil ich nicht glaube, dass es ansonsten natürlich bei uns selbst entwickelt. Traso Packages ist ein Thema, was soll am Ende viele Vorteile bringen. Das Wort "uns" ist hier auch wichtig, da ich mehrmals gefragt wurde "was soll es unseren Kunden bringen". Das ist nicht für unseren Kunden gedacht, und ist für die nicht direkt relevant. Das ergibt uns, als Entwickler, eine Bessere Arbeitsumgebung. Eine Umsetzung von svn auf git hat unseren Kunden auch direkt nichts gebracht. Würde ich aber heute als Bewerber kommen und hören dass hier noch svn verwendet ist, würde ich aufstehen und weg gehen. Ich würde mich nicht wundern, wenn es Bewerbers gibt, die wegen eine ältere PHP Version abgesagt haben. Eine sinnvolle Projektstruktur ist in der selben Reihe. Ein nicht technisches Beispiel ist - bequeme Sessels. Das bringt unseren Kunden auch nichts, wir könnten dann die billigere Stuhle haben. Pakete und deren Verwaltung ist ein Industriestandard (nicht nur in der PHP-Welt, aber in das ganze IT), und das ist nicht grundlos so. Ich wiederhole nochmal die Vorteile die wir dadurch bekommen können: 1. Strukturierung des Codes. Modularisierung ist selbstverständlich ein richtiges Konzept. Durch die Umsetzung, kriegen wir die Pakete, die können logischerweise nicht kleiner gemacht werden. Und dann auch größere Pakete, die von den kleineren bestehen. Ein logisches Baum-Struktur wird uns helfen auf die spezifische Teile konzentrieren, als auch besser entkoppeln. Wenn die Firma wachsen wird, es werden immer mehr Leuten die an den gleichen stellen Arbeiten. Wenn ich mir vorstelle, wie würde es aussehen mit 50 Entwickler und unseres aktuelles Struktur, ist mir gruslig. 2. Bessere Übersicht auf die Bestandteile die wir haben. Das bedeutet nicht unbedingt, das wir danach weniger Dateien oder Verzeichnisse haben, sondern sieh Punkt 1., dass die strukturiert werden. Es werden nur einige Verzeichnisse unter /packages geben: Core, Hotels, Flights, Bookings, Export. Eventuell ein Paar mehr, aber grundsätzlich schon klar um welcher Bereich es gerade geht. 3. Bessere Übersicht welches Teil arbeitet mit dem anderen zusammen. Kein Spagetti-Code mehr. Obwohl ist Spagetti immer gern esse, im Code gehört das nicht. Währen ich ein Beispiel Paket gebaut habe, habe ich schon eine Stelle gefunden, die, für mich unerwartet, eine Abhängigkeit hatte. 4. Reusability. Wer werden fähig unseren Code mehrmals verwenden in den parallelen Projekten, wie z.B. Autocheck, oder irgendein Business-Intelligence-Tool. 5. Kleiner Umfang für einer Entwickler. Wenn Artur oder ein externer Entwickler sich einarbeitet, ist das immer einfacher mit kleineren strukturierten Teilen zu arbeiten. Die Umsetzung kann unseren Code auf das neue qualitative Niveau bringen, und dann, bekommen unseren Kunden davon schon was: weniger Bugs, und dadurch mehr neue Features. Ich habe, wie gesagt, schon eine Menge Zeit investiert und habe die Beispiel Pakete gebaut, die findet man unter: http://stash.app.activate.de/projects/PKG Die externe Pakete, findet man unter: http://stash.app.activate.de/projects/EX Dann weiter, habe ich ein xres Branch erstellt: http://stash.app.activate.de/projects/PHP/repos/xres/browse?at=refs%2Fheads%... So würde es aussehen. Die Idee mit den submodules war obwohl interessant, leider nicht passend. Ich habe sie ausprobiert und mehrere Probleme sind aufgetaucht. Ich habe also die andere Zwischenlösung gefunden: ein package Verzeichnis hat ein symlink von jedes Modul vendor Verzeichnis. Z.B.: modules/xhotels/vendor -> ../../packages. So, jedes Modul hat eigene Abhängigkeiten in composer.json definiert, die werden dann alle in ein Verzeichnis installiert (/packages, oder auch vendor) und mit xres commitet. So passt es in unseres heutiges Struktur und verursacht keine Probleme. Ihr könnt auch im xhotels das SIDX Importer (import_SIDX.php) euch anschauen (packages Branch), der verwendet schon die Klassen vom Package. Also, das ist schon alles fertig, man muss nur die Hand ausstrecken und nehmen. Ich hoffe auf eure positives Feedback (Das, dass es ein Problem ist wenn ein Paket jetzt nur eine Klasse enthält ist kein konstruktives Feedback). VG Viktoras -- Mit freundlichen Grüßen Viktoras Bezaras - Entwickler - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 355 740 44 E-Mail: v.bezaras@traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850