Warum sind die meisten Programmierer schlechte Bugfixer?
-
DEvent schrieb:
Ein gutes Projekt sollte immer TDD konsequent durchsetzen.
Nö. Alle Generalisierungen sind falsch.
-
volkard schrieb:
DEvent schrieb:
Ein gutes Projekt sollte immer TDD konsequent durchsetzen.
Nö. Alle Generalisierungen sind falsch.
Hast du ein Beispiel, wo TDD schlecht ist?
-
DEvent schrieb:
Hast du ein Beispiel, wo TDD schlecht ist?
Kommt bei grafiklastigen "Anwendungen" schon mal vor.
-
DEvent schrieb:
volkard schrieb:
DEvent schrieb:
Ein gutes Projekt sollte immer TDD konsequent durchsetzen.
Nö. Alle Generalisierungen sind falsch.
Hast du ein Beispiel, wo TDD schlecht ist?
Du plonk du. "Alle Generalisierungen sind falsch"!
Wo TDD schlecht ist? Ich leite von JPanel ab und mir redet ernsthaft jemand ein ich soll diese Klasse TDD'en.
- GUI
- Programme die lange Berechnungen durchführen und das Ergebnis, ... das hat ja keinen Sinn
- Programme die viel an ihrem Environment ändern (Rollback eines Tests nicht möglich)Eigentlich ist TDD maximal bei der Persistenzschicht und ganz eingeschränkt noch in der Serviceschicht von 0815-Business-Anwendungen günstig.
MfG SideWinder
-
Softwaresysteme sind sehr komplex. Daher ist das Auffinden von Fehlern äußerst schwierig. Es fehlt einem einfach oft an der Übersicht.
Nach meiner Erfahrung ist TDD keine magische Formel zum vermeiden von Bugs. Entweder sind die Tests zu lokal oder zu global. Lokale Tests (die zB nur eine Methode überprüfen) finden oft die Bugs nicht, da sie in komplizierteren Situationen auftreten und globale Tests sind schwer zu schreiben (und was bringt der Test, wenn er dann 2 Tage zum durchlaufen braucht?) und testen daher auch oft nicht die Fälle wo dann die schwierigen Bugs auftreten und wenn man doch Bugs entdeckt, dann steht man bei globalen Tests vor dem gleichen Problem der Bugsuche. Persönlich finde ich TDD schon praktisch und ich schreibe für meinen Code regelmäßig Tests. Aber die Tests finde ich eher nützlich beim umschreiben oder erweitern von Code und um das API-Design überprüfen zu können. (Wobei zu lokale Tests das umschreiben aber auch sehr limitieren können.)
-
TDD fördert aber das schreiben einzelner, testbarer Codemodule. Ebenso fördert es Refactoring und Verbesserungen oder Optimierungen am Code, da man sicherer ist, dass eine Änderung nicht ein Feature bricht oder ein Bug einführt.
* GUI
Da gibt es auch Testframeworks. Habe mich damit aber nicht beschäftigt. Meistens wird da doch geprügt, ob ein Button auch eine Aktion ausführt oder ein Input-Feld seine Eingabe überprüft.* Programme die lange Berechnungen durchführen und das Ergebnis, ... das hat ja keinen Sinn
Meistens kann man diese lange Berechnungen in kurze Teilberechnungen aufsplitten, die testbar sind. Auch testet man nicht alle möglichen Werte, sondern man hat Werte-Klassen (Äquivalenzklasse http://de.wikipedia.org/wiki/Äquivalenzklassentest).* Programme die viel an ihrem Environment ändern (Rollback eines Tests nicht möglich)
Man testet doch in einer Testumgebung, da ist meist ein Rollback möglich. An was hast du da gedacht?Sicher ist es irgendwo nicht möglich oder zu aufwändig TDD zu betreiben, aber ich bleibe bei meiner Ausage: Ein gutes Projekt sollte immer TDD konsequent durchsetzen.
Gibt es nun ein Beispiel, wo TDD wirklich etwas negatives ist? Ich kann mir kein Vorstellen, es sei denn es ist wirklich aufwändig etwas zu testen.
-
Das ist jetzt aber ein religiöser Feldzug und mutet nicht mehr so an, als würde es auf Beobachtungen und logischen Schlußfolgerungen beruhen.
Wenn Du Dich mit TDD besser im Griff hast, ist es ja gut. Aber Dein Lieblingswerkzeug ist nicht mein Lieblingswerkzeug.
(Unterschiedliche Religionen machen Debuggen auch schwieriger.)
-
TDD ist auch nur ein Werkzeug. Und bessere Werkzeuge ermöglichen mir, noch komplexere Probleme anzugehen. Das reduziert nicht zwangsweise die Fehlerrate.
Das ist so ähnlich, wie mit Autos. Mit dem Auto bin ich nicht schneller am Ziel als zu Fuß. Mein Ziel ist nur viel weiter weg
. Früher ist man nicht auf die Idee gekommen, mal schnell zur nächsten Stadt zu gehen, weil diese 50 km entfernt ist. Da begnügte man sich halt mit dem Dorf in 3 km Entfernung.Es gibt kein Programmierwerkzeug, welches Bugs von vorneherein ausschliesst. Die Bugs werden aber unter Umständen subtiler und daher schwerer zu finden. Das bedeutet nicht unbedingt, dass der Code schlecht ist. Auch guter Code enthält leider Fehler.
-
tntnet schrieb:
Es gibt kein Programmierwerkzeug, welches Bugs von vorneherein ausschliesst. Die Bugs werden aber unter Umständen subtiler und daher schwerer zu finden. Das bedeutet nicht unbedingt, dass der Code schlecht ist. Auch guter Code enthält leider Fehler.
Es gibt eines, du kannst code in formeln zerlegen und analysieren und so vom vorgegebenem input auf den vorgegebenen output loesen. kannst du die formel nicht loesen, ist der code fehlerhaft.
das verschiebt natuerlich den fehler, die fehler liegen dann auf der definitions seite. Aber rein bugmaessig ist so ein code fehlerfrei da er genau nach definition handelt.
-
DEvent schrieb:
* Programme die viel an ihrem Environment ändern (Rollback eines Tests nicht möglich)
Man testet doch in einer Testumgebung, da ist meist ein Rollback möglich. An was hast du da gedacht?Ab einer gewissen Datenmenge wird das schon schwerer... oder in einem Echtzeitumfeld (near realtime, ich spreche jetzt nicht von Embedded), wo Datenströme auf das System einprasseln. Die Testumgebung ist deutlich geringer komplex als das Applikationsumfeld.
Ein TDD ist ja eine Linearisierung der Daten nach der Zeit, und damit nur eine Annäherung an das Verhalten der Realität.
-
Schwer reproduzierbare Bugs finden und fixen ist schonmal grundsätzlich schwer, auch wenn man den Code selbst geschrieben hat. Das wurde ja schon mehrfach geschrieben.
Wenn der Code dann noch von jmd. anderem ist, dann ist es doppelt und dreifach schwer. Ich würde meinen dass das selbstverständlich ist und keiner näheren Erleuterung bedarf.
Da der OP aber anscheinend genau eine solche haben will...Bei Code den ich selbst geschrieben habe, bzw. wo ich am gesamten Entwicklungsprozess eng beteiligt war, habe ich einen guten Überblick über das ganze Programm. Ich kenne die Stellen wo "gehackt" wurde (z.B. schnell umsetzbar statt sauber programmiert wurde) und überhaupt weiss ich was wo wie passiert.
Daher kann ich viel schneller Vermutungen darüber anstellen, was den Bug auslösen könnte. Wenn es dann ums fixen geht, kann ich auch viel besser abschätzen was ich wo wie ändern kann, ohne dass dadurch neue Fehler entstehen.Bei Code der nicht von mir ist fehlt mir dieser Überblich. Sich so einen Überblich zu verschaffen ist nicht ganz einfach, und erfordert auch einiges an Zeit. Da der Code von jemandem geschrieben wurde der anders denkt als man selbst, folgt er auch anderen ungeschriebenen Gesetzen. Das macht es doppelt schwer. Etwas was man selbst nie machen würde, und daher auch gar nie auf die Idee kommen würde davon auszugehen jemand anderes könnte es machen, findet der ursprüngliche Programmierer vielleicht voll OK, und hat es an ein paar Stellen verwendet. Genau so kann es umgekehrt sein: man findet einen komplizierten Workaround für irgendwas was man selbst ganz OK gefunden hätte, und wundert sich dann erstmal lange warum er es nicht anders gemacht hat, weil es anders ja auch total OK gewesen wäre. Und sucht den (nicht vorhandenen) zwingenden Grund für den komplizierten Workaround.
-
rapso schrieb:
tntnet schrieb:
Es gibt kein Programmierwerkzeug, welches Bugs von vorneherein ausschliesst. Die Bugs werden aber unter Umständen subtiler und daher schwerer zu finden. Das bedeutet nicht unbedingt, dass der Code schlecht ist. Auch guter Code enthält leider Fehler.
Es gibt eines, du kannst code in formeln zerlegen und analysieren und so vom vorgegebenem input auf den vorgegebenen output loesen. kannst du die formel nicht loesen, ist der code fehlerhaft.
das verschiebt natuerlich den fehler, die fehler liegen dann auf der definitions seite. Aber rein bugmaessig ist so ein code fehlerfrei da er genau nach definition handelt.
Du hast es ja selbst beantwortet. Probleme bleiben. Das, was Du exakt definieren kannst, bzw. definiert hast, kann im Prinzip Fehlerfrei funktionieren. Aber tut es das auch, wenn ich beispielsweise in einer multithreaded Umgebung Gleichzeitigkeit habe? Oder bei fehlerhaften Eigabedaten? Bei beliebigen fehlerhaften Eingabedaten? Oder auch bei im Prinzip korrekten, aber doch ungewöhnlichen Daten? Reagiert das System bei beliebigen Benutzerinteraktionen korrekt? Was ist bei hoher Last? Was ist, wenn ein unerwarteter technische Fehler auftritt? Es gibt einfach viele Probleme, die sich nicht einfach in eine Formel zerlegen lässt.
Wie auch beim TDD kann dadurch eine bestimmte Fehlerart stark reduziert werden. Aber auch die Werkzeuge wollen richtig eingesetzt werden. Häufig kommt beim TDD auch das Problem, dass ich doch nicht alle möglichen Fälle bedacht habe. Da habe ich schon ein ach so tolles Werkzeug TDD und dennoch spielt da der Faktor Mensch eine Rolle. So was ärgerliches aber auch
.
-
volkard schrieb:
Alle Generalisierungen sind falsch.
Ist diese Aussage nicht etwas zu generell?
...
-
.bugbuster. schrieb:
Vorallem wenn es um Bugs geht die nicht ganz so einfach zu reproduzieren sind oder wenn sie den Code nicht selber geschrieben haben, sind einige Programmierer richtig schlecht, wenns darum geht einen Bug zu fixen. Warum?
Um Bugs zu finden, muß man den Code richtig kennen, und das ist bei fremden Programmcode nun einmal sehr zeitaufwendig. Wenn man ein Projekt übernimmt, und dann daran arbeitet ist das machbar, aber mal eben so einen Bug in fremden Programmcode zu finden ist mit sehr viel Einarbeitungsaufwand verbunden, der oftmals in keinem Verhältnis zu Ergebnis steht. Außenstehende haben leider meist keinerlei Überblick wie groß der Aufwand wirklich ist.
-
Manchmal kann aber ein Außenstehender trotzdem einen Bug viel schneller oder überhaupt finden, als jemand der das Projekt in und auswendig kennt. Denn derjenige der das Projekt sooo gut kennt, kann auch betriebsblind werden. Es kommt aber natürlich auf die Art des Bugs an. Aber ein Fremder muß nicht generell die größere Hürde überwinden.
-
~john schrieb:
Wenn man ein Projekt übernimmt, und dann daran arbeitet ist das machbar, aber mal eben so einen Bug in fremden Programmcode zu finden ist mit sehr viel Einarbeitungsaufwand verbunden, der oftmals in keinem Verhältnis zu Ergebnis steht.
Das hängt davon ab, was der Außenstehende tun soll:
Soll er den Bug unter Einbeziehung der Architektur ändern, benötigt er viel mehr Zeit. Konzentriert er sich aber ausschließlich auf den Bug - unter Vernachlässigung von Kollateralschäden - wird er wohl schneller und rascher Ergebnisse erzielen können.
-
Ein paar mal und dann wirds richtig schwierig.
-
Tyrdal schrieb:
Ein paar mal und dann wirds richtig schwierig.
Daraus folgt, dass es bei den meisten Projekten richtig schwierig ist, und damit wären wir wieder bei der Ausgangsfrage. Die man IMO damit beantworten kann: Weil die meisten Programmierer schlechte Programmierer sind.
-
Artchi schrieb:
Manchmal kann aber ein Außenstehender trotzdem einen Bug viel schneller oder überhaupt finden, als jemand der das Projekt in und auswendig kennt. Denn derjenige der das Projekt sooo gut kennt, kann auch betriebsblind werden. Es kommt aber natürlich auf die Art des Bugs an. Aber ein Fremder muß nicht generell die größere Hürde überwinden.
Stimmt schon, ja.
Muss nicht generell.
Meistens braucht er aber länger.
Und spätestens wenns dann um's Fixen geht kann es für nen Aussenstehenden schnell sehr aufwendig werden. MUSS natürlich auch nicht sein. Gibt ja genug Bugs die so simpel und "lokal" sind, dass das Fixen überhaupt kein Thema ist, sobald man den Bug mal gefunden hat.
-
Bashar schrieb:
Weil die meisten Programmierer schlechte Programmierer sind.
Ich wollte es nicht schreiben .. vielleicht nicht die meisten, aber viele.:)
