Schlechter Code unter Zeitdruck

[Luckie]

Wir hatten in der Firma ein Projekt für einen Kunden. Dafür hatten wir natürlich eine Deadline, die auch unbedingt gehalten werden musste. Dieses wurden in CakePHP umgesetzt. Jetzt arbeite ich an einen Firmen internen Projekt auch mit CakePHP ohne richtige Deadline. OK, es soll natürlich auch mal fertig werden, aber ich habe keinen Zeitdruck. Das Projekt für die extrene Firma war mein erstes Projekt mit CakePHP. Jetzt musste ich feststelle, wo ich mehr Zeit habe, dass ich bei meinem ersten CakePHP Projekt vieles ziemlich unsauber gelöst habe und ihm Nachhinein bin ich damit auch ziemlich unzufrieden. Aber der Zeitdruck lies es einfach nicht zu lange nach einer besseren Lösung zu suchen.

Wie geht ihr mit solchen Situationen um?

[SirThornberry]

Man entwickelt sich immer weiter uns selbst wenn man alle Zeit der Welt hat und den Quelltext einige Monate später ansieht wird man so einiges finden was man nicht mehr so machen würde.
Daher meine Einstellung in dieser Sache: Lass die Vergangenheit ruhen und lerne für die Zukunft.

[Luckie]

Zitat:

Zitat von SirThornberry

Man entwickelt sich immer weiter uns selbst wenn man alle Zeit der Welt hat und den Quelltext einige Monate später ansieht wird man so einiges finden was man nicht mehr so machen würde.

Ja das ist klar.

Zitat:

Daher meine Einstellung in dieser Sache: Lass die Vergangenheit ruhen und lerne für die Zukunft.

Bleibt mir ja nichts anderes übrig. ;)

Aber geht ihr dann in solchen Situationen auch schon mal zum Chef und sagt ihm, dass ihr mehr Zeit braucht, um guten, sauberen Code zu produzieren und der Zeitplan deswegen nicht eingehalten werden kann oder frickelt ihr dann was zusammen, was zwar läuft aber der Zeitplan gehalten werden kann?

[himitsu]

Zitat:

Zitat von Luckie

Aber geht ihr dann in solchen Situationen auch schon mal zum Chef und sagt ihm,

Sollte man sowas nicht besser mit dem Kunden absprechen?
- Könnt ihr noch etwas warten und bekommt dafür ein "besseres" Produkt
- oder wollt ihr einfach nur ein "irgendwie" funktionierendes Produkt?

Der Chef könnte doch höchstens sagen
- OK, nehmen wir 'ne Verzugsstrafe hin und machen es besser.
oder (was dann wohl eher dabei rauskommt)
- Egal, Hauptsache es läuft und wir bekommen keinen Ärger.

[Luckie]

Ich habe keinen Kundenkontakt, das läuft alles über den Chef. Mein Ansprechpartner wäre der Chef. Aber das Ding ist ja, mein schlechter Code funktioniert und tut, was er soll. Und das ist ja das Dilemma, der Kunde sieht nur die Fassade und das ist es, was ihn interessiert, aber er sieht nicht was dahinter steckt.

[himitsu]

Nja, jedenfalls wenn es schon kurz vor knapp ist und man keine Zeit mehr hat,
dann könnte man (oder der Chef) eben mit dem Kunden sprechen.

Wenn man diesem erklärt worum es geht und er sagt "OK, wenn es danach besser ist, dann geb ich euch noch etwas mehr Zeit", dann könnte man es ja noch besser machen oder es bleibt so wie es ist.

Wobei man es dem Kunden auch verschweigen könnte und es auch einfach so läßt ... so aus Angst vor dem, wie der Kunde reagieren könnte.


Oder bei Abgabe des Projekts: "Hier hab ihr es ... PS: Wenn ihr wollt, dann könnten wir es (gegen mehr Geld) noch etwas verbessern." :angel2:

[Matze]

Wenn der Code zuverlässig funktioniert und sicher ist, sehe ich kein Problem darin.
Wenn ihr die Website warten müsst und merkt, dass es so nur schwer möglich ist, dann könnt ihr den Code immer noch im Laufe der Zeit anpassen.

Wie du sagst, interessiert den Kunden meistens nur, dass etwas funktioniert. Egal wie der Code aussieht. Und unter Zeitdruck geht es oft auch nicht anders.

Bei neuen Projekten kannst du es natürlich besser machen, wenn dein Chef einverstanden ist. Er zahlt sicher auch nicht gerne, wenn du nun Wochen lang Code optimierst und im Endeffekt kein entsprechender Mehrwert herauskommt. Handelt es sich um eine Art Vorlage, die immer wieder verwendet wird, ist die Zeit sicher gut investiert.

