Schreiben Arbeitgeber Stile und bestimmte Machweisen vor ?
-
/rant/ schrieb:
Dabei hat in manchen Projekten, welche nun in meiner Zuständigkeit liegen, die Menge an Quellcode um fast 80% abgenommen und meine Vorgesetzten verstehen zum Teil nicht mehr, wie und warum etwas jetzt noch funktionieren kann
scheinst ja ein overcoder zu sein, oder deine vorgesetzten sind etwas das sie nicht sein sollten :p
lg lolo
-
Z schrieb:
Projekte scheitern, wenn man erkennt, dass sie sich wirtschaftlich nicht mehr lohnen. Den Profi vom Amateur trennt IMHO, dass er erkennt, wann ein Projekt einzustellen ist und dies auch tut. Demzufolge kannst Du keine gescheiterten Projekte wiedererwecken. Du kannst höchstens das know-how der Projektleiche ausschlachten oder ein neues Projekt daraus definieren.
Eine Leiche ist tot, töter gibt es nicht. Der Gerichtsmediziner will auch nur herausfinden, was zum Tod geführt hat - und er weiss, dass in der Leiche nichts lebendes mehr zu finden ist. Das Ausschlachten einer Projektleiche kann nicht gehen. Denn die Fehler liegen selten in einer handvoll falscher if-Abfragen oder fehlerhafter Zuweisungen. Sondern eher in einem nicht sorgfältig durchdachtem Konzept. Die Wiedererweckung eines gescheiterten Projektes führt in vielen Fällen eben zur kompletten Neuentwicklung. Wie anders will man die falschen Denkansätze vermeiden?
Das waren meine bisherigen Aussagen, dass dies alles auch zum vorgebbaren Programmiertstil gehört. Ob da nun bei einer Detailaufgabe etwas weniger Code oder ein paar Millisekungen herauskitzelbar sind, ist nicht das Thema. Also nochmals JA - ein paar Firmenregeln dürfen sein und sind jederzeit sinnvoll!
Nichts ist schlimmer, als ein Projekt für gescheitert erkären zu müssen oder einem irgendwie hingepfriemelten Projekt mangels Stabilität oder Erweiterbarkeit später dann doch den Tod zu testieren.
-
berniebutt schrieb:
Eine Leiche ist tot, töter gibt es nicht. Der Gerichtsmediziner will auch nur herausfinden, was zum Tod geführt hat - und er weiss, dass es in der Leiche nichts lebendes mehr zu finden ist.
ach die organe von toten sind durchaus begehrtes gut, kommt natürlich auch immer ein bischen darauf an wielang der patient schon tot ist;)
berniebutt schrieb:
Die Wiedererweckung eines gescheiterten Projektes führt in vielen Fällen eben zur kompletten Neuentwicklung. Wie anders will man die falschen Denkansätze vermeiden?
meißt reicht doch ein umschreiben, da muß man doch nicht das ganze ding in die tonne kloppen, außer die substanz ist so schlecht das man da nichts mehr machen kann, solche fälle solls ja auch geben...
berniebutt schrieb:
Das war meine Aussage, dass dies alles zum vorgebbaren Programmiertstil gehört.
was du meinst ist eher die aufgabe eines software architekt und hat mit Programmiertstil wenig zu tun oder
lg lolo
-
noob_lolo schrieb:
/rant/ schrieb:
Dabei hat in manchen Projekten, welche nun in meiner Zuständigkeit liegen, die Menge an Quellcode um fast 80% abgenommen und meine Vorgesetzten verstehen zum Teil nicht mehr, wie und warum etwas jetzt noch funktionieren kann
scheinst ja ein overcoder zu sein, oder deine vorgesetzten sind etwas das sie nicht sein sollten :p
lg lolo
Nun, es sind halt Vorgesetzte, welche keine Zeit mehr dafür haben, jede Woche stundenlang im Quellcode diverser Projekte herumzukriechen und diesen zu refaktorisieren. Stattdessen widmen sie sich anderen Aufgaben (Pflegen von Kundenkontakten, Planung, Geschäftsleitung, etc.) und geben mir dafür die notwendige Zeit und Freiheit
MfG
-
berniebutt schrieb:
Z schrieb:
Projekte scheitern, wenn man erkennt, dass sie sich wirtschaftlich nicht mehr lohnen. Den Profi vom Amateur trennt IMHO, dass er erkennt, wann ein Projekt einzustellen ist und dies auch tut. Demzufolge kannst Du keine gescheiterten Projekte wiedererwecken. Du kannst höchstens das know-how der Projektleiche ausschlachten oder ein neues Projekt daraus definieren.
Eine Leiche ist tot, töter gibt es nicht. Der Gerichtsmediziner will auch nur herausfinden, was zum Tod geführt hat - und er weiss, dass in der Leiche nichts lebendes mehr zu finden ist. Das Ausschlachten einer Projektleiche kann nicht gehen. Denn die Fehler liegen selten in einer handvoll falscher if-Abfragen oder fehlerhafter Zuweisungen. Sondern eher in einem nicht sorgfältig durchdachtem Konzept. Die Wiedererweckung eines gescheiterten Projektes führt in vielen Fällen eben zur kompletten Neuentwicklung. Wie anders will man die falschen Denkansätze vermeiden?
Das waren meine bisherigen Aussagen, dass dies alles auch zum vorgebbaren Programmiertstil gehört. Ob da nun bei einer Detailaufgabe etwas weniger Code oder ein paar Millisekungen herauskitzelbar sind, ist nicht das Thema. Also nochmals JA - ein paar Firmenregeln dürfen sein und sind jederzeit sinnvoll!
Nichts ist schlimmer, als ein Projekt für gescheitert erkären zu müssen oder einem irgendwie hingepfriemelten Projekt mangels Stabilität oder Erweiterbarkeit später dann doch den Tod zu testieren.
(Vorweg: ich sage nicht, dass da jemals tot was war oder dass dort was falsch gemacht wurde !)
-> Ich sag nur Windows. Das baut doch schon von Anfang an wie Lego aufeinander auf. Hier und da wird ein blaues Steinchen durch ein Gelbes ersetzt, aber 90 % von Windows 7 sind Vista, von Vista sind wiederum 80 % XP usw.
--> Bei Vista wars dann auch zu sehen: Anforderungen um 100 % gewachsen (
).
-
noob_lolo schrieb:
berniebutt schrieb:
Das war meine Aussage, dass dies alles zum vorgebbaren Programmiertstil gehört.
was du meinst ist eher die aufgabe eines software architekt und hat mit Programmiertstil wenig zu tun oder
lg loloDer Begriff Architekt ist anders belegt. Ich würde ihn nie auf Software-Projekte übertragen. Bleiben wir aber bei diesem Begriff aus dem Hausbau. Wenn die Konstruktion eines Gebäudes nicht stimmt, ist das fertige Haus nicht oder nur eingeschränkt nutzbar. Die Analogie zu Software-Projekten ist durchaus ähnlich. Entwurf und Programmierstil gehen da leicht ineinander über. Egal, ob ein Software-Projekt im eigenen Haus verwendet, verkauft, oder im Kundenauftrag erstellt werden soll, es geht immer um dasselbe. Die Entwicklung muss wirtschaftlich, stabil, und auf längere Zeit mit geringem Aufwand wartbar sein. Jeder vernünftige Firmenchef darf und muss da Vorgaben machen dürfen, wenn er morgen nicht selbst vom Fenster weg sein möchte.
-
berniebutt schrieb:
Der Begriff Architekt ist anders belegt. Ich würde ihn nie auf Software-Projekte übertragen. Bleiben wir aber bei diesem Begriff aus dem Hausbau. Wenn die Konstruktion eines Gebäudes nicht stimmt, ist das fertige Haus nicht oder nur eingeschränkt nutzbar.
ja also ich hab den auch nur aufgegriffen, man könnts doch eher mit nem fertig haus vergleichen, das besteht ja auch aus modulen
und da sind wir schon da wo es einen unterschied macht, wenn natürlich die module verschmelzen ist das alles müll. aber das hat mit stil nichts zu tun...
modul schnittstellen -> entwurf (architekt, oder was auch immer)
konkrete modul implementation -> stillg lolo
-
/rant/ schrieb:
die eleganten Lösungen sind nicht immer die einfachsten
Häufig sind die einfachen Lösungen allerdings die elegantesten, da wartbarsten.
-
noob_lolo / thordk / ...
Dann sind wir uns doch im wesentlichen einig und der Fragesteller hat brauchbare Antworten bekommen!Programmieren für einen Arbeitgeber - also für Geld - ist weit mehr als das Aneinanderreihen von Programmbefehlen. Das Ziel ist ein wirtschaftlich erstelltes, stabiles, und wartbares Programm. Das nenne ich den erzielbaren Nutzen aus einer investierten Arbeit. Aus der Sicht eines Arbeitgebers sollte dieser erzielbare Nutzen möglichst gross sein. Wie kann man das erreichen? Ich meine, durch klare und sinnvolle Vorgaben für Programmierstile und Machweisen.
Wie man so etwas nun nennen will, ist zweitrangig. Das Stichwort Module war genannt, ich ergänze noch den Begriff Blöcke. Es kommt also darauf an, eine komplexe Gesamtaufgabe in überschaubaren Teilaufgaben zu lösen. Innerhalb solcher Teilaufgaben kann man einem damit beauftragten Programmierer seine individuellen Freiheiten lassen. Ein gutes Gesamtkonzept bedeutet die Unabhängigkeit der Module untereinander. Man muss sie einzeln jederzeit verbessern oder austauschen können.
Das Thema ist so alt wie die Programmierung und bleibt aktuell.
-
berniebutt schrieb:
Wie kann man das erreichen? Ich meine, durch klare und sinnvolle Vorgaben für Programmierstile und Machweisen.
Wobei man hier sagen muss das Vorgaben meist antiproportional zur Unternehmensgröße sind. Und in kleinen Firmen auch mal ein Stil durchgeboxt werden kann (z.B. habe ich in unseren Projekt nach und nach den vorhandenen Stil umändern können, aber ich bin auch inzwischen für 90% der Entwicklung verantwortlich).
-
thordk schrieb:
/rant/ schrieb:
die eleganten Lösungen sind nicht immer die einfachsten
Häufig sind die einfachen Lösungen allerdings die elegantesten, da wartbarsten.
Nicht wenn es um Haufenweise Copy/Paste Code geht
