C/C++ Forum :: Schreiben Arbeitgeber Stile und bestimmte Machweisen vor ?

Tim06TR Mitglied 23:23:33 09.03.2010 Titel:

Wie sehr wird man vom Arbeitgeber eingeschränkt ? Abweichung sind natürlich logisch. Sprechen die einem im Stil dazwischen ? in jeder kleinigkeit ?
Schreiben sie bestimmte header und libs vor ? (klar wenns auf linux laufen soll nichts was windows spezifisch ist). [...]

Employed people first

.

Das würde mich interessieren.

drakon Mitglied 23:39:41 09.03.2010 Titel:

Diese Frage kann man nicht allgmein beantworten. Hängt vom Arbeitgeber, wie viel Erfahrung/Freiheiten, Team usw. ab.

Aber grundsätzlich würde ich sagen ja. Meist wird man sich an gewisse Eigenheiten vom Firmencode anpassen müssen, aber wie stark ist sehr abhängig.

evilissimo Chefkoch 01:41:46 10.03.2010 Titel:

Normalerweise gibt es in größeren Firmen immer Richtlinien, weil sonst versteht am Ende keiner den Code vom anderen mehr.
Oder jeder verwendet seine eigenen bzw andere Libraries und dann wird die Integration/Zusammenführen von code eventuell schwierig etc.

Grade bei großen Projekten ist das sehr wichtig.

hustbaer Mitglied 01:52:07 10.03.2010 Titel:

Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben.
Da musst du davon ausgehen dass dir fast alles vorgeschrieben wird.
* Was genau du programmieren sollte
* Mit welcher Sprache
* Auf welchem Target-OS
* Die Style-Guidelines (Benennung, Formatierung, ...)
* Mit welchen Tools (IDE, Plugins, Debugging-Tools)
* Mit welche Libraries/APIs du zu arbeiten hast
* Um wieviel Uhr du deinen Kaffee trinken gehst

etc.

Wenn du dagegen Senior-Developer oder gar Lead-Developer bist, bist du derjenige der einige dieser Dinge vorschreibt.

Natürlich bist du auch da noch eingerschränkt, denn es wir dir wohl kein Chef durchgehen lassen, wenn du einfach mal so ohne Grund das OS wechselst, die Toolchain, alle verwendeten Libraries, die Stype-Guides umstellst etc.
Ganz einfach weil es kontraproduktiv wäre.

Sogesehen hat man weniger "absolute" Vorgaben, dafür etliche Dinge, wo es einfach nicht praktikabel wäre, etwas anders zu machen als bisher.

Natürlich kommt es wie drakon schon geschrieben hat sehr auf die Firma drauf an. Allgemein würde ich sagen: je kleiner die Firma, desto mehr Freiheiten bzw. umgekehrt je grösser desto mehr Vorgaben.

Bashar Mitglied 02:01:56 10.03.2010 Titel:

hustbaer schrieb:

Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,

Ist das üblich, dass es solche Ränge gibt?

Unregistrierter

Bashar schrieb:

hustbaer schrieb:

Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,

Ist das üblich, dass es solche Ränge gibt?

You've been living in a dream world, Bashar.

evilissimo Chefkoch 07:29:14 10.03.2010 Titel:

Bashar schrieb:

hustbaer schrieb:

Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,

Ist das üblich, dass es solche Ränge gibt?

Also bei uns gibt es mitlerweile ca 100 Developer und wir haben Junior Developer, Developer, Senior Developer und die Team Leader (welche auch teilweise noch entwickeln aber nicht soo viel Zeit dafür haben) und wir haben einen Principal Developer.

Ich denke das dies ganz einfach davon abhängt wie groß die Firma ist und ob die den Corporate weg gehen oder nicht.

C++ Forumbot Forumbot 08:43:51 10.03.2010 Titel:

Dieser Thread wurde von Moderator/in pumuckl aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Baba Yaga Mitglied 09:05:57 10.03.2010 Titel:

Bashar schrieb:

hustbaer schrieb:

Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,

Ist das üblich, dass es solche Ränge gibt?

