Technisches Update für Firma

rapso

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

Artchi

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?

deejey

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.

deejey

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

hustbaer

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.

Mechanics

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

Th69

hustbaer schrieb:

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

Wie sonst? Willst du erst den Code umbauen, um dann später die Fehler zu suchen, weil der neue Code sich dann doch anders verhält als das Original?

Es kann (und wird wahrscheinlich) auch so sein, daß der Originalcode gar nicht Unit-Test-fähig ist - meintest du das?

rapso

Peter Pan^^ schrieb:

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

entweder fragt er da den falschen, oder es betrifft deinen arbeitsbereich. gehen wir mal vom zweiten aus (und nicht dass es ein schlechter cheffe ist):
das heisst, er moechte nicht wissen, dass die coder 3% mehr zeilen schreiben wenn in der kueche eine premium-kaffee marke verwurschtelt wird.
Eher dass du fuer deinen bereich feedback gibst.

Filtern wir also dich betreffende dinge (korrigier ruhig falls ich in deienn 2 beitraegen das nicht richtig einschaetzen gelernt habe ).

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

ueberleg dir konkret wie diese deinen arbeitsbereich betreffenden punkte effektiv verbessert werden koennen. dabei musst du davon ausgehen, dass sowas zu sagen "x y z mueste besser werden und a b c sollte auch jemand umsetzen" wird er zustimmend abnicken und es passiert nichts. dein ziel ist also dinge zu finden fuer die du ownership uebernehmen kannst und dich danach dafuer auch voll reinhaengst.

wenn du diese kleinen stufen schaffst, dann hast du reputation um dinge anzugehen die weniger mit dir direkt zu tun haben.

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.

welche loesung wuerdest du besser finden die unmittelbar umgesetztbar ist? moechtest du ein modul erstellen auf das beide seiten aufsetzen und somit abgleich nicht noetig sind bzw durch deine definitionen der interfaces keine false positives entstehen?
wenn du wuestest wie und das koentest hast du den handschlag deines cheffes sicher die situation zu verbessern. erzaehl ihm aber nicht wie schlimm es ist, sag ihm was der sachliche status ist und wenn du es aendern duerftest wuerde es x y z fuer immer besser machen fuer die firma. (cheffes haben echt viele probleme, sie bitten dich also nicht feedback um noch mehr probleme zu erfahren, sondern vom gegenteil, dinge die du besser machst als sie sind).

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

kann sein, sowas kann sehr einfach in einer schlechten einstellung oder schlechtem verhalten enden, weil man sich da reinsteigert. In schlechten faellen entsteht antipathie gegen mitarbeiter und ohne dass du es merkst macht es dich zu einen "bad apple".
Du hast recht, die ganze welt ist schlecht, das ist tatsache. du kannst das nicht aendern, kaum als lead, als junior schon garnicht (du siehst nur die limitierungen schlechter). aber das sollte dich nicht irgendwann zu einem depressiven 40+jaehrigen machen der immer noch in der selben firma ist und nur status quo maintained und motzt

Such dir eine challenge die du bewaeltigen kannst und die was bringt und dann mach daraus dein "happy place". dann zur naechsten challenge. Am ende siehst du es macht nichts wenn die ganze firma schlecht ist (oder software), wenn alle pro-aktiv dran arbeiten dinge besser zu machen. eigentlich ist das viel spassiger als in einer perfekten firma anzufangen, 9-5 in den sessel zu pupsen und einer von 100 code monkeys zu sein die die schon perfekte welt nicht verbessern koennen

Tyrdal

einalter schrieb:

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

Klar lässt der Drang alles aus Selbstzweck umändern zu wollen irgendwann nach, wenn aber alles immer als gegeben hingenommen wird ist das genauso falsch. Natürlich muss man von Zeit zu Zeit überlegen ob das was man tut auch auf bessere Weise getan werden kann. Und wenn ich da was bemerke sage ich das auch wenn ich kein Neuling mehr bin.

ein wie ich finde interessanter artikel der sich i.wie auch auf das thema bezieht:
http://www.heise.de/developer/artikel/Die-Geschichte-vom-guten-Computerprogramm-Teil-1-2505363.html

