Technisches Update für Firma



  • Hallo zusammen,

    ich komme heute zu euch, um euch nach Erfahrungen zu fragen und nach Tipps, die ihr mir vielleicht geben könnt.

    Erstmal zur Situation:
    Ich arbeite in einer (kleinen, ca. 20 Entwickler) Software Firma, die sich auf Finanzsoftware (im Web per Java) spezialisiert hat. Früher wurden da viele recht individuellen Lösungen für die Kunden gezimmert in mittlerweile etwas veralteten Sprachen (z.B. VB6, was auch teilweise heute noch läuft).
    Mittlerweile sind wir davon runter (oder wenigstens weitestgehend auf dem Weg) und versuchen ein einheitliches Produktpaket zusammenhängend zu releasen. (Versuchen deshalb, weil der Prozess noch sehr chaotisch ist.)

    Ich selbst bin studierender (Bachelor fertig, Master fast) Informatiker, die beiden Senior Entwickler haben vor Jahren ein Informatik Studium angefangen aber nicht abgeschlossen, wir haben 2 weitere Informatik Studenten als Hilfskräfte, ein paar (3 oder 4) Wirtschaftsinformatiker und ansonsten quasi "nur BWLer mit Computerführerschein, die dann mal etwas programmieren", um es mal überspitzt auszudrücken.

    Auf fachlicher Ebene, eben dem ganzen Wirtschaftszeugs, sidn wir denke ich vom Wissen her gut besetzt und auch erfolgreich.
    Auf technischer Ebene sieht es aber eher mau aus (wie ich persönlich finde, aber das denken andere auch).

    Die Kritikpunkte, die ich sehe und die mich stören sind:
    - im Joel Test schneiden wir mit 3-4 Punkten ab (1, 4, ~8, 9)

    - eine einheitliche Architektur gibt es nicht, Auftrennung zwischen GUI, Logik und z.B. Persistenz gibt es quasi gar nicht

    - OOP wird nur schlecht eingesetzt, weil andere hausinterne Tools dies nicht nur nicht forcieren, sondern es eigentlich soagr erschweren (das ändert sich jetzt mit einer neuen Version stärker zum besseren hin), Grundprinzipien wie SOLID werden fast komplett ignoriert(oder sind halt nicht bekannt)

    - jeder Entwickler aht seine x Projekte, in denen quasi kein andere rumfummelt (was gut, was aber aus unternehmerischer Sicht schlecht ist*)

    - Getestet wird nur im BlackBox Verfahren: d.h. der Entwickler schreibt eine Menge mehr oder weniger guter Klickparcours und andere sollen die dann durchklickern, sowas wie UnitTests oder Integrationstest etc. werden absolut gar nicht verwendet, nein, sogar er noch als richtig schlecht angesehen, weil sie ja soviel Zeit kosten ** (meine Meinung ist nicht, dass UnitTests hier als Silver Bullet gegen alles hilft, bitte nicht missverstehen)

    - Projektmanagement und überhaupt Verfahren wie Wasserfall, Scrum, XP, agile irgendwas kommt nicht zum Einsatz. Als Gegenargument kommen genau die Vorteile eben der Agilen Verfahren als grund, dass diese nicht durchführbar sind. Der zweite Mann der Firma hat mal in etwa gesagt: "Scrum? Nee, das geht in der Praxis nicht, das geht nur in der Uni. Am besten is einfach wenn man immer weiter Anforderungen reinkippt wie mans braucht..." ***

    - Sowas wie Continuous Integration ist komplett fremd und wird sogar als nichtsbringend angsehen

    - immer wieder gibt es Versionierungsprobleme: Modul A wurde beim Kunden in Version a ausgerollt, Modul B hat eine Abhängigkeit zu A, braucht aber unbedingt Version b, aber keiner weiss mehr welche Version beim Kunden ausgerollt wurde, die neuste version wiederum kann auch nicht von Produkt A rausgegeben werden, weil die noch buggy ist, und mal eben on-the-fly updates leifern geht auch nicht

    Habt ihr sowas schonmal erlebt?
    Wie geht/würdet umgehen ihr damit um?
    Was habt ihr für Tipps? Erstmal ganz generell
    Was ist in euren Augen wichtig oder unwichtig oder normal?
    Und vor allem: Wie überzeugt man alteingesessene Kollegen, die Entscheidungsbefugnis haben bzw. dem Chef zu Entscheidungen raten, aber alles besser wissen?

    Der ein oder andere fragt sich jetzt vielleicht, warum ich dort noch arbeite wenn ich soviel Kritik übe oder mir da so viel auf den Sack geht. Aber auf der anderen Seite, ist die Arbeitsatmosphäre einfach angenehm, die Kollegen sind super cool und ich bin loyaler Idealist 😉

    Einen Lichtblick gibt es: Es ist eine Schulung geplant (die interne Leute halten).
    Hättet ihr für so etwas Themenvorschläge?

    Viele Grüße 🙂

    * bei einem Projekt ist es letzten Sommer vorgekommen, dass der entsprechende Kollege dauerkrank geworden ist, der der das übernommen ist jetzt auch lange Zeit weg, und jetzt?!

    ** bei einem Projekt müssen riesige (externe) XML Dateien (~60k-100k Zeilen) geparst und auseinander genommen werden, dort steht irgendwo eine Berechnungsvorschrift drin, die allerdings mit deutschen Worten gespickt ist (sowas wie Summe(a, b, c)), und diese Regeln/Vorschriften muss das Programm (korrekt) ausführen. Einen Parser für diese Vorschriften wurde damals nicht gebaut "weil das zulange braucht und zu aufwendig ist", stattdessen wurden diese XMLs händisch (von einem Studenten) durchsucht und die Rechenvorschriften in ein weiteres XML umformuliert, so dass das Programm diese versteht. Theoretisch soweit so gut, nur muss dies ja auch geprüft und getestet werden, was durch einen Menschen jedoch praktisch nicht möglich ist (tausende Zeilen XML Code ok, aber dort geht es um viele viele viele siebenstellige IDs, die miteinander verrechnet werden, das kann ein Mensch nicht länger als 5 Minuten prüfen). Und das schlimme, jedes Jahr werden diese XMLs geupdatet und erweitert und dann muss jedes Jahr wieder ein Mensch dran und prüfen.

    *** Der eigentliche Plan war unser aktuelles Release Ende 2014/Anfang 2015 zu releasen, naja was soll ich sagen, statt im herbst 2014 hat die Testphase Ende Frühling 2015 angefangen und immer noch ist nicht released



  • Wo ist das Problem, wenn du nicht unzufrieden bist?

    Peter Pan^^ schrieb:

    - im Joel Test schneiden wir mit 3-4 Punkten ab (1, 4, ~8, 9)

    Das sind zwölf Lösungsansätze, aber was sind die konkreten Probleme?

    Peter Pan^^ schrieb:

    - eine einheitliche Architektur gibt es nicht, Auftrennung zwischen GUI, Logik und z.B. Persistenz gibt es quasi gar nicht

    Habe ich noch nie in der Praxis irgendwo gesehen. Software ist eben immer das Spiegelbild der Organisation, die sie schreibt.

    Peter Pan^^ schrieb:

    - OOP wird nur schlecht eingesetzt, weil andere hausinterne Tools dies nicht nur nicht forcieren, sondern es eigentlich soagr erschweren (das ändert sich jetzt mit einer neuen Version stärker zum besseren hin), Grundprinzipien wie SOLID werden fast komplett ignoriert(oder sind halt nicht bekannt)

    "OOP"/"SOLID" ist Geblubber, mit dem sich Schulungen verkaufen lassen. Ignorieren.

    Peter Pan^^ schrieb:

    - jeder Entwickler aht seine x Projekte, in denen quasi kein andere rumfummelt (was gut, was aber aus unternehmerischer Sicht schlecht ist*)

    Es gibt keine realistische Chance das ohne automatische Tests, Spezifikationen und Continuous Integration nachhaltig zu ändern.

    Peter Pan^^ schrieb:

    - Getestet wird nur im BlackBox Verfahren: d.h. der Entwickler schreibt eine Menge mehr oder weniger guter Klickparcours und andere sollen die dann durchklickern, sowas wie UnitTests oder Integrationstest etc. werden absolut gar nicht verwendet, nein, sogar er noch als richtig schlecht angesehen, weil sie ja soviel Zeit kosten ** (meine Meinung ist nicht, dass UnitTests hier als Silver Bullet gegen alles hilft, bitte nicht missverstehen)

    Unit Tests sind ein Werkzeug wie jedes andere. Wer meint, dass er das nicht braucht, verschwendet eben mehr Zeit mit Fehlersuche. Du hast keine Chance jemand anderen dazu zu bringen, das zu erkennen. Du kannst nur selber damit anfangen und vielleicht färbt es ab.

    Peter Pan^^ schrieb:

    - Projektmanagement und überhaupt Verfahren wie Wasserfall, Scrum, XP, agile irgendwas kommt nicht zum Einsatz. Als Gegenargument kommen genau die Vorteile eben der Agilen Verfahren als grund, dass diese nicht durchführbar sind. Der zweite Mann der Firma hat mal in etwa gesagt: "Scrum? Nee, das geht in der Praxis nicht, das geht nur in der Uni. Am besten is einfach wenn man immer weiter Anforderungen reinkippt wie mans braucht..." ***

    In so einer Organisation würden formale Verfahren tatsächlich nicht funktionieren. Nach zwei Wochen würden sich alle wieder so verhalten wie vorher. Das ist aber auch nicht so schlimm. Fang erst einmal im Kleinen an. Da kann man schon viel bewirken.

    Peter Pan^^ schrieb:

    - Sowas wie Continuous Integration ist komplett fremd und wird sogar als nichtsbringend angsehen

    Das ist Furcht vor dem Unbekannten. Typisch Expert Beginner bzw "Senior". Einfach heimlich einrichten und benutzen.

    Peter Pan^^ schrieb:

    - immer wieder gibt es Versionierungsprobleme: Modul A wurde beim Kunden in Version a ausgerollt, Modul B hat eine Abhängigkeit zu A, braucht aber unbedingt Version b, aber keiner weiss mehr welche Version beim Kunden ausgerollt wurde, die neuste version wiederum kann auch nicht von Produkt A rausgegeben werden, weil die noch buggy ist, und mal eben on-the-fly updates leifern geht auch nicht

    Wenn das das tatsächliche Problem ist, fang doch hier an. Dokumentiere, was geliefert wurde.

    Peter Pan^^ schrieb:

    Und vor allem: Wie überzeugt man alteingesessene Kollegen, die Entscheidungsbefugnis haben bzw. dem Chef zu Entscheidungen raten, aber alles besser wissen?

    Gar nicht. Und wenn du es doch schaffst, wird es dir niemand danken.

    Peter Pan^^ schrieb:

    Einen Lichtblick gibt es: Es ist eine Schulung geplant (die interne Leute halten).

    Das ist die faule Lösung. "Wenn ich nicht mehr weiter weiß, lade ich einfach alle zu einem Meeting ein." Damit sich das nicht wie Zeitverschwendung sondern nach Arbeit anhört, heißt das dann "Workshop" oder "Schulung". Bringt man sich "intern" normalerweise denn nichts gegenseitig bei?



  • der ganz normale Wahnsinn 😉
    Solange es "so" funktioniert, wird auch nichts geändert. Du kannst nur schauen, dass du in deiner kleinen Welt (also deine Module, Klassen, Funktionen) für Ordnung sorgst.



  • Am wichtigsten ist dass man gut gefrühstückt hat



  • Ich kann eure Situation schlecht einschätzen. Das hört sich schon recht chaotisch an, chaotischer als bei anderen. Andererseits wirfst du aber auch ziemlich viele Buzz Words in den Raum, die sich so anhören, als ob du eher aus dem akademischen Umfeld kommst und wenig Erfahrung hättest.
    Was sagt jetzt z.B. dieser Joel Test und warum sollte man da wirklich irgendwelche Probleme haben? Spontan würd ich sagen, wir erfüllen zumindest grob alle Punkte bis auf die letzten beiden. Ja und? Das ist zu pauschal. Warum sollten Kandidaten im Interview Code schreiben? Sagt gar nichts, ich finde, wir haben grad in der Firma überdurchschnittlich gute Entwickler. Warum sollte man hallway usability testing machen? Unsere Software ist viel zu komplex und viel zu speziell und das meiste passiert sowieso im Hintergrund und muss von Consultants eingerichtet werden. 90% des Codes und der Komplexität bekommt ein Endkunde nie direkt zu Gesicht. Was soll ich also mit dem Punkt anfangen?
    Das mit Spezifikationen ist auch so eine Sache... Wir arbeiten an unserem eigenen Produkt und machen keine (bzw. selten) Auftragssoftware. Da sind Spezifikationen also nicht ganz so entscheidend. Wir schreiben trotzdem welche, die sind halt nicht unbedingt sehr detailliert und es kann sich trotz Spezifikation viel ändern. Sagt erstmal gar nichts aus.

    Dass es keine Trennung zwischen GUI und Logik gibt (wir haben z.B. schon mal nichts, was ich direkt als Persistenz bezeichnen würde, gut, dass ich keine Enterprise Anwendungen mehr schreiben muss) hört sich wirklich nicht gut an. Das muss man nach und nach angehen. Aber auch hier muss man nicht unbedingt übertreiben. Man braucht nicht unbedingt eine 20 Schichtenarchitektur wie aus dem Lehrbuch oder dem Microsoft Patterns Guide, um guten und wartbaren Code zu haben.
    Ich habe bisher selten oder ehrlich gesagt sogar noch nie wirklich funktionierende Unit Tests gesehen. Das ist nicht die Lösung aller Probleme. Es kann viel leichter dazu ausarten, dass man sagt, wir brauchen unbedingt Unit Tests und dann sehr viel Zeit reinsteckt, um Alibi Tests zu schreiben, die sehr viel trivialen Code abdecken und überhaupt nicht weiterhelfen. Da muss man auch schauen, ob man die wirklich sinnvoll integrieren kann und nicht einfach irgendwas machen, weil jemand sagt, dass es gut wäre.
    Du kannst dich gegen alteingesessene Kollegen durchsetzen, wenn du erstmal paar Jahre lang zeigst, dass du was leistest. Dann wird man wahrscheinlich auch auf dich hören. Auf klugscheißerische Frischlinge hört man erfahrungsgemäß nicht 😉



  • Naja, eigentlich kann man nicht viel dazu sagen ... er hat da viele Schlagworte mal eben auf den Tisch geknallt, die jeder für sich komplex sind und viele Bücher, Kurse, Workshops usw. füllen.

    In dieser angeblichen Firma arbeiten offenbar nur Trottel und ein Genie "was würdet ihr tun, was sind eure Tipps?" 🤡

    * bei einem Projekt ist es letzten Sommer vorgekommen, dass der entsprechende Kollege dauerkrank geworden ist, der der das übernommen ist jetzt auch lange Zeit weg, und jetzt?!

    Jetzt hilft nur noch Beten



  • deejey schrieb:

    In dieser angeblichen Firma arbeiten offenbar nur Trottel und ein Genie "was würdet ihr tun, was sind eure Tipps?"

    Nein, genau das denke ich nicht. Das tut mir leid, dass ich da etwas ungenau formuliert habe.

    TyRoXx schrieb:

    Peter Pan^^ schrieb:

    - im Joel Test schneiden wir mit 3-4 Punkten ab (1, 4, ~8, 9)

    Das sind zwölf Lösungsansätze, aber was sind die konkreten Probleme?

    Ich persönlich finde nicht, dass das Lösungsansätze sind O_o
    Aber Joel schreibt einem seiner weiteren Artikel (genau wie du auch sagst), einfach (heimlich) einrichten und benutzen. Problem dabei: ohne große Scripts und allem schaffe ich es nicht einen CI Server aufzusetzen, der Daily Builds macht. Aus dem einfachen Grund, da unsere Software nicht darauf ausgelegt und geplant ist. Letztlich ists (für einen Menschen) nicht schwer zu deployen, aber das automatisiert zu machen stell ich mir eher schwierig vor. Es kann aber gut sein, dass mir da Vorwissen und Erfahrung fehlt.

    TyRoXx schrieb:

    Peter Pan^^ schrieb:

    - eine einheitliche Architektur gibt es nicht, Auftrennung zwischen GUI, Logik und z.B. Persistenz gibt es quasi gar nicht

    Habe ich noch nie in der Praxis irgendwo gesehen. Software ist eben immer das Spiegelbild der Organisation, die sie schreibt.

    Ich sehe das deswegen so: wir machen echte Standardsoftware wie sie in der Uni postuliert wird, wo man als Backend Entwickler dafür sorgt, dass der Fachentwickler einen stress- und problemfreien Tag hat. (unsere Software ist nichtmals übelst riesig, nur um die 500k-600k Zeilen Code glaub ich)
    Und das erste Modul, wo ich damals Kontakt mit hatte, hatte an genau meinem Kontaktpunkt eine(!) Methode mit ~2500 Zeilen, die umgebende Klasse hatte ~7500 Zeilen. Logik, GUI und Datenbank alles zusammengemischt. Wiederverwendbarkeit, Fehlanzeige. Da wurde dann (nicht-triviale) Funktionalität für eine externe Bibliothek gebaut, die woanders auch gebraucht wird, aber eben nicht genutzt werden kann.

    TyRoXx schrieb:

    Peter Pan^^ schrieb:

    - OOP wird nur schlecht eingesetzt, weil andere hausinterne Tools dies nicht nur nicht forcieren, sondern es eigentlich soagr erschweren (das ändert sich jetzt mit einer neuen Version stärker zum besseren hin), Grundprinzipien wie SOLID werden fast komplett ignoriert(oder sind halt nicht bekannt)

    "OOP"/"SOLID" ist Geblubber, mit dem sich Schulungen verkaufen lassen. Ignorieren.

    Wieso? Wir sind in Java unterwegs, d.h. per se wird OOP gefördert/gefordert durch die Sprache. Klar kann man mit statischen Methoden auch dann prozedural entwickeln und ja OOP ist auch kein Allheilmittel. Aber sich etwas an diese Prinzipien halten schadet doch nicht, oder?
    Und bei einer Klasse mit mehreren tausend Zeilen, die als Server, als Datenbank, als Filesystem Umgebung und Errorhandler fungiert werde ich schon stutzig.

    Das Problem ist dabei ja einfach, die Einarbeitung und das Code Verständnis ist schwierig (eins meiner größten persönlichen Probleme) und eine Testbarkeit ist auch kaum gegeben.

    TyRoXx schrieb:

    Peter Pan^^ schrieb:

    - jeder Entwickler hat seine x Projekte, in denen quasi kein andere rumfummelt (was gut, was aber aus unternehmerischer Sicht schlecht ist*)

    Es gibt keine realistische Chance das ohne automatische Tests, Spezifikationen und Continuous Integration nachhaltig zu ändern.

    Könntest du da etwas drauf eingehen?

    TyRoXx schrieb:

    Peter Pan^^ schrieb:

    - Getestet wird nur im BlackBox Verfahren: d.h. der Entwickler schreibt eine Menge mehr oder weniger guter Klickparcours und andere sollen die dann durchklickern, sowas wie UnitTests oder Integrationstest etc. werden absolut gar nicht verwendet, nein, sogar er noch als richtig schlecht angesehen, weil sie ja soviel Zeit kosten ** (meine Meinung ist nicht, dass UnitTests hier als Silver Bullet gegen alles hilft, bitte nicht missverstehen)

    Unit Tests sind ein Werkzeug wie jedes andere. Wer meint, dass er das nicht braucht, verschwendet eben mehr Zeit mit Fehlersuche. Du hast keine Chance jemand anderen dazu zu bringen, das zu erkennen. Du kannst nur selber damit anfangen und vielleicht färbt es ab.

    Das hört sich so an, als wärst du ein Verfechter von Unittests.
    Und ja, in meinen Modulen nutze ich Unittests. Und die haben mir schon Stunden erspart. 🙂

    TyRoXx schrieb:

    Peter Pan^^ schrieb:

    - Projektmanagement und überhaupt Verfahren wie Wasserfall, Scrum, XP, agile irgendwas kommt nicht zum Einsatz. Als Gegenargument kommen genau die Vorteile eben der Agilen Verfahren als grund, dass diese nicht durchführbar sind. Der zweite Mann der Firma hat mal in etwa gesagt: "Scrum? Nee, das geht in der Praxis nicht, das geht nur in der Uni. Am besten is einfach wenn man immer weiter Anforderungen reinkippt wie mans braucht..." ***

    In so einer Organisation würden formale Verfahren tatsächlich nicht funktionieren. Nach zwei Wochen würden sich alle wieder so verhalten wie vorher. Das ist aber auch nicht so schlimm. Fang erst einmal im Kleinen an. Da kann man schon viel bewirken.

    Deshalb strebe diese auch nicht an. Ich hab da mal nachgefragt, aber als Antwort kamen dann Dinge wie: "Das geht eh nicht in der Praxis", "Das geht hier nicht", "Das macht der Kunde nicht mit", "Der Kunde weiss eh nicht was er will, da geht nur evolutionäres Prototyping" ...

    TyRoXx schrieb:

    Peter Pan^^ schrieb:

    Sowas wie Continuous Integration ist komplett fremd und wird sogar als nichtsbringend angsehen

    Das ist Furcht vor dem Unbekannten. Typisch Expert Beginner bzw "Senior". Einfach heimlich einrichten und benutzen.

    Dazu noch eine Frage: was genau ist eigentlich Continuous Integration?
    Ich hab es bisher so verstanden, dass es quasi einen CI-Server irgendwo gibt, der greift regelmäßig auf die Versionierung zu und zieht sich dann die aktuellen Stände, baut/kompiliert sie, eventuell werden Metriken berechnet, automatisierte Tests ausgeführt, und zum Schluss kommt hinten quasi ein theoretisch ausrollbarer Stand raus mit einigen Diagrammen oder Tabellen, wo drin steht, was wie wo die Probleme waren, welche Tests nicht funktionierten.
    Oder verstehe ich das komplett falsch?

    TyRoXx schrieb:

    Peter Pan^^ schrieb:

    Einen Lichtblick gibt es: Es ist eine Schulung geplant (die interne Leute halten).

    Das ist die faule Lösung. "Wenn ich nicht mehr weiter weiß, lade ich einfach alle zu einem Meeting ein." Damit sich das nicht wie Zeitverschwendung sondern nach Arbeit anhört, heißt das dann "Workshop" oder "Schulung". Bringt man sich "intern" normalerweise denn nichts gegenseitig bei?

    Mh, ich glaube eher nur so lala. Java 8 ist seit fast 1.5 Jahren draussen, wir benutzen es auch, bzw. könnten, aber die meisten benutzen noch nur Java 6, weil die Neuerungen einfach nicht bekannt sind (und ja, auch die aus Java 7 nicht). Es kann sein, dass ich (etwas) zu idealistisch eingestellt bin, aber mir wurde immer eingetrichtert, dass man sich als IT'ler fit und halbwegs aktuell halten sollte 😮 (jaja, nicht auf jeden Trend aufspringen usw., schon klar)

    Aber wieso meinst du, sei das die "faule" Lösung? Oder besser gefragt, wie geht es besser?
    Einen externen ranholen? Oder Consulting Unternehmen?

    Danke Tyrox für deine ausführlichen Antworten 🙂

    deejey schrieb:

    Am wichtigsten ist dass man gut gefrühstückt hat

    Ich bin aber kein Frühstücker 😞

    Mechanics schrieb:

    Was sagt jetzt z.B. dieser Joel Test und warum sollte man da wirklich irgendwelche Probleme haben? Spontan würd ich sagen, wir erfüllen zumindest grob alle Punkte bis auf die letzten beiden. Ja und? Das ist zu pauschal. Warum sollten Kandidaten im Interview Code schreiben? Sagt gar nichts, ich finde, wir haben grad in der Firma überdurchschnittlich gute Entwickler. Warum sollte man hallway usability testing machen? Unsere Software ist viel zu komplex und viel zu speziell und das meiste passiert sowieso im Hintergrund und muss von Consultants eingerichtet werden. 90% des Codes und der Komplexität bekommt ein Endkunde nie direkt zu Gesicht. Was soll ich also mit dem Punkt anfangen?

    2 Punkte dazu:
    -Wir haben vor wenigen Wochen einen neuen Kollegen bekommen, studierter Diplomwirtschaftsinformatiker, der als Vollzeit Entwickler eingestellt wurde.
    Als Laie (wie ich es im bin) würde ich erwarten, dass er programmieren kann(egal ob Java, C# oder ..., die Sprache ist ja eher nebensächlich). Aber sein Programmiererfahrung beschränkte sich auf das Zusammenklicken einer Web-Anwendung mit Visual Studio inklusive Datenbankanbindung usw. Auch hier wieder, bitte nicht falsch verstehen, er ist ein netter Kerl und menschlich auch total cool. Aber die (Java) Programmierung hat er jetzt fast komplett lernen müssen und sein Stil ist eben stark prozedural und repetetiv. Er macht halt viele Fehler, die man halt am Anfang macht.
    Ich glaube, wir haben eben nicht (nur) überdurchschnittlich gute Entwickler.

    - Okay, sagen wir von den 12 Joel Punkten können wir den vernachlässigen, grad auch weil wir ein Nischenprodukt entwickeln. Trotzdem könnte es doch eigentlich nicht schaden. 🙂

    Mechanics schrieb:

    Dass es keine Trennung zwischen GUI und Logik gibt (wir haben z.B. schon mal nichts, was ich direkt als Persistenz bezeichnen würde, gut, dass ich keine Enterprise Anwendungen mehr schreiben muss) hört sich wirklich nicht gut an. Das muss man nach und nach angehen. Aber auch hier muss man nicht unbedingt übertreiben. Man braucht nicht unbedingt eine 20 Schichtenarchitektur wie aus dem Lehrbuch oder dem Microsoft Patterns Guide, um guten und wartbaren Code zu haben.

    Da steh ich bei dir, Struktur ja, alle Design Patterns mit 20 Schichten und bla bla wäre aber zu viel.

    Mechanics schrieb:

    Ich habe bisher selten oder ehrlich gesagt sogar noch nie wirklich funktionierende Unit Tests gesehen. Das ist nicht die Lösung aller Probleme. Es kann viel leichter dazu ausarten, dass man sagt, wir brauchen unbedingt Unit Tests und dann sehr viel Zeit reinsteckt, um Alibi Tests zu schreiben, die sehr viel trivialen Code abdecken und überhaupt nicht weiterhelfen. Da muss man auch schauen, ob man die wirklich sinnvoll integrieren kann und nicht einfach irgendwas machen, weil jemand sagt, dass es gut wäre.

    Da habe ich auch Angst vor. Andererseits, wenn man im Internet sucht, wird immer davon gesprochen, dass "Writing Tests is a skill" und dass das eben nicht jeder kann.

    Ich bedanke mich hier schonmal bei allen Antworten.

    Ich bin zwar noch ein junger Frischling, gebranntmarkt durch das universitäre Umfeld, aber im Grunde nur ein wohlwollender Idealist 😉



  • Peter Pan^^ schrieb:

    Dazu noch eine Frage: was genau ist eigentlich Continuous Integration?
    Ich hab es bisher so verstanden, dass es quasi einen CI-Server irgendwo gibt, der greift regelmäßig auf die Versionierung zu und zieht sich dann die aktuellen Stände, baut/kompiliert sie, eventuell werden Metriken berechnet, automatisierte Tests ausgeführt, und zum Schluss kommt hinten quasi ein theoretisch ausrollbarer Stand raus mit einigen Diagrammen oder Tabellen, wo drin steht, was wie wo die Probleme waren, welche Tests nicht funktionierten.
    Oder verstehe ich das komplett falsch?

    Continuos Integration hört sich erstmal sehr stark nach einem Buzz Word an, damit man Schulungen verkaufen kann 😉 Wir machen im Prinzip das, was du beschrieben hast. Wir bezeichnen das halt nicht als Continuos Integration, wir machen das einfach. Geht vielleicht sogar noch etwas weiter. Ist schon recht viel Aufwand, weil wir keine fertigen Server verwenden sondern im Endeffekt die ganze Infrastruktur selber aufgebaut haben. Da kümmern sich paar Leute drum, macht man nicht nebenbei.



  • Peter Pan^^ schrieb:

    -Wir haben vor wenigen Wochen einen neuen Kollegen bekommen, studierter Diplomwirtschaftsinformatiker, der als Vollzeit Entwickler eingestellt wurde.
    Als Laie (wie ich es im bin) würde ich erwarten, dass er programmieren kann(egal ob Java, C# oder ..., die Sprache ist ja eher nebensächlich). Aber sein Programmiererfahrung beschränkte sich auf das Zusammenklicken einer Web-Anwendung mit Visual Studio inklusive Datenbankanbindung usw. Auch hier wieder, bitte nicht falsch verstehen, er ist ein netter Kerl und menschlich auch total cool. Aber die (Java) Programmierung hat er jetzt fast komplett lernen müssen und sein Stil ist eben stark prozedural und repetetiv. Er macht halt viele Fehler, die man halt am Anfang macht.
    Ich glaube, wir haben eben nicht (nur) überdurchschnittlich gute Entwickler.

    Warum erwartest du, dass man nach dem Studium programmieren kann? Etliche meiner Kommilitonen konnten das nicht. Und ich hab an einer FH studiert, von der Uni kenne ich noch mehr Leute, die nicht programmieren können. Aber das kann man im Vorstellungsgespräch auch anders erkennen, dafür muss man die Bewerber nicht unbedingt was programmieren lassen. Und dann muss man entscheiden, ob er vielleicht andere Stärken hat und man die braucht. Man braucht ja nicht nur Programmierer. Wir versuchen aber nur Leute einzustellen, die billig sind, aber schon gut programmieren können. Wenn jemand sagt, dass er schon als Schüler viel programmiert hat, ist das wahrscheinlich eher ein Kandidat für uns, als jemand der sagt, dass er seine ersten Programmiererfahrungen im Studium gesammelt hat. Jedenfalls finde ich diesen Punkt als "Kriterium" für irgendwas viel zu pauschal.

    Peter Pan^^ schrieb:

    Da habe ich auch Angst vor. Andererseits, wenn man im Internet sucht, wird immer davon gesprochen, dass "Writing Tests is a skill" und dass das eben nicht jeder kann.

    Das kann schon gut sein. Aber ich denke, die meisten können das eben nicht und es ist generell schwierig. Ich habe vor Jahren so eine Art Kommunikationsframework für ein Projekt geschrieben. Natürlich mit Unit Tests. Es gab in den ganzen Jahren, in denen das im Einsatz ist keinen einzigen Fehler in der Kommunikationsschicht, und wir haben da nie was umgebaut. So gesehen waren die Unit Tests umsonst. Dafür gabs etliche konzeptionelle Probleme in den Workflows drüber. Die Probleme waren uns damals nicht bewusst, keine Chance, die von Anfang an durch Tests abzudecken. Und auch jetzt wüsste ich immer noch nicht, wie man das machen sollte. Viel zu komplex, viel zu viele verteilte Komponenten. Wenn man anfängt, da etwas zu mocken, sitzt man ewig dran und hat dann doch keinen realitätsnahen Test. Und den braucht man im Endeffekt auch nicht, weil wenn das Problem ausdiskutiert und gelöst ist, wirds so nicht mehr auftreten. Oder man kanns halt schnell manuell testen, dafür gibts Test Protokolle. Der Nutzen des Unit Tests würde in keinem Verhältnis zum Aufwand stehen.



  • Mechanics schrieb:

    Continuos Integration hört sich erstmal sehr stark nach einem Buzz Word an, damit man Schulungen verkaufen kann 😉 Wir machen im Prinzip das, was du beschrieben hast. Wir bezeichnen das halt nicht als Continuos Integration, wir machen das einfach. Geht vielleicht sogar noch etwas weiter. Ist schon recht viel Aufwand, weil wir keine fertigen Server verwenden sondern im Endeffekt die ganze Infrastruktur selber aufgebaut haben. Da kümmern sich paar Leute drum, macht man nicht nebenbei.

    Wenn man stattdessen nen Jenkins-Server nimmt, geht eigentlich recht einfach. Klar nen gewissen Aufsetz/Konfigurationsaufwand hat man am Anfang.



  • ich hab schon soviele studenten gesehen die ankommen und die ganze firma nach ihren wuenschen umgestalten wollen 🙂

    das problem ist dass du dich, weil es wohl dein erster job ist, sehr an die firma bindest. dabei sind die probleme und loesungen eigentlich nicht dein arbeitsbereich. du bist wohl zum programmieren da, nicht um dem cheffe die firmenleitung abzunehmen.
    dass die firma rund laeuft ist seine aufgabe, dass die bereiche gut laufen in denen er sich weniger gut auskennt sollte durch einstellung guter leads geloest werden.

    jeder firma hat probleme, du als junior bist aber nicht die person die das loesen sollte/kann (nicht nur aus kompetenz und erfahrungs gruenden, sondern auch aus sozialen).

    die loesungen sind also:
    1. du bist ein sneaky guy und fuehrst dinge heimlich auf eigene faust ein. das kann deine arbeitssituation vereinfachen, koennte aber auch viel reibung verursachen wenn andere anfangen dasselbe zu machen bzw. zu petzten was der junior alles macht, obwohl er coden sollte.
    2. du und deine kolegen setzen sich beim cheff durch dass er jemandem (zumindestens temporaer) einstellt der die situation in z.b. 6monaten loest. nein, keinen consultant, sondern jemand in der executive position. jemand der das recht hat zu befehlen "ab heute benutzt jeder xyz damit wir tasks tracken und einen burndown chart bekommen"
    3. du suchst dir einen job wo es dir besser gefaellt. es wundert mich bei deinem konkreten ideen und dann wohl auch faehigkeiten ueberhaupt dass du dort angefangen hast. das ist kein angriff gegen dich, aber wenn du eine ganze firma umgestalten wuerdest, wie kannst du dann persoenlich dich auf soeinen job ueberhaupt einlassen? (du kannst ja nichts falsches bestellen und es dann zum richtigen geschmack versuchen zu wuerzen und dich dann ueber das restaurent beschweren, wenn du dort essen koenntest wo nach deinem geschmack serviert wird).



  • Mechanics schrieb:

    Warum erwartest du, dass man nach dem Studium programmieren kann? Etliche meiner Kommilitonen konnten das nicht. Und ich hab an einer FH studiert, von der Uni kenne ich noch mehr Leute, die nicht programmieren können. Aber das kann man im Vorstellungsgespräch auch anders erkennen, dafür muss man die Bewerber nicht unbedingt was programmieren lassen. Und dann muss man entscheiden, ob er vielleicht andere Stärken hat und man die braucht. Man braucht ja nicht nur Programmierer.

    Nein, das erwarte ich nicht. Viele von uns Informatikstudenten gehen ja in ganz andere Richtung, eben nicht in die Software-Entwicklung.
    Aber die bewerben sich auch nicht als Vollzeit Java-Entwickler. Ich mein, man wird im Studium ja etwa in die Richtung gehen, in der man später auch mal arbeiten will.
    Und ja, es ist auch klar, dass nicht nur Entwickler gebraucht werden. Aber als Entwickler bewerben, als Nicht-Entwickler eingestellt werden, aber dann als Entwickler eingesetzt werden klingt arg unlogisch o_O

    rapso schrieb:

    ich hab schon soviele studenten gesehen die ankommen und die ganze firma nach ihren wuenschen umgestalten wollen 🙂

    Haha^^, das glaube ich gern 😃
    Ich bin übrigens nicht der einzige. Ich habe quasi die ganze junge Generation in der Firma auf meiner Seite.

    rapso schrieb:

    das problem ist dass du dich, weil es wohl dein erster job ist, sehr an die firma bindest. dabei sind die probleme und loesungen eigentlich nicht dein arbeitsbereich. du bist wohl zum programmieren da, nicht um dem cheffe die firmenleitung abzunehmen.

    Ja, erster Job in der Sparte ja, mag sein, dass ich da etwas hohe Erwartungen habe und erstmal auf den Boden der Tatsachen Realität zurückgeholt werden muss.

    Ja, laut Vertrag bin ich als Programmierer und Tester eingestellt. Aber, und das ist der eigentliche Grund warum ich da soviel drüber nachdenke und mich damit beschäftige, Chef kam vor einigen Wochen zu mir an und fragte nach, wie man/wir denn die Qualität unserer Software erhöhen könnte. D.h. eigentliche genau die Ziele von modernem Software Engineering einhält: gute und kurze Testbarkeit, hohe Erweiterbarkeit, hohe Wartbarkeit etc. die ganze Palette durch

    Persönlich bin ich davon betroffen worden, da ich gerne mal für vermeintliche "Schnellschüsse", also Dinge wo man mal eben ein Miniprogrämmchen schreibt innerhalb von 2-3 Stunden, herangezogen werde, die konzeptuelle Fehler von vor Jahren ausbügeln sollen. Und statt 2-3 Stunden soll das natürlich gestern fertig gewesen sein, aber Features enthalten und Usability umfassen, die wochenlange Studien vorraussetzen. Kurz um, ich schrieb ein Programm, was (oben genannte XML) Rechenvorschriften miteinander abgleicht ohne sie soweit abstrahieren zu können, damit dies wirklich möglich ist. Stattdessen greife ich auf Stringebene auf Suchen und contains mit ein paar Regex zurück, was letztlich sowohl false positive als auch false negative Fehler macht. Zack, aus dem Schnellschuss wurden 2 Tage, die letztlich nem anderen Kollegen nix bringen.

    Kann es sein, dass ich mir hier grad einfach nur was Kummer von der Seele schreiben will und nach etwas Bestätigung suche? O_o



  • Du kannst nicht eine bestehende Software, die über Jahre gewachsen ist, einfach umbauen. Wenn das Produkt z.B. 50 Mannjahre gebraucht hat, ist das etwas unrealistisch das umzubauen. Denn wer sagt denn, das der Umbau am Ende fehlerfrei oder zumindest nicht mehr Fehler hat, als das Original?

    Man könnte aber neue Module nach Lehrbuch entwickeln. Oder Alt-Code der angefasst wird (neue Features, Bugfix, Algorithmus-Änderung), gleich mit modernisieren. Aber vorher Unittest machen, dann Umbau!

    Aber einfach so Alt-Code umbauen, weils cooler ist? 😮



  • Kann es sein, dass ich mir hier grad einfach nur was Kummer von der Seele schreiben will und nach etwas Bestätigung suche? O_o

    ja, kann sein, kann alles Mögliche sein ... ich mein wenn alle "jungen" auf deiner Seite sind, diskutiert es doch gemeinsam aus, macht eine Übersicht
    * Ist-Zustand, alle Punkte
    * Vorschläge Soll-Zustand je Punkt
    * Herausstellen der messbaren/spürbaren Vorteile der Änderungen ganz wichtig
    * grobe zeitliche Planung/ca. Aufwand je Punkt als Orientierung

    dann alle zusammentrommeln und diskutieren, vlt. erstmal ohne Chef. Wichtig ist zu jedem Kritikpunkt einen Vorschlag mit Vor- und ggf. Nachteilen zu präsentieren.



  • Artchi schrieb:

    Du kannst nicht eine bestehende Software, die über Jahre gewachsen ist, einfach umbauen. Wenn das Produkt z.B. 50 Mannjahre gebraucht hat, ist das etwas unrealistisch das umzubauen. Denn wer sagt denn, das der Umbau am Ende fehlerfrei oder zumindest nicht mehr Fehler hat, als das Original?

    Man könnte aber neue Module nach Lehrbuch entwickeln. Oder Alt-Code der angefasst wird (neue Features, Bugfix, Algorithmus-Änderung), gleich mit modernisieren. Aber vorher Unittest machen, dann Umbau!

    Aber einfach so Alt-Code umbauen, weils cooler ist? 😮

    Natürlich nicht, wo denkst du hin o_O
    Rein theoretisch würd ichs gern sehen (weil cool :D), aber da könnten wir uns aus wirtschaftlicher Sicht gleich die Klippe runter stürzen.

    deejey schrieb:

    dann alle zusammentrommeln und diskutieren, vlt. erstmal ohne Chef. Wichtig ist zu jedem Kritikpunkt einen Vorschlag mit Vor- und ggf. Nachteilen zu präsentieren.

    Mh, ja das wäre eine Idee.
    Wobei ich weniger glaube, dass unser Chef das Problem darstellt, der ist zu lang aus der Entwicklung raus um das halbwegs sinnvoll bewerten zu können, eher gibt es die älteren Entwickler, die da mehr oder weniger stark gegen sind und das im Keim ersticken. Und das unter dem Vorwand der Wirtschaftlichkeit.



  • [...], eher gibt es die älteren Entwickler, die da mehr oder weniger stark gegen sind und das im Keim ersticken. Und das unter dem Vorwand der Wirtschaftlichkeit.

    Als ich angefangen habe, dachte ich auch, ich muss alles umreissen und verändern.
    Irgendwann legt sich das.

    Inzwischen nerven mich die ganzen Jungen, die frisch von der FH sind und meinen, sie wissen alles besser. Ihre Vorschläge sind ja ganz nett, aber mal eben ein riesiges Programm anpassen an irgendwelche Regeln ("was ihr wisst nicht was SOLID ist!?"), die die auf der FH gelernt haben, nein danke.
    Die Dinge funktionieren ja, klar gibts da und dort mal Fehler. Aber das sind meist Fehler in der Planung, da muss man dann alle an einen Tisch holen, drüber sprechen, und dann umbauen. Diese Fehler werden ja nicht durch einen Modultest, durch SOLID, durch Mocken oder was auch immer gefunden.

    Mich wundert ja auch, wieviel Bullshit heute gelehrt wird. Wir durften uns noch mit Graphen Algorithmen, Mathematik, Betriebssysteme und ähnlichem rumschlagen. Wird nun Bullshit Bingo auf Kosten "richtiger" Informatikthemen gelehrt?

    Nur meine Meinung ... damit du dich vielleicht mal in die Lage der "Alten" reindenken kannst.



  • Peter Pan^^ schrieb:

    Mh, ja das wäre eine Idee.
    Wobei ich weniger glaube, dass unser Chef das Problem darstellt, der ist zu lang aus der Entwicklung raus um das halbwegs sinnvoll bewerten zu können, eher gibt es die älteren Entwickler, die da mehr oder weniger stark gegen sind und das im Keim ersticken. Und das unter dem Vorwand der Wirtschaftlichkeit.

    Na dann lass es halt, was soll dann der Wirbel hier 😃



  • Artchi schrieb:

    Oder Alt-Code der angefasst wird (neue Features, Bugfix, Algorithmus-Änderung), gleich mit modernisieren. Aber vorher Unittest machen, dann Umbau!

    lol

    Vorher Unit-Tests machen, dann umbauen. Das ist ulkig.



  • Tyrdal schrieb:

    Wenn man stattdessen nen Jenkins-Server nimmt, geht eigentlich recht einfach. Klar nen gewissen Aufsetz/Konfigurationsaufwand hat man am Anfang.

    Ich weiß nicht genau, was die Kollegen da treiben (eigentlich interessiert mich das auch kaum). Ist über Jahre gewachsen. Ist schon klar, dass es da mehr oder weniger fertige Lösungen gibt. Aber die werden halt auch nicht alle Probleme automatisch lösen. Wir machen da schon viele ziemlich spezielle Sachen und auch die Testumgebungen aufzusetzten und zu verwalten ist viel Aufwand. Für automatische Tests haben wir auch schon alles mögliche ausprobiert, auch kommerzielle Lösungen, hat aber alles nicht so wirklich gepasst und funktioniert und wir haben am Ende dann doch einiges selber entwickelt.



  • hustbaer schrieb:

    Artchi schrieb:

    Oder Alt-Code der angefasst wird (neue Features, Bugfix, Algorithmus-Änderung), gleich mit modernisieren. Aber vorher Unittest machen, dann Umbau!

    lol

    Vorher Unit-Tests machen, dann umbauen. Das ist ulkig.

    Hä? Wieso?
    Genau darauf zielt doch z.B. Test-Driven-Development ab?!

    Ich mag solche Aussagen (die leider öfters hier im Forum von den alten Hasen kommen) nicht; die sind meistens positiv und negativ deutbar, haben dann aber keine Begründung.
    Ich sehe hier z.B. auf der einen Seite Ironie und auf der anderen Seite ein Lustigmachen über Unittests o_OAber keine Angst, hustbaer, volkard kann das auch gut


Log in to reply