In sogenannten "Spieleschmieden" betiteln sie sich häufig so, um sich wichtig zu tun. Meistens hat noch nicht einmal der Herr "Lead-Developer" eine formale Ausbildung genossen. Dementsprechend schlecht ist auch die Bezahlung.
NS: In Stellenangeboten seriöser Firmen wirst Du solche Bezeichnungen nicht finden.

_matze Mitglied 09:40:36 10.03.2010 Titel:

Wir sind nur ein kleiner Laden, und da gibt es keine Senior-, Lead- und sonstige Programmierer. Nur den SW-Chef und den kümmerlichen Rest...

Aber selbst bei uns gibt es ein paar Vorschriften zur Programmierung.

Jockelx Mitglied 09:53:36 10.03.2010 Titel:

Zitat:

Wie sehr wird man vom Arbeitgeber eingeschränkt ?

Das hört sich aber sehr negativ an.
Natürlich ist das manchmal nervig Gewohnheiten zu ändern, aber:
Wenn jeder seinen eigenen Stil einbringen würde, wäre das im Endeffekt alles viel nerviger.

byto Mitglied 09:57:02 10.03.2010 Titel:

Zumindest die grundlegenden Prozesse für die Entwicklung sollten schon klar definiert sein. Ist das nicht der Fall, würde ich mir ernsthaft Gedanken machen, ob das der richtige Arbeitsplatz für mich ist.

Ob es darüber hinaus Vorschriften gibt, was Tools, Libs und Styleguides angeht, ist individuell verschieden. Wenn nur geile Typen im Projekt arbeiten, kommt man mit wenig Richtlinien aus. Je mehr einfache Codemonkeys dabei sind, um so wichtiger sind klar einzuhaltende Regeln.

Ich halte grundsätzlich wenig von zu vielen Vorschriften. Sowas gaukelt meistens nur eine falsche Sicherheit vor. Nicht selten leidet eher die Qualität darunter, weil Entwickler in ihren Werkzeugen beschnitten werden. Obwohl Tool XYZ für diesen Fall am besten wäre, darf man es nicht benutzen, weil der Herr Chef Architekt es nicht abgesegnet hat. Das ist dann selten wenig verwunderlich, kennt der Herr Chef Architekt das Tool ja nicht mal, weil er die letzten Jahre gar nicht mehr selbst entwickelt hat und somit technisch längst abgehängt wurde. :o)

Wichtiger sind imo regelmäßige Code Reviews. Daran hapert es aber häufig.

Unregistrierter

Baba Yaga schrieb:

Bashar schrieb:

hustbaer schrieb:

Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,

Ist das üblich, dass es solche Ränge gibt?

In sogenannten "Spieleschmieden" betiteln sie sich häufig so, um sich wichtig zu tun. Meistens hat noch nicht einmal der Herr "Lead-Developer" eine formale Ausbildung genossen. Dementsprechend schlecht ist auch die Bezahlung.
NS: In Stellenangeboten seriöser Firmen wirst Du solche Bezeichnungen nicht finden.

Doch, gerade dort, eher nicht in kleinen Firmen und "Spieleschmieden", die ich jetzt einfach mal dazuzähle, ganz einfach weil es dort viel größere Abteilungen & Teams gibt.

Z Mitglied 21:15:20 10.03.2010 Titel:

lol du opfer schrieb:

Baba Yaga schrieb:

Bashar schrieb:

hustbaer schrieb:

Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,

Ist das üblich, dass es solche Ränge gibt?

In sogenannten "Spieleschmieden" betiteln sie sich häufig so, um sich wichtig zu tun. Meistens hat noch nicht einmal der Herr "Lead-Developer" eine formale Ausbildung genossen. Dementsprechend schlecht ist auch die Bezahlung.
NS: In Stellenangeboten seriöser Firmen wirst Du solche Bezeichnungen nicht finden.

Doch, gerade dort, eher nicht in kleinen Firmen und "Spieleschmieden", die ich jetzt einfach mal dazuzähle, ganz einfach weil es dort viel größere Abteilungen & Teams gibt.

Das ist ein Überbleibsel der DotCom-Blase. Seitdem nennt sich jeder Kioskbesitzer CEO und jeder Hausmeister Facility Manager.

C++ Forumbot Forumbot 23:59:39 10.03.2010 Titel:

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Beruf und Ausbildung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

