Hallo zusammen, ich möchte gern eine Idee teilen, was ich schon seit einige Zeit hatte. Ich glaube jeder weißt dass classlib ein Codestapel ist. Es gibt bestimmte Probleme, die ich gern angehen möchte. Also Probleme: 1. Unstrukturiert. Sucht ihr auch nach der Dateien mit "Find in path" oder Shift+Shift, da es überhaupt nicht klar ist wo das Ding liegt? 2. Hat irgendjemand eine gute Ahnung was da liegt und was nicht? Ein Verzeichnis von alle Klassen oder so? Ich glaube man kann doch noch Dinosaurier Knochen finden. 3. Nehmen wir eine Beispiel Klasse. Wer verwendet diese Klasse? Welche Module? In eine Factory, wo der Name vom String aufgebaut ist? 4. Unspezifische Namen. classlib/Exporte, classlib/Request, classlib/Debug. Hotel Exporte oder Flug? Request an wem? Welches Debug (wie haben doch 3, oder)? Ich meine, kann man verstehen worum es geht ohne alle im Büro nachzufragen? 5. Wenn ich eine Klasse ändern möchte, die ist vom alle Modulen verwendet ist, tja.. viel Spaß beim Testing. 6. Wenn ich nur eine Module separat verwenden möchte (z.B. ganz spezifische Data-Machine nur für ein Flug Import) muss man trotzdem komplette lib mitnehmen. Ja, ich weiß, es geht irgendwie noch. Brennt nicht. Kann man gewöhnen. Die Lösung die ich vorschlage ist: Traso Packages. Eine interne Repository mit verschiedenen einzelnen unabhängigen Pakete, die werden mit Composer gesteuert. Unseren eigenen Packagist. Was bringt das? 1. Strukturiert. Wenn ich z.B. HBD Client Klasse brauche - suche ich nach HBD Packet. Im Paket ist natürlich die Klasse, aber auch Tests, Doku, Nutzungs-Beispiele, wenn der Entwickler super fleißig ist. 2. Eine Liste der Pakete gibt eine gute Vorstellung was wir haben. Wenn wir natürlich das richtig organisieren. 3. In jede Module findet dann man eine composer.json Datei, wo ist genau geschrieben welche Pakete braucht diese Module. 4. Namespaces. Die Klassen können immer noch Exporte und Request heißen, jetzt aber in einem Namespace: /Traso/Xres/Flug/Exporte u.s.w. 5. Im composer.json kann man genau definieren welche Version ist hier nötig. Wenn ich eine Request Klasse aktualisiere, ich setze auch bei mir in der Module die Version hoch, die andere Module gehen immer noch mit der alte. Was noch? 6. Wenn wir weitere Tools bauen (Business Intelligence, Import Checker, was auch immer) - man kann ruhig die Pakete verwenden. 7. Paket-Spezifische PR's, Forks, Hirarchy (Paket A verwendet Paket B) 8. Zukünftige Vorteile: wenn ein Praktikant/Bewerber kommt, kann man ihm einzelne Pakete zu Arbeiten geben, statt kompletten xres. Genauso mit Externe Entwicklern ( Thorsten Curschmann). Es muss nicht auf einmal alles umgebaut werden. Wir starten mit kleine Dinge und werden graduell sehen ob es alles uns passt. Meinen Vorschlag wäre auch eine Software wie GitLab zu verwenden (sehr ähnlich wie GitHub, kann aber bei uns installiert werden) - da kann man die Pakete anschauen, PR erstellen, auch Probleme melden u.s.w. Bitte aufpassen, das ist ein Konzept. Ich möchte nur jetzt wissen ob ihr mit der Idee grundsätzlich einverstanden seid. Dafür möchte ich gern Anfang nächste Woche eine Kurze Meeting haben um eure Meinungen zu bekommen. Vielen Dank für die Aufmerksamkeit 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