Technisches Update für Firma

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.

Das ist zumindest die Erfahrung von Firmen, bei denen ich bis jetzt war.

Ich musste in meinem Studium ein Spiel mit strikter Schichtentrennung programmieren das mit Konsole, GUI und WUI (Web UI) lief.

und warum erzählt du nicht von relevanten Projekten die du in den Firmen gemacht hast - sondern kommst mit so einem Ein-Mann, Auf-der-grünen-Wiese, Mini-Projekt aus dem Studium?

hustbaer

Ähm schrieb:

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.

In der einen Firma die du meinst kann das durchaus so sein. Deine Aussage war aber absolut formuliert. Und absolut stimmt es eben nicht. Es gibt gute Gründe Dinge zu branchen/forken bzw. allgemein Code-Duplizierung zu machen. Überall wo es geht gemeinsamen Code zu verwenden "drückt" mächtig auf diesen gemeinsamen Code. Änderungen daran werden mächtig aufwändig und gefährlich. Da kann es schnell passieren dass durch eine Änderung die man für Projekt X oder Kunde Y macht 3 andere Projekte "brechen".

Ähm schrieb:

Ä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?

Klar.

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.

Mag sein. Genau so ulkig wie jemand der wegen etwas mosert was er selbst noch nicht versucht hat, ist aber jemand der meint etwas einschätzen zu können das er 1x in einem Mini-Projekt verwendet hat.
Ich sage nicht dass du nicht Recht hast. Ich sage nur: du kannst es nicht einschätzen.