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