spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Guten Tag,

am 2. Januar dieses Jahres habe ich meinen Job bei einem großem IT Unternehmen begonnen. Wir sind die in-house IT und entwickeln Kundennahe Lösungen die wir durch andere Teile des Unternehmens rein bekommen.
Ich arbeite in der Java Abteilung und sollte gleich zu Anfang dieses Übungsprogramm schreiben. Dazu hätte ich von euch gerne einmal Feedback, wie "professionell" das ganze jetzt geworden ist. Feedback von meinem Software Architekten habe ich schon (länger, so wurde es als "geleckt" akzeptiert), aber ich bin aktuell nicht sehr zufrieden wie offenbar in der Industrie Software entwickelt wird, bzw. was in der Java Welt als "best practice" angesehen wird (Stickwort: overengineering).

Also, was haltet ihr davon? Kennt ihr das auch wenn ihr zuhause mit aktuellen Technologien arbeitet und Probleme einfach löst, und euch dann so unproduktiv/altmodisch im Unternehmen vorkommt? Das muss sich nicht unbedingt auf mein Mini-Projekt beziehen, es wäre allgemein mal interessant zu hören wie das bei anderen so läuft.

Noch nebenbei: ich bin überhaupt kein Java Fan, genaugenommen finde ich Java obsolet/veraltet/schlecht designed, aber damit muss ich jetzt erstmal leben.

[Edit]

Dieser sehr gute, nicht mehr ganz aktuelle, Artikel trifft eigentlich was ich denke. Und hier auch erlebe.

Gut die Anforderungen waren am Anfang nicht klar spezifiziert. Mir war die Freiheit gelassen einen sinnvollen und nachvollziehbaren Getränkeautomaten zu implementieren.

Zitat von »Sacaldur«

• Es gibt eine Klasse für einen "Getränkewunsch". Das kann man (in diesem Fall) vereinfachen, da der "Getränkewunsch" nichts weiter als ein Getränk (beschrieben durch das Fach, in welchem es lagert) ist. Am Ende würde man also das Getränk/das Fach des Getränks (oder dessen ID/Nummer) verwenden, statt eine Klasse dafür anzulegen.
  
• Ein "Münzschacht" und ein "Getränkefach" sind meiner Meinung nach unterschiedliche Dinge. Ich bin mir nicht sicher, was mit diesen Beiden Dingen genau gemeint ist, allerdings kann ich mir anhand des Namens nicht vorstellen, dass sie an irgendeiner Stelle anhand ihrer gemeinsamen Basisklasse (also polymorph) verwendet werden würden.
  
• Diverse Exceptions erscheinen mir dem Namen nach nicht unbedingt sinnvoll. Wenn der Benutzer bspw. zu wenig Geld eingeworfen hat, um ein Getränk zu erwerben, dann schalten die meisten Automaten auf einen anderen Zustand um, statt die Eingabe (Getränkauswahl) zu verweigern.
  
• Diverse Setter erscheinen mir überflüssig zu sein, da diese sehr wahrscheinlich nur ein einziges Mal aufgerufen werden (für Getraenkefach.setPreis(int) würde ich das annehmen). Stattdessen wäre ein weiterer Parameter im Konstruktor und ein Verzicht auf den Setter besser.
  
• Getraenkewunsch.getraenkeFachNummer, Fach.inhaltLimit etc. könnte genausogut auf final und public gesetzt werden, wodurch der Getter nicht mehr erforderlich wäre.
  
• Allgemein wird scheinbar einfach probiert, eine Aktion durchzuführen und auf eine Exception zu warten, statt vorher zu prüfen, ob die Operation überhaupt möglich ist. Das ist nur an solchen Stellen nicht der Fall, an denen mit Hilfe des eigenen Code geprüft werden _muss_ (bspw. weil sonst das Fachlimit überschritten werden würde).

Bei Punkt 1 wären wir schon mal beim "Javaland" in dem es nur Nomen gibt. Mein C++ Gehirn hatte an der Stelle auch erstmal keine Klasse angelegt, sondern wie du schon sagst, einfach mit einer Nummer (echten Daten) gearbeitet. Die Klasse wurde dann auf Wunsch hin eingebaut.

Der Punkt 2 wäre mir jetzt auch erstmal nicht aufgefallen. Das entstand dann aus dem Kontext der "Vereinfachung" heraus, da sich beide Klassen Member teilen.
Jetzt wo du es sagst: in C++ hätte ich das wahrscheinlich nie so geschrieben, da natürlich kein polymorphes Verhalten erwünscht ist.