[Luckie]

Ich denke schon, dass die Zeit gut investiert ist, da spätere Anpassungen wesentlich einfacher und schneller umsetzbar sind, auch für andere, die nicht so in das Projekt eingearbeitet sind.

Beispielsweise sollen Formulare mit Standardwerten vorbelegt werden. Bisher habe ich es so, dass man jedes mal den internen Code anfassen muss. Zur Zeit zerbreche ich mir den Kopf, wie ich es hinbekomme, dass ein einfacher Funktionsaufruf genügt. Und das dauert eben.

[Matze]

Zitat:

Zitat von Luckie

Beispielsweise sollen Formulare mit Standardwerten vorbelegt werden. Bisher habe ich es so, dass man jedes mal den internen Code anfassen muss. Zur Zeit zerbreche ich mir den Kopf, wie ich es hinbekomme, dass ein einfacher Funktionsaufruf genügt. Und das dauert eben.

Mit einer Template-Engine ist das ein Klacks. ;)

[Luckie]

Das steht jetzt hier nicht zur Debatte.

[FBrust]

Hallo Luckie,

du kannst halt nur abwarten, ob Du das Produkt nochmal auf den Tisch bekommst und dann eben das eine oder andere verbessern (sofern Du nicht wieder eine Deadline hast :mrgreen: ). Aber man wird ja mit jedem Projekt besser (oder sollte es zumindest :wink: ).



Gruß
Frank

[mirage228]

Tag,

Ich würde da versuchen die goldene Mitte zu treffen, was bestimmt leichter gesagt als getan.

Hintergrund ist, dass der schlechte Code zwar funktioniert, aber zukünftige Erweiterung und die Code-Wartung ggf. schwieriger ( = teurer ) macht. Mit diesem Kosten-Argument, und dass die Kosten je mehr neuer Code auf dem alten schlechten Code basiert immer weiter steigen können, kannst Du solche nachträglichen Arbeiten am Code eigentlich recht plausibel begründen und auch einfordern. Letzlich muss eben das Kosten/Nutzen-Verhältnis stimmen.

Wo bei dir allerdings das Ziel der Überarbeitung liegt, lässt sich ohne konkreten Code nicht sagen, aber der Hinweis auf die Template-Engine war schon recht gut für den Anfang würde ich sagen :)

Viele Grüße,

[shmia]

Als Programmierer bewegt man sich in dem Dreieck
Qualität <-> Zeit <-> Funktionsumfang
Wenn man versucht einen dieser drei Parameter zu ändern (meist weniger Zeit und/oder mehr Funktionsumfang) müssen sich
zwangsläufig die anderen Parameter verändern (typisch: Qualität wird sinken).
Lesestoff: http://www.codinghorror.com/blog/200...ron-stool.html

Man darf aber die Qualität keinesfalls zu weit absinken lassen!
Jeder Fehler, der übersehen wird verursacht später beim Kunden die zehnfachen Kosten.
Schwache und schlampige Designs können später enorme Wartungskosten verursachen.
Es rächt sich immer wieder, wenn man nicht genug Wert auf Qualität gelegt hat.

Mit mehr Manpower kann man manchmal die Parameter Zeit und/oder Funktionsumfang verbessern.
Bringt man allerdings zusätzliche Programierer in ein Projekt unter Zeitdruck, wird sich das Projekt
noch weiter verzögern (neue Programmierer bremsen die bisherigen Programmierer).
adding manpower to a late software project makes it later

[mschaefer]

Ja jeder der Codiert ist wohl auch etwas besessen davon und der künstlerische Aspekt von sauberen Code ist sicherlich nicht zu vereachten. Kann Luckie da gut nachvollziehen, aber manchmal sind Deadlines einfach wichtig, damit andere Menschen weiterarbeiten können und dann muß es halt laufen.

Wenn so ein Projekt wieder auftaucht, dann muß man halt da durch. Aber oft haben sich dann die Anforderungen soweit verändert, dass man ehedem vieles Überdenken muß und aufgurnd der vielen Versionsänderungen von IDE und Komponennten erübrigt sich vieles.

Mein Ansatz ist, dass ich versuche mit gut aufgeräumten Routinen und Komponentne ins Renne zu gehen. Was im Projekt für Überraschunen auftauchen ist sicherlich nicht immer vorhersehbar und daher muß man auch mal mit Nebenstrecken zum Ziel kommen.

Grüße in die Runde // Martin