Technisches Update für Firma

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.