denn sie wissen nicht was sie programmieren, zumindest ich =)

Begrün schrieb:

Hier ist einer der besser hätte programmieren können, wenn er ein besseres Gedächtnis gehabt hätte. http://www.c-plusplus.net/forum/viewtopic-var-t-is-253654.html

jaja, das macht nur der viele alkohol. *fg*

Icematix

Kennt ihr das auch?

Man schaut nach etwas Zeit alten Code an, bemerkt plötzlich vermeintliche Fehler, schreibt den halben Code um bis man bemerkt dass es davor doch richtig war und jetzt falsch ist?

Icematix schrieb:

Man schaut nach etwas Zeit alten Code an, bemerkt plötzlich vermeintliche Fehler, schreibt den halben Code um bis man bemerkt dass es davor doch richtig war und jetzt falsch ist?

ja, das passiert wenn man nicht mehr komplett im thema drinsteckt und meint, irgendwas verbessern zu müssen, was vordergründig umständlich aussieht. liegt aber oft auch an schlechten/falschen kommentaren im code. ich bin in der beziehung sehr vorsichtig geworden. der spruch: 'never change a running system' existiert nicht ganz zu unrecht.

byto

Icematix schrieb:

Man schaut nach etwas Zeit alten Code an, bemerkt plötzlich vermeintliche Fehler, schreibt den halben Code um bis man bemerkt dass es davor doch richtig war und jetzt falsch ist?

Mit Unittests wäre das nicht passiert.

EXDW

;fricky schrieb:

der spruch: 'never change a running system' existiert nicht ganz zu unrecht.

dieses sprichwort fuehrt dazu das dirty hacks auch drinnen bleiben
(wenn man nie ein funktionierendes system geaendert haette waeren wir noch auf windows 3.0)

man muss immer wieder etwas riskieren um auch richtige fortschritte zu haben

Mr Evil schrieb:

;fricky schrieb:

der spruch: 'never change a running system' existiert nicht ganz zu unrecht.

dieses sprichwort fuehrt dazu das dirty hacks auch drinnen bleiben
(wenn man nie ein funktionierendes system geaendert haette waeren wir noch auf windows 3.0)
man muss immer wieder etwas riskieren um auch richtige fortschritte zu haben

naja, ich brauche schon einen triftigen grund, um irgendwas zu verändern. wenn eine software nur aus lauter miesen hacks besteht, sonst aber prima läuft, ist für mich kein grund.

MasterK

;fricky schrieb:

wenn eine software nur aus lauter miesen hacks besteht, sonst aber prima läuft, ist für mich kein grund.

Bis man irgendwann in der situation ist, dass man in relativ kurzer zeit neue funktionalität hinzufügen soll. Dann steht man vor einem riesen haufen code-müll und versucht die neuen funktionen da irgendwie reinzufrickeln, was in noch grösserem code-müll endet. Ganz abgesehen davon natürlich, dass es 3x so lang dauert. Und man beim nächsten mal vor genau dem gleichen problem steht.

Aber es läuft ja. Irgendwie...

MasterK schrieb:

Bis man irgendwann in der situation ist, dass man in relativ kurzer zeit neue funktionalität hinzufügen soll.

das wäre z.b. ein grund fürs aufräumen.

EXDW

er sagte ja "relativ kurze zeit"
man kann doch schon vorher aufraeumen - wo man die zeit hat - und da muss man ein funktionierendes system anfassen und aendern - einfach damit die dirty hacks weg sind (die aus zeitmangel rein kamen) und man spaeter beim erweitern keine zeit dafuer aufbringen muss

viele meiner kollegen dachten anfangs auch so - immer mehr leute gehen von diesem sprichwort weg und riskieren auch mal etwas - muss man halt hin und wieder

byto

Deswegen ist der konsequente Einsatz von Unittests so sinnvoll.

Muss man das System ändern, kann man jederzeit überpüfen, ob Unittests fehlschlagen. Laufen alle Tests durch, ist das natürlich noch keine Garantie, dass alles einwandfrei funktioniert. Aber viele Fehler lassen sich dadurch schonmal aufdecken.

Und je besser die Qualität der Tests, umso mehr Fehler findet man bei Codeänderungen. Zusätzlich sinkt die Hemmschwelle der Entwickler, bestehenden Code sinnvoll zu refactorn, statt einfach nur einen Balkon dranzubauen.

Mr Evil schrieb:

viele meiner kollegen dachten anfangs auch so - immer mehr leute gehen von diesem sprichwort weg und riskieren auch mal etwas - muss man halt hin und wieder

aber es ist doof risiken einzugehen, wenn man am ende fast nichts gewinnt. jede software ist irgendwie modular aufgebaut. wenn nun eins dieser module von übelsten dilettanten zusammengeflickt wurde und nur per zufall funktioniert, gibt es keinen grund, etwas daran zu verändern, wenn dieses modul einfach nur benutzt werden soll und es zuverlässig arbeitet. aus sicht von client-code ist es eine 'black box', die irgendwelche funktionen erfüllen soll. wie sie das macht, oder wie schlecht sie programmiert ist, spielt dabei keine rolle. erst wenn das ding probleme macht, muss es umgebaut oder ersetzt werden, vorher nicht. man sollte sein ästhetisches empfinden in den hintergrund stellen, wenn man fremden code einsetzt. das ist vielleicht für viele nicht ganz einfach.

byto schrieb:

Deswegen ist der konsequente Einsatz von Unittests so sinnvoll.

auf jeden fall sind unit-tests sehr sinnvoll. aber sie sind keine versicherung gegen fehler, wenn man an code rumbastelt, ohne zu wissen, welche folgen irgendwelche eingriffe haben können.

EXDW

wenn das modul aber in sehr kurzer zeit erweitert oder anders veraendert werden soll hat man nicht mehr die zeit den dirty hack weg zu bekommen oder das ding neu auf zu ziehen - schlimmstenfalls verstaerkt man noch die hacks indem andere drum herum gebastelt werden

fuer den benutzer ist es ne blackbox - da hast du recht - aber darum gehts gar nicht sondern um das modul selber

;fricky schrieb:

aber es ist doof risiken einzugehen, wenn man am ende fast nichts gewinnt. jede software ist irgendwie modular aufgebaut. wenn nun eins dieser module von übelsten dilettanten zusammengeflickt wurde und nur per zufall funktioniert, gibt es keinen grund, etwas daran zu verändern, wenn dieses modul einfach nur benutzt werden soll und es zuverlässig arbeitet. aus sicht von client-code ist es eine 'black box', die irgendwelche funktionen erfüllen soll. wie sie das macht, oder wie schlecht sie programmiert ist, spielt dabei keine rolle. erst wenn das ding probleme macht, muss es umgebaut oder ersetzt werden, vorher nicht. man sollte sein ästhetisches empfinden in den hintergrund stellen, wenn man fremden code einsetzt. das ist vielleicht für viele nicht ganz einfach.

Zum Teil gebe ich Dir da Recht, nur weil ein Modul schlecht programmiert ist muß man es nicht zwingend verbessern. Auf der anderen Seite gehst Du aber ebenso ein Risiko ein es nicht anzupacken.

Scenario 1: Du läßt das schlechte MOdul solange laufen bis tatsächlich ein Problem austritt und packst es erst dann an.

Scenario 2: Du machst eine Refaktoring Runde um zumindest die schlimmsten Hacks loszuwerden auch ohne das ein akutes Problem existiert.

Nach "Never change a running System" würde man Scenario 1 bevorzugen. Das große Risiko dabei ist, daß man nicht vorhersagen kann _wann_ ein Problem auftritt und ob man dann, wenn es auftritt die notwendige Zeit hat es zu lösen. Im worst-case könnte das Problem so ungünstig auftreten das man eine wichtige Deadline vermasselt. Erschwerend kommt hier hinzu das der schlechte Code eine Problemlösung in der Regel zusätzlich erschwert.

Im Scenario 2 dagegen wird die Problembekämpfung zu einem Zeitpunkt durchgeführt den man selbst bestimmen kann, damit wird die Arbeit planbar. Klar kann immer noch zu einem späteren Zeitpunkt ein unvorhergesehenes Problem auftreten, aber dann kommt einem der bereits aufgeräumte Code wahrscheinlich entgegen und die Problemlösung wird leichter.

In der Realität bin ich allzu oft gezwungen Scenario 1 zu wählen, aber mehr als einmal mußte ich bei Projekten erleben wie ein "Quick Hack" meines Vorgängers mir eine Deadline versaut hat. Sauberer Code ist mehr als nur ein "Nice to have", langfristig kann er Dir den Arsch retten. Wogegen diese "läuft schon irgendwie Hacks" auf lange Sicht fast immer mehr Probleme erzeugen als sie lösen.