branleb Mitglied 01:06:38 11.03.2010 Titel:

Wir sind auch relativ klein, aber bei uns gibts es auch Head Developer, Senior Developer und Junior Developer...

Wobei bei uns das afaik hauptsächlich Arbeitsvertragsgrade sind, die die Bezahlung und so beeineinflussen. Was wer zu sagen hat, bestimmt das können. Zumindest grob. Wir sind aber echt klein.

Branleb

noob_lolo Mitglied 09:56:16 11.03.2010 Titel:

Z schrieb:

lol du opfer schrieb:

Baba Yaga schrieb:

Bashar schrieb:

hustbaer schrieb:

Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,

Ist das üblich, dass es solche Ränge gibt?

In sogenannten "Spieleschmieden" betiteln sie sich häufig so, um sich wichtig zu tun. Meistens hat noch nicht einmal der Herr "Lead-Developer" eine formale Ausbildung genossen. Dementsprechend schlecht ist auch die Bezahlung.
NS: In Stellenangeboten seriöser Firmen wirst Du solche Bezeichnungen nicht finden.

Doch, gerade dort, eher nicht in kleinen Firmen und "Spieleschmieden", die ich jetzt einfach mal dazuzähle, ganz einfach weil es dort viel größere Abteilungen & Teams gibt.

Das ist ein Überbleibsel der DotCom-Blase. Seitdem nennt sich jeder Kioskbesitzer CEO und jeder Hausmeister Facility Manager.

solang es das pipi größer macht ists doch super

oder hast du, wie ich probleme zu verstehen was du dann effektiv machen mußt :o)

Baba Yaga Mitglied 13:13:50 11.03.2010 Titel:

noob_lolo schrieb:

oder hast du, wie ich probleme zu verstehen was du dann effektiv machen mußt :o)

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.

muemmel Mitglied 18:03:49 11.03.2010 Titel:

Hi Baba Yaga,

Zitat:

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

Z Mitglied 23:46:35 11.03.2010 Titel:

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 :live:

berniebutt Mitglied 14:04:17 13.03.2010 Titel:

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.

volkard Moderator 15:20:05 13.03.2010 Titel:

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.

abc.w Mitglied 23:09:30 13.03.2010 Titel:

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...

berniebutt Mitglied 14:28:22 14.03.2010 Titel:

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!

volkard Moderator 14:43:49 14.03.2010 Titel:

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.

berniebutt Mitglied 12:29:30 15.03.2010 Titel:

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 :leak:

Tim06TR Mitglied 18:40:04 19.03.2010 Titel:

1. Seit wann gibt es ein Beruf und Ausbildungsforum

2. Sehr interessant, so hatte ich mir das irgwo auch gedacht.
Viel interessantes zu lesen.

Z Mitglied 22:13:14 19.03.2010 Titel:

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.

/rant/ Mitglied 15:39:39 20.03.2010 Titel:

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 :leak:

MfG

noob_lolo Mitglied 12:05:50 21.03.2010 Titel:

/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

lg lolo

berniebutt Mitglied 13:00:19 21.03.2010 Titel:

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.

noob_lolo Mitglied 16:52:00 21.03.2010 Titel:

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 :confused:

lg lolo

/rant/ Mitglied 02:07:26 22.03.2010 Titel:

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

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 :live:

MfG

Tim06TR Mitglied 12:26:47 22.03.2010 Titel:

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 ( :eek:

).

berniebutt Mitglied 13:48:21 22.03.2010 Titel:

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 :confused:

lg lolo

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. 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. :eek:

noob_lolo Mitglied 00:57:39 23.03.2010 Titel:

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 -> stil

lg lolo

thordk Mitglied 09:02:34 23.03.2010 Titel:

/rant/ schrieb:

die eleganten Lösungen sind nicht immer die einfachsten

Häufig sind die einfachen Lösungen allerdings die elegantesten, da wartbarsten.

berniebutt Mitglied 11:44:47 23.03.2010 Titel:

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.

asc Mitglied 11:54:10 23.03.2010 Titel:

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).

/rant/ Mitglied 13:32:35 25.03.2010 Titel:

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