Punkt 3: das scheint eine echt grusselige Praxis in Java Enterprise Bereich zu sein: Exceptions werden als Rückgabewerte missbraucht. Ich hatte im ganzen Programm zunächst keine einzige Exception.
Wobei ich da meinem Architekten recht geben muss: wenn etwas schief geht erkennt man an einer fachlichen Exception was nicht stimmt. Trotzdem werden diese falsch eingesetzt...

Getter und Setter... ja auch eher weils so üblich ist. Ich hatte zunächst wie mit structs in C++ gearbeitet und Klassen als Tupel verwendet, mit public Membern.

Zum letzten Punkt: jop, gefällt mir auch garnicht. Sehe ich auch in dem Projekt in dem ich Arbeite, dass Objekte in ungültigen Zuständen rumdümpeln und eher mit try...catch korrigiert werden (bzw. Loggen -> weitermachen), anstatt dieses Antidesign von vorne herein zu vermeiden.

Um noch mal auf den Kontext einzugehen: mein Ansatz war sehr C++ getrieben, da ich eigentlich selten in Java programmiere. Das war jetzt das erste mal dass ich mit der Business Welt in diesem Bereich zu tun hatte.
Ich finde es sehr interessant, dass sich dort diese scheußlichen Muster eingeschleift haben. Damit will ich garnicht mal alle Java Entwickler beleidigen. Aber mal ehrlich, ist das nicht auffällig? Woran liegt das?
Das Design sieht mir in Java immer Object-Obsessed aus, statt Data oriented zu sein.

Auch finde ich überall Locator, Factories und Singletons... muss das sein? Ich hätte einfach gerne eine Erklärung dafür und vielleicht gute Argumente, um mal etwas dagegen zu halten.

Aber Danke schon mal für dein Feedback Sacaldur

Zitat von »TrommlBomml«

Oftmals stellt sich auch die Frage danach, wie lange die Technologie die man verwendet offiziell Support hat, solange die Software im Einsatz ist.

Wie meinst du das genau? Was ich hier sehe sind gigantisch große Frameworks die irgendwie komisch in das eigene Design integriert wurden.
Wir sind also noch nicht so weit Frameworks wie z.B. Spring einzusetzen, die oberflächlich erstmal besser aussehen. Die ganze Toolchain ist sowieso veraltet...

@Toa: ja die Tests waren überhaupt nicht vorgesehen und wurden dann im nachhinein geschrieben
Im Projekt in dem ich arbeite sind die Tests aber noch hässlicher, teilweise mit > 100 Zeilen in einer Methode... Ich guck mir deinen Code mal an.

@buggypixels: ja ich dachte auch "frisch von der Uni" Mein erster Ansatz lief schon, war naiv und simpel. Sinnvoll aufgeteilt aber eben straight das Problem gelöst, so wie ich es in meinen eher favorisierten Sprachen auch getan hätte.
Meinem Mentor ging es darum die Logik so klein zu zerlegen wie möglich ("single layer of abstraction"). Ich finde es nur begrenzt sinnvoll...

Also nur damit da keine Missverständnisse auftreten: das ist nicht mein Stil, das Programm ist in mehreren Iterationen entstanden in denen ich dann auch häufig gegen die gewünschten Änderungen argumentiert habe. Letztendlich habe ich das geschrieben was jemand anderes sich so vorgestellt hat. Das ist nicht völlig schwachsinnig, ich glaube schon das mein Mentor sein Fach beherrscht. Aber er ist eben mit Java aufgewachsen und hat (denke ich) noch nie in einer anderen Sprache programmiert.

Gegen Java habe ich übrigens gar nicht so viel als Sprache (schon einiges, aber das schreckt mich nicht ab), sondern eher wie damit umgegangen wird. Was sich so als Industriestandard eingebürgert hat (die ganzen viel zu fetten Frameworks und overengineering, excessive Nutzung von Patterns und static Methoden die eignetlich first class functions sein sollten, ...).

[Edit]

@Toa: das System hinter deinen Tests ist entweder deutlich besser designed oder weniger komplex. Das die Tests in dem Projekt in dem ich arbeite wesentlich größer sind ist teilweise schon legitim (200.000 Zeilen Code müssen eben getestet werden), da das Projekt uralt ist. Bei neuen Tests/Projekten verwenden wir Jnario, das sieht dann auch so aus wie bei dir, von der Länge und Komplexität her.

[Edit]

Noch ein Nachtrag, mir ist gerade aufgefallen dass ihr euch das Design auch visuell ansehen könnt:



Gott Münzschacht...