Schreiben Arbeitgeber Stile und bestimmte Machweisen vor ?
-
Hi Baba Yaga,
Wenn mir jemand sagt, er wäre "Head-Developer", dann würde ich ihn als mittelmässigen Friseur einstufen. "Senior-Developer" ist vermutlich einer, der sich um ältere Mitbürger kümmert, während ich meine Aufgabe als "Junior-Developer" darin sehen würde, möglichst viele Nachkommen zu zeugen.
besser kann man es einfach nicht auf den Punkt bringen.
Ich weise die Leute in den Backshops und Backfaktorys auch liebend gerne darauf hin, daß sie in einem Arschladen oder einer Arschfabrik arbeiten.Und bei Kaffee ToGo möchte ich auch nichts kaufen, was sollte ich schließlich mit einem Kaffe der zum weglaufen ist.
Gruß Mümmel
-
muemmel schrieb:
Und bei Kaffee ToGo möchte ich auch nichts kaufen, was sollte ich schließlich mit einem Kaffe der zum weglaufen ist.
Und ich dachte immer, "Kaffee Togo" ist ein besonders hochwertiger Exklusivimport aus Westafrika.
Baba Jaga: LOL
-
Egal wie gross oder klein eine Softwarefirma ist, auch Richtlinien zum Stil der Programmierung sind notwendig und sinnvoll. Ein hauseigener Stil muss sein, damit jeder andere in der Firma auch den Code pflegen kann und nicht jeder dasselbe anders macht. Du bist im Urlaub, krank, oder hast die Firma verlassen. Soll deine Arbeit dann liegen bleiben oder weggeschmissen werden? Der Kunde wartet und will eine neue Lösung oder ein Fehler muss schnell gefunden werden. Dem Kunden ist es meist egal, wer da angefangen hat mit der Programmierung.
-
Na, aber ein bißchen überbewertet wird der einheitliche Stil jetzt schon. Bei manchen fremden Projekten kommt man nicht rein. Das liegt meistens gar nicht am fremden Stil, sondern an der fremden Logik, nämlich daran, daß der Architekt nicht programmieren konnte.
-
Manchmal bekommt man als Vorgabe ein "Code Checker" Tool, das bei jeder Kleinigkeit im Code eine Warnung ausspuckt - und da kann man nichts anderes als einen besonderen Stil anzueignen, ob der gut ist oder nicht, sei dahingestellt...
-
volkard schrieb:
Na, aber ein bißchen überbewertet wird der einheitliche Stil jetzt schon. Bei manchen fremden Projekten kommt man nicht rein. Das liegt meistens gar nicht am fremden Stil, sondern an der fremden Logik, nämlich daran, daß der Architekt nicht programmieren konnte.
Ja klar, die Strukturierung eines Programmentwurfes gehört ebenso zum Stil. Auch da kann und darf der Chef klare Vorgaben machen. Bei fremden Projekten fehlt oft einiges im Stil. Dann ist leider manchmal eine Neuprogrammierung unumgänglich. Dies zu vermeiden, ist der Sinn von Stilvorgaben!
-
berniebutt schrieb:
volkard schrieb:
Na, aber ein bißchen überbewertet wird der einheitliche Stil jetzt schon. Bei manchen fremden Projekten kommt man nicht rein. Das liegt meistens gar nicht am fremden Stil, sondern an der fremden Logik, nämlich daran, daß der Architekt nicht programmieren konnte.
Ja klar, die Strukturierung eines Programmentwurfes gehört ebenso zum Stil. Auch da kann und darf der Chef klare Vorgaben machen. Bei fremden Projekten fehlt oft einiges im Stil. Dann ist leider manchmal eine Neuprogrammierung unumgänglich. Dies zu vermeiden, ist der Sinn von Stilvorgaben!
Du hast gar nicht verstanden, was ich schrieb. Aber wenn für Dich Stilvorgaben ein Allheilmittel sind, bin ich ja beruhigt. Euch wird niemals ein Projekt umfallen, weil Ihr einen einheitlichen Stil pflegt. Ich kenne es nur andersrum, daß der Rekursion verbietet und sich dann wundert, daß das Sortieren so langsam ist.
-
volkard schrieb:
Du hast gar nicht verstanden, was ich schrieb. Aber wenn für Dich Stilvorgaben ein Allheilmittel sind, bin ich ja beruhigt. Euch wird niemals ein Projekt umfallen, weil Ihr einen einheitlichen Stil pflegt. Ich kenne es nur andersrum, daß der Rekursion verbietet und sich dann wundert, daß das Sortieren so langsam ist.
Es kann schon sein, dass ich nicht alles verstanden habe, was du erklärt hast. Ein Projekt, das irgendwann umfällt, ist einfach schlecht konzipiert. Ich selbst bin schon in viele gescheiterte Projekte eingestiegen und habe die dann ans Laufen gebracht. Ich meine, ich weiss wovon ich rede. Dein Beispiel mit dem Sortieren ist schwach. Wer immer eine bessere schnellere Lösung für was auch immer hat, kann diese doch einbinden und als Firmenwissen bereitstellen. Der Arbeitgeber wird es dir danken und rückt vielleicht mehr Gehalt heraus!
daddeldu
-
1. Seit wann gibt es ein Beruf und Ausbildungsforum
2. Sehr interessant, so hatte ich mir das irgwo auch gedacht.
Viel interessantes zu lesen.
-
berniebutt schrieb:
Ein Projekt, das irgendwann umfällt, ist einfach schlecht konzipiert. Ich selbst bin schon in viele gescheiterte Projekte eingestiegen und habe die dann ans Laufen gebracht.
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.
-
Ich bin noch relativ neu im Geschäft (ein wenig mehr als 4 Monate) und darf trotzdem bereits jetzt meinen eigenen Stil komplett durchsetzen. Wir sind eine kleine Firma und ich muss relativ viel alten Code reorganisieren oder sogar neu schreiben, weil dieser nicht wirklich durchdacht ist (Spaghetti-Code, Copy & Paste, ...). 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 (die eleganten Lösungen sind nicht immer die einfachsten ;)). Zufrieden sind wir trotzdem alle
MfG
-
/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.