ich finde oberstes kriterium sollte wenn man etwas entwickelt immer funktionalität sein...
dh. es ist erstmal unwichtig wieso es funktioniert, was schöner sein könnte/sollte/müsste, denn funktionieren sollte es ÍMMER!

wenn du das programm zum zwecke der wartbarkeit umbaust und dafür 1 jahr brauchst, die wartung aber eher selten erfolgt bzw. dort überhaupt keine wartungen, erweitungerungen erfolgen sollen ist dies sinnlos und unwirtschatflich....

ganz zu schweigen das du dann überhaupt die vorhanden funktionalität erreichen solltest weil ein sauberes/wartbares programm das nicht tut was es soll bringt nix, dann müssen für die überarbietet version auch erstmal tests
gemacht werden etc ...

du darfst auch nicht vergessen unternehmen müssen wirtschaftlich handeln...
(den kunden interessiert es nicht wie der code aussieht... zumindest im normalfall... -> damit will ich aber nicht sagen das man sich nicht an codingguidelines oder vorschriften halten kann/sollte...)

nur ich bin der meinung dies sollte immer in einem wirtschaftlichen rahmen geschehen... damit ein gutes preis-leistungs verhältnis entsteht...

ich denke zu dem auch das sich dein chef darüber gedanken machen wird, da es letztenendlich er ist, der dich bezahlt ...

ich finde auch du solltest erstmal bei dir anfangen... also ändere die dinge die dich stören und deine arbeit deiner meinung nach erleichtern und schneller machen... (wenn das gut läuft werden meiner erfahrung nach die anderen schon schauen und ggf. auch dinge von dir übernehmen... da ja sonst auch vor dem chef auffällt das sie schludern... )

ist aber nur meine meinung dazu

Ich glaube, ich hatte das oben irgendwo mal erwähnt (hoffe ich^^), ich bin noch Student und arbeite daher nur nebenbei in der Firma ~16h/Woche.
Das heißt im umgekehrt, ich habe zwar meine Projekte, aber die sind im Verhältnis ziemlich klein und weitestgehend ohne fachlichen Zusammenhang. Das wichtigste meiner Projekte ist sogar komplett abgekapselt, da es ein Wrapper um eine externe native Bibliothek ist. Besteht aus zwar aus einigen kleinen Projekten (damit meine ich Visual Studio Solutions bzw. Eclipse Java Projekte) von einigen 1000 Zeilen, aber nix riesiges. Die Kollegen sehen nur die feine saubere Schnittstelle, müssen irgendwo mal sowas wie ein Init Aufrufen und können dann rum-usern wie sie wollen.
Und ich hab da eine Reihe von Unit-Tests, die sich auch immer dann lohnen, wenn ein Update eben dieser externen Bibliothek reinkommt, und auch ein halbwegs sauberes Design (ja, der schlechteste Code den ich in der Firma gesehen habe ist immer noch meiner!).

Was ich damit sagen will: an meinem Projekt sind Dinge, die ich gerne ändern bzw. einführen würde, soweit umgesetzt, aber es sieht keiner, damit interessierts keinen und folglich kommt keiner auf die Idee mir zu folgen.
Umgekehrt, habe ich als Student (zu Recht!) natürlich nur weniger die Chance, dass mir ein größeres zentraleres Projekt übertragen wird, damit sich Kollegen mal das ein oder andere abschauen können.

deejey

tja, also dann weiß ich auch nicht ...

hustbaer

Th69 schrieb:

hustbaer schrieb:

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

Wie sonst? Willst du erst den Code umbauen, um dann später die Fehler zu suchen, weil der neue Code sich dann doch anders verhält als das Original?

Nein, wollen nicht.

Th69 schrieb:

Es kann (und wird wahrscheinlich) auch so sein, daß der Originalcode gar nicht Unit-Test-fähig ist - meintest du das?

Genau das.

