Mit einem Debugger findest du crashes, super, das ist aber nur ein mögliches Problem. Um den Crash zu finden brauch ich keinen Debugger, da reicht auch der Crash Report der Users. Und was hat man wenn man die Stelle gefunden hat? Richtig die Stelle Code an der es abraucht. Das hilft bei der Problemlösung ziemlich wenig wenn man die Materie nicht kennt - und das ist genau was hier ausgesagt wurde.
Ich gib dir jetzt mal einen Crash Fix als Beispiel. Ein Crash bei dem wir etwa zwei Jahre lang nicht wussten wie man ihn auslösen kann. Wir wussten die Zeile wo es abraucht, aber nicht warum. Zuletzt nach einigen Code-Änderung hätte dir ein Debugger nicht mal mehr den Crash gezeigt, da es ein vom Timing abhängiges Problem war - upps Debugger verändern ja das Verhalten von Anwendungen. Ohne tiefes Verständnis des internen Aufbaus der Anwendung wäre dieser Crash nicht behebbar gewesen und den Ansatz den ich gewählt hatte, war ein Schuss ins Blaue basierend auf Annahmen, die ich ableiten konnte aus meinem Wissen über den internen Aufbau der Anwendung und das Verhalten im fraglichen Zeitraum.
Ich wage sehr zu bezweifeln, dass ein nicht Domain Experte dieses Problem hätte identifizieren können (den Weg das Problem zu reproduzieren hatte ich auch selbst aus Wissen über die Anwendung abgeleitet), noch dass er auf den Lösungsansatz gekommen wäre, noch dass er ihn hätte umsetzen können. Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Von C++ Entwickler am So, 19. August 2012 um 16:34 #
Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Erkennst du hier deinen Denkfehler nicht?
Du schreibst "Experten der Anwendung". Eben, ein Experte der Anwendung ist nicht zwangsläufig auch ein Experte der RFCs, Gesetzesvorschriften und Normen in diesem Bereich, etwas, was du ja zu Beginn hier angeführt hast, daß man das brauchen würde, um den C++ Code zu fixen. Siehe deine Worte:
Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt.
Es ist also ein Code wie jeder andere, der eine bestimmte Anwendung bildet. Für die Anwendung arbeitet man sich kurz ein, bei gegebenen UML Diagramm sollte das recht effizient möglich sein, ansonsten nimmt man eben den Code und dann kann ein guter C++ Entwickler auch das Problem fixen.
Denn das Problem hat nichts mit RFCs, Gesetzevorschriften oder Normen oder speziellen Softwarebereichen zu tun, sondern es ist schlichtweg nur C++ Code.
Die Grundlagen die einem Programm zugrunde liegen sind überall gleich, die Spezialisierung fängt erst da an, wo du Experten in umzusetzenden Gestezesvorschriften, RFCs oder Normen benötigst und das braucht man nicht zum Bug fixen, sondern für nur neue Features.
nun ok du hast vollkommen Recht ich bin ein absoluter Idiot. Ich verstehe gar nicht warum ich mehr als ein Jahr gebraucht habe bis ich KWin intern verstanden habe und ich verstehe noch viel weniger warum ich nach all den Jahren und sogar mittlerweile als Maintainer immer noch Bereiche gibt von denen ich keine Ahnung habe.
Ich hätte mich wohl besser mal kurz in den Quellcode einarbeiten müssen oder ich bin einfach ein zu schlechter Programmierer.
Nun zu der RFC Geschichte. Klar wenn ich bei KWin Bugs behebe brauche ich dafür keine RFC, trotzdem hab ich hier einen kompletten Stapel mit ausgedruckten Spezifikationen, die ich immer mal wieder zur Rate ziehe. Muss manchmal schon sein, wenn sich die GTK Anwendungen anders verhalten als die Qt Anwendungen. Da muss man halt schon mal die Specs lesen. Aber klar braucht man ja nicht, der C++ Code ist natürlich völlig ausreichend.
Schon mal gesehen, dass ein RFC buggy ist oder von Servern falsch umgesetzt wird? Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten. Aber klar das Lesen des Quellcodes hätte das Problem sicherlich behoben.
"Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten."
Und jetzt? Musst Du die "Diplomarbeit" noch einmal schreiben?
Sorry, aber was du schreibst ist ziemlich naiv.
Mit einem Debugger findest du crashes, super, das ist aber nur ein mögliches Problem. Um den Crash zu finden brauch ich keinen Debugger, da reicht auch der Crash Report der Users. Und was hat man wenn man die Stelle gefunden hat? Richtig die Stelle Code an der es abraucht. Das hilft bei der Problemlösung ziemlich wenig wenn man die Materie nicht kennt - und das ist genau was hier ausgesagt wurde.
Ich gib dir jetzt mal einen Crash Fix als Beispiel. Ein Crash bei dem wir etwa zwei Jahre lang nicht wussten wie man ihn auslösen kann. Wir wussten die Zeile wo es abraucht, aber nicht warum. Zuletzt nach einigen Code-Änderung hätte dir ein Debugger nicht mal mehr den Crash gezeigt, da es ein vom Timing abhängiges Problem war - upps Debugger verändern ja das Verhalten von Anwendungen. Ohne tiefes Verständnis des internen Aufbaus der Anwendung wäre dieser Crash nicht behebbar gewesen und den Ansatz den ich gewählt hatte, war ein Schuss ins Blaue basierend auf Annahmen, die ich ableiten konnte aus meinem Wissen über den internen Aufbau der Anwendung und das Verhalten im fraglichen Zeitraum.
Ich wage sehr zu bezweifeln, dass ein nicht Domain Experte dieses Problem hätte identifizieren können (den Weg das Problem zu reproduzieren hatte ich auch selbst aus Wissen über die Anwendung abgeleitet), noch dass er auf den Lösungsansatz gekommen wäre, noch dass er ihn hätte umsetzen können. Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Erkennst du hier deinen Denkfehler nicht?
Du schreibst "Experten der Anwendung".
Eben, ein Experte der Anwendung ist nicht zwangsläufig auch ein Experte der RFCs, Gesetzesvorschriften und Normen in diesem Bereich, etwas, was du ja zu Beginn hier angeführt hast, daß man das brauchen würde, um den C++ Code zu fixen.
Siehe deine Worte:
Es ist also ein Code wie jeder andere, der eine bestimmte Anwendung bildet.
Für die Anwendung arbeitet man sich kurz ein, bei gegebenen UML Diagramm sollte das recht effizient möglich sein, ansonsten nimmt man eben den Code und dann kann ein guter C++ Entwickler auch das Problem fixen.
Denn das Problem hat nichts mit RFCs, Gesetzevorschriften oder Normen oder speziellen Softwarebereichen zu tun, sondern es ist schlichtweg nur C++ Code.
Die Grundlagen die einem Programm zugrunde liegen sind überall gleich, die Spezialisierung fängt erst da an, wo du Experten in umzusetzenden Gestezesvorschriften, RFCs oder Normen benötigst und das braucht man nicht zum Bug fixen, sondern für nur neue Features.
nun ok du hast vollkommen Recht ich bin ein absoluter Idiot. Ich verstehe gar nicht warum ich mehr als ein Jahr gebraucht habe bis ich KWin intern verstanden habe und ich verstehe noch viel weniger warum ich nach all den Jahren und sogar mittlerweile als Maintainer immer noch Bereiche gibt von denen ich keine Ahnung habe.
Ich hätte mich wohl besser mal kurz in den Quellcode einarbeiten müssen oder ich bin einfach ein zu schlechter Programmierer.
Nun zu der RFC Geschichte. Klar wenn ich bei KWin Bugs behebe brauche ich dafür keine RFC, trotzdem hab ich hier einen kompletten Stapel mit ausgedruckten Spezifikationen, die ich immer mal wieder zur Rate ziehe. Muss manchmal schon sein, wenn sich die GTK Anwendungen anders verhalten als die Qt Anwendungen. Da muss man halt schon mal die Specs lesen. Aber klar braucht man ja nicht, der C++ Code ist natürlich völlig ausreichend.
Schon mal gesehen, dass ein RFC buggy ist oder von Servern falsch umgesetzt wird? Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten. Aber klar das Lesen des Quellcodes hätte das Problem sicherlich behoben.
"Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten."
Und jetzt?
Musst Du die "Diplomarbeit" noch einmal schreiben?
Nein, natürlich nicht. Ich hab das ganze mal im Blog zusammengefasst. Ausführlich auch hier.
68 Euro? Da finde ich die Nutzung des openSUSE Buldservice aber wesentlich origineller.