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