Was sind das hier zum Teil für Loser-Antworten? Eine Firma kann ganz schön viel offensichtlichen Mist treiben. Die Firma, in der ich momentan als Werkstudent tätig bin hat lange Zeit für jeden Kunden Code aus anderen Repositories dupliziert und ein eigenes Repository dafür angelegt. Das Ergebnis: Jede Menge Code der von allen Projekten geteilt wird, aber eben doch kleine, feine Unterschiede. Manche Repos haben spezielle Features, andere wiederum Bug-Fixes die andere nicht haben. So langsam sieht man ein, dass das kompletter Murks war.
Die Windows-Abteilung nutzt noch Visual Studio 2005. Wir Linuxer dürfen deswegen kein C++11 verwenden. O.o Ich könnte noch einige solcher offensichtlich dummen Beispiele liefern und letztendlich haben solche Verhaltensweisen keine guten, rational vertretbaren Gründe, sondern es ist einfach Murks – Punkt!

Und zum Thema Schichten-Trennung: Das geht sehr gut! Ich musste in meinem Studium ein Spiel mit strikter Schichtentrennung programmieren das mit Konsole, GUI und WUI (Web UI) lief. Mit Schichtungtrennung kein Problem! Ohne Schichtentrennung hat man eben jede Menge duplizierten Code und man kann nicht mal eben so auf ein andere GUI-Framework wechseln!

"Hat man immer schon so gemacht" ist kein Argument dafür, dass man Dinge so fortsetzen muss. Es ist traurig, dass Dinge, die ich im Studium gelernt und eben auch praktisch(!) umgesetzt habe, erst viele Jahre später zum Thema werden!

hustbaer

Ähm schrieb:

Ich könnte noch einige solcher offensichtlich dummen Beispiele liefern und letztendlich haben solche Verhaltensweisen keine guten, rational vertretbaren Gründe, sondern es ist einfach Murks – Punkt!

Naja, man will immer glauben dass das so ist. Leider machst du es dir da auch etwas zu einfach. Es gibt für sehr vieles rational vertretbare Gründe.

Ähm schrieb:

Und zum Thema Schichten-Trennung: Das geht sehr gut! Ich musste in meinem Studium ein Spiel mit strikter Schichtentrennung programmieren das mit Konsole, GUI und WUI (Web UI) lief. Mit Schichtungtrennung kein Problem! Ohne Schichtentrennung hat man eben jede Menge duplizierten Code und man kann nicht mal eben so auf ein andere GUI-Framework wechseln!

Klar ist Schichtentrennung suba.
Finde es bloss witzig dass du die 2 1/2 Zeilen Code die du im Studuim geschrieben hast als aussagekräftig einstufst.

hustbaer schrieb:

Ähm schrieb:

Ich könnte noch einige solcher offensichtlich dummen Beispiele liefern und letztendlich haben solche Verhaltensweisen keine guten, rational vertretbaren Gründe, sondern es ist einfach Murks – Punkt!

Naja, man will immer glauben dass das so ist. Leider machst du es dir da auch etwas zu einfach. Es gibt für sehr vieles rational vertretbare Gründe.

Gibt es nicht. Das sind genau die Baustellen, die man sich seit Jahren vornimmt anzugehen und alle paar Jahre setzt man etwas Kleines davon um.

Ähm schrieb:

Und zum Thema Schichten-Trennung: Das geht sehr gut! Ich musste in meinem Studium ein Spiel mit strikter Schichtentrennung programmieren das mit Konsole, GUI und WUI (Web UI) lief. Mit Schichtungtrennung kein Problem! Ohne Schichtentrennung hat man eben jede Menge duplizierten Code und man kann nicht mal eben so auf ein andere GUI-Framework wechseln!

Klar ist Schichtentrennung suba.
Finde es bloss witzig dass du die 2 1/2 Zeilen Code die du im Studuim geschrieben hast als aussagekräftig einstufst.

Umgekehrt wird ein Schuh draus: Hast du es jemals ernsthaft versucht? Die meisten hier mosern, ohne jemals einen ernsthaften Versuch gestartet zu haben. Das ist zumindest die Erfahrung von Firmen, bei denen ich bis jetzt war.