Wieviel LOC pro Tag?

[SeppJ]

volkard schrieb:

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

Auch bei Code, den du nicht selber geschrieben hast?

[volkard]

SeppJ schrieb:

volkard schrieb:

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

Auch bei Code, den du nicht selber geschrieben hast?

Wenn ich den Quellcode einsehen und testen kann, gehts gewöhnlich auch recht fix. Doof wird's, wenn der Fehler völlig außerhalb meiner Reichweite ist, schwere Architekturfehler und undokumentierte Einschränkungen von Fremdlibs zum Bleistift, aber die Fehler werden ja als Feature deklariert und nicht gefixt.

[volkard]

hustbaer schrieb:

volkard schrieb:

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

Auch bei nicht reproduzierbaren Fehler?

Wenn der Fehler garantiert nicht reproduziert werden kann, wirds schwierig.

Erinnere mich an Code von fremden Proggern,

//häßlicher code
…
delete foo;
…
//10 Zeilen, die nach C aussehen
…
return f(foo->bar)+fabs(y);

und die Schutzverletzung kommt ca alle 14 Tage Laufzeit, nämlich nur, wenn das delete zufällig auch noch auslöst, daß das ganze Speicherfragment dem BS zurückgegeben wird. Und geschätzt noch 1000 weitere so Fehler um Projekt. *Aua*

Mit Multithreading und sinnlosen Locks kann man auch gute Rätsel bauen.

Hatte wohl einfach Glück, auf keins zu treffen. Oder hab ich nur die bösen Erinnerungen verdrängt?

[numLOC]

Danke, es tut gut zu hören, dass auch ihr Profis mal länger braucht und nicht jeden Aufgabe in einem Tag erledigt ist, das beruhigt mich ungemein. Meine Firma will ich trotzdem nicht nennen. Nur soviel, selbst die Ct hat schon über ihre Dienstleistung berichtet, also ist sie mit Sicherheit nicht ganz unbekannt. Ich habe übrigens gestern mit meiner Psychologin darüber gesprochen den Job dort an den Nagel zu hängen und dann was vernünftiges zu finden, oder halt ganz mit dem beruflichen Programmieren aufzuhören. Ich solle immer auf mein Baugefühl achten und nur das tun, wo ich ein gutes Gefühl dabei habe. Jeder Gang zur Arbeit war bis jetzt die Hölle für mich, ich habe mich so nie sooo schlecht gefühlt. So etwas kann einen echt fertig machen.

[Gregor]

volkard schrieb:

Erinnere mich an Code von fremden Proggern,

//häßlicher code
…
delete foo;
…
//10 Zeilen, die nach C aussehen
…
return f(foo->bar)+fabs(y);

und die Schutzverletzung kommt ca alle 14 Tage Laufzeit, nämlich nur, wenn das delete zufällig auch noch auslöst, daß das ganze Speicherfragment dem BS zurückgegeben wird. Und geschätzt noch 1000 weitere so Fehler um Projekt. *Aua*

Kann man bei C++ nicht irgendwie automatisch zusätzliche Checks beim Kompilieren einbauen? In Fortran (ifort Compiler) kompiliere ich einfach mit

-CB -check uninit -check pointers -traceback

und schon wird beim Auführen des Programms genau an solchen Stellen abgebrochen und mir wird in der Fehlermeldung ganz genau gesagt, was los ist. Das Finden derartiger Bugs ist dann letztendlich eine Frage von Minuten.

[Xin]

volkard schrieb:

Bin wohl ein Anfänger. Schaffe es nie, länger als einen Tag an der falschen Stelle zu suchen.

Manchmal bekomme ich Fehlerbeschreibungen ("Tut's irgendwie nicht"), den Quellcode präsentiert und ich merke, wie ich automatisch die Anfängerfehler durchgehe... Bedingung in Schleifen, Semikolon... und im so im Prinzip im Moment, wo ich den Code sehe schon sagen kann, was verkehrt läuft.

Wenn der Bug aber ist, dass ein 3D-Körper kein Volumen mehr hat, obwohl der Körper perfekt aussieht. Der Körper soll nicht geschlossen sein.
Solche Bugs bekomme ich dann, weil mich da durch beiße.
Die OpenGL-Visualisierung ist perfekt.
Also muss man die Konstruktion des 3D Körpers verfolgen und stellt dann fest, dass an einem Punkt eine Ordinate bei der 7. Stelle hinter'm Komma in einem speziellen Fall verrutscht, was den Körper an einer Stelle nicht sauber schließt, aber die Information geht bei der Visualisierung verloren, da OpenGL mit float arbeitet und wir mit double. Das ganze ergab sich, dass die Facette, die aus mehr als drei Punkten besteht, die nicht perfekt in einer Ebene lagen und die Ebene dann eben einen Punkt nicht mehr genau genug trifft. Der Körper besitzt damit einen minimalen Schlitz und ist daher fehlerhaft.
Die Daten sind von einer anderen Software importiert. Wir sind extrem genau, das Datenformat ist sehr lasch. Wir müssen quasi alles reparieren bzw. interpretieren.

In einer anderen Firma hatte ich einen Fall, wo eine Exception falsch behandelt wurde, was anderswo eine Exception auslöste, die falsch behandelt wurde, was anderswo eine Exception auslöste, die bei mir einschlug. Die einzige Info, die ich hatte, war dass mein Code getestet ist und die gefangene Exception eigentlich nix mit mir zu tun hat. Gelegentlich kommt eine Exception vorbei, obwohl in dem Moment keiner was getan hat.

Wenn Du das alles an einem Tag schaffst, super. Ich empfehle Dich meinem Chef und gebe das Datenformat gerne ab.

Ansonsten fängt nicht jeder als Profi an.

hustbaer schrieb:

@Xin
You win

8 Wochen vollzeit kommt glaub ich nichtmal bei unserem hartnäckigsten Bug zusammen.

Juhuu...

Privatprojekt im Studium, bezahlt hat mir das keiner. Damit war ich für den Bug auch selbst verantwortlich. Aber Vollzeit meint wirklich 7*8 Tage * min. 8 Stunden/Tag. Aber ich habe draus gelernt. ^^

numLOC schrieb:

Danke, es tut gut zu hören, dass auch ihr Profis mal länger braucht und nicht jeden Aufgabe in einem Tag erledigt ist, das beruhigt mich ungemein. ...
Ich habe übrigens gestern mit meiner Psychologin darüber gesprochen den Job dort an den Nagel zu hängen und dann was vernünftiges zu finden, oder halt ganz mit dem beruflichen Programmieren aufzuhören.

Darf ich mal fragen mit welchen Erwartungen Du Dich hinter einen Computer setzt?

numLOC schrieb:

Ich solle immer auf mein Baugefühl achten und nur das tun, wo ich ein gutes Gefühl dabei habe. Jeder Gang zur Arbeit war bis jetzt die Hölle für mich, ich habe mich so nie sooo schlecht gefühlt. So etwas kann einen echt fertig machen.

Ein Haus baut man auch nicht von heute auf morgen. Warum sollte das bei Software anders sein?

[numLoc]

Ich habe erwartet, dass ich da morgens ins Büro kommen und Code wie ein irrer bis zum Abend runterkloppe. Anstelle dessen war ich viel mehr mit Analyse, Debuggen und Recherche beschäftigt. Ich habe mehr auf einem Blatt Papier mir die Zusammenhänge aufgezeichnet, als dass ich Code eingetippt habe. Beim Wochenmeeting musste ich Woche für Woche erzählen warum ich noch nicht weiter bin. Für die eigentliche Aufgabe wurde ein Tag angesetzt und nach 2 Monaten war ich erst fertig, weil ich überhaupt keine Ahnung von den ganzen Zusammenhängen und den Frameworks hatte. Die nächste Aufgabe hatte wieder mit einem anderen Framework und der Anpassung einer fremden Software zu tun, die ich auch nicht kannte, und da bin ich auch nicht mit fertig geworden.

Ich bin wohl zu dumm für den Job, da ich auch nicht studiert habe.

[Gregor]

Xin schrieb:

Wenn der Bug aber ist, dass ein 3D-Körper kein Volumen mehr hat, obwohl der Körper perfekt aussieht. Der Körper soll nicht geschlossen sein.
Solche Bugs bekomme ich dann, weil mich da durch beiße.
Die OpenGL-Visualisierung ist perfekt.
Also muss man die Konstruktion des 3D Körpers verfolgen und stellt dann fest, dass an einem Punkt eine Ordinate bei der 7. Stelle hinter'm Komma in einem speziellen Fall verrutscht, was den Körper an einer Stelle nicht sauber schließt, aber die Information geht bei der Visualisierung verloren, da OpenGL mit float arbeitet und wir mit double. Das ganze ergab sich, dass die Facette, die aus mehr als drei Punkten besteht, die nicht perfekt in einer Ebene lagen und die Ebene dann eben einen Punkt nicht mehr genau genug trifft. Der Körper besitzt damit einen minimalen Schlitz und ist daher fehlerhaft.
Die Daten sind von einer anderen Software importiert. Wir sind extrem genau, das Datenformat ist sehr lasch. Wir müssen quasi alles reparieren bzw. interpretieren.

Bugs der Art "Die Ergebnisse, die mir das Programm zurueckliefert sind irgendwie falsch", sind natuerlich enorm schwer zu finden, wenn sie ueberhaupt auffallen. Ich glaube gerne, dass Du da lange nach gesucht hast. Ich hatte mit solchen Problemen auch schon jede Menge Spass. Eigentlich ist das Debuggen solcher Bugs sogar enorm interessant. Ich habe bei mir gemerkt, dass ich dann teilweise richtig kreativ bei den Debugging-Techniken werde. Unter Umstaenden muss man den Fehler durch irgendwelche Zwischenergebnisse zurueckverfolgen, die man nur schwer interpretieren kann. Oder man hat es mit derart grossen Datenmengen zu tun, dass es schwer ist, die Natur des Fehlers darin ueberhaupt zu erkennen.

[Xin]

numLoc schrieb:

Ich habe erwartet, dass ich da morgens ins Büro kommen und Code wie ein irrer bis zum Abend runterkloppe. Anstelle dessen war ich viel mehr mit Analyse, Debuggen und Recherche beschäftigt.

Das entspricht etwa meiner Erfahrung. Bei mir auf'm Tisch landet gerne das Zeug, dass andere mit der Kneifzange nicht freiwillig anpacken.
Entwickeln ist aber oft zu großen Teilen recherchieren, analysieren, reverse engineering, testen und debuggen und anschließend Tests automatisieren, um die Qualität abzusichern.
Das eigentliche Entwickeln ist eher ein überschaubarer Bruchteil der Arbeit. Am Ende der Woche hat man eventuell nur zwei Variablen vertauscht.

Code runterkloppen macht sicherlich am meisten Spaß, aber das ist wie Tetris spielen. Je länger man spielt, desto wichtiger ist, dass man nicht einfach nur runterkloppt.

numLoc schrieb:

Ich habe mehr auf einem Blatt Papier mir die Zusammenhänge aufgezeichnet, als dass ich Code eingetippt habe. Beim Wochenmeeting musste ich Woche für Woche erzählen warum ich noch nicht weiter bin. Für die eigentliche Aufgabe wurde ein Tag angesetzt und nach 2 Monaten war ich erst fertig, weil ich überhaupt keine Ahnung von den ganzen Zusammenhängen und den Frameworks hatte. Die nächste Aufgabe hatte wieder mit einem anderen Framework und der Anpassung einer fremden Software zu tun, die ich auch nicht kannte, und da bin ich auch nicht mit fertig geworden.

Da darf man vielleicht auch mal Deinen Projektleiter fragen, ob er Dich entsprechend Deiner Fähigkeiten einsetzt.
Ich stünde auch wie ein Ochs vor einem Berg, wenn man mir ein unbekanntes Stück Code, ein unbekanntes Framework und eine Aufgabe vorsetzt und sagt 'Mach mal'.
Dann geht es eben genauso wieder los: recherchieren, analysieren, Zeichnungen machen...

numLoc schrieb:

Ich bin wohl zu dumm für den Job, da ich auch nicht studiert habe.

Das kann ich nicht beurteilen. Ich kann aber nachvollziehen, dass eine Aufgabe, die die eigenen Fähigkeiten übersteigt frustrierend sein kann. Als ich die 8 Wochen im Studium nach dem Bug gesucht habe, wollte ich wissen und verstehen, was ich da produziert habe, dass es mich so lange aufhalten kann. Diese Lehr-Zeit hätte ich einem Projektleiter, der mich dafür bezahlt, nicht erklären können. Dessen Job wäre dann gewesen, mir Unterstützung bereitzustellen, die mit mir das Problem löst. Nur hatte ich niemanden, der mich da unterstützen konnte.
Ich habe aber draus gelernt.

Wenn Dein Projektleiter Dich 8 Wochen an so einem Problem sitzen lässt, dann darfst Du auch fragen, ob diese Situation seine beste Möglichkeit ist, das Problem zu lösen.
Wenn Du also erklären musst, warum Du immernoch nicht fertig bist und Dein Projektleiter reagiert nicht, dann hat er entweder keine bessere Alternative oder trägt die Verantwortung dafür, dass Du keine Unterstützung bekommst.
Wenn Du nicht das Beste bist, dann darfst Du nach Unterstützung fragen, und damit den Projektleiter zu unterstützen, um die Sache im Sinne der Firma zu beschleunigen.
Und wenn Du das Beste bist, was Deine Firma dazu aufzubieten hat, dann bist Du der richtige Mann für den Job.
Die Koordinierung, also den richtigen Mann für den Job zu finden, ist aber eigentlich der Job des Projektleiters.

Ich habe 'Praktische Informatik' studiert, was sich am besten mit "Wir werfen Dich ins kalte Wasser und gucken mal, ob Du schwimmen kannst" übersetzen lässt. Das war genau das Studium: Schreiben Sie einen Linux-Treiber für diese PCI-Karte. Ich kann unter Linux den gcc aufrufen... aber PCI-Treiber?
Das ist offensichtlich auch Dein Berufsbild.

Ich habe nahezu jeden Bug gefixt, auch dann wenn neuschreiben schneller gewesen wäre, weil ich verstehen wollte, welcher Fehler mir nicht sofort ins Auge springt. Und das ist manchmal frustrierend, weil es einem immer wieder bewusst macht, dass man eben nicht so gut ist, wie man glaubt.
Lob ist selten. Das größte Lob ist quasi, dass man die Bugs bekommt, an denen sich andere die Zähne ausgebissen haben. In der Regel mit den Worten "Kannst Du mal eben drüber schauen?".

Entwickeln ist ein strategisches Knobelspiel: Zum einen braucht man eine Strategie, wie man möglichst wenig knobeln muss und wenn man knobeln muss, dann braucht man eine Strategie, wie man das Problem lösen kann...
Ein Studierter kann nicht alles. Er hat mit etwas Glück ein paar Strategien auf Lager und die Erfahrung, dass man auch schonmal 8 Wochen lang debuggen muss, um Erfolgreich zu sein, bzw. hat gelernt, sich nicht den Bug durch die Fehlerausgabe zu vernichten. ^^

[Gast]

@numLoc: Vielleicht suchst du dir eine größere Firma. Kleine Firmen können enorm undankbar sein und ihre Mitarbeiter regelrecht verheizen.
Deine Zweifel kennen wohl nicht wenige Entwickler!

PS: Vll. lernst du parallel noch, wie du dir das Leben als Entwickler einfacher machen kannst. D. h., TDD, Patterns etc.

L. G.,
IBV

[Marthog]

Gregor schrieb:

Kann man bei C++ nicht irgendwie automatisch zusätzliche Checks beim Kompilieren einbauen?

Clang kann das, aber bis Apple den mit Google entwickelt hat, haben sich kaum Compilerbauer und auch sonst keine Firma dafuer verantwortlich gefuehlt.

[großbuchstaben]

auch ganz nett sind bugs, die abhängig von äußeren Faktoren wie der Prozessorlast auftreten, also beispielsweise ein deadlock, der nur dann auftritt, wenn die Prozessorlast im Augenblick hoch genug ist, daß der zweite Thread ein paar Millisekunden länger zur Initialisierung braucht, sodaß er das Stop-Signal vom ersten nicht mehr mitbekommt. Wenn es in 95% der Fälle klappt, könnte es 20 Starts dauern, um überhaupt einmal den Fehlerzustand herzustellen.

[hustbaer]

@großbuchstaben
95%? Also 5% Chance den Fehler zu erwischen? Bei nem Deadlock? Optimist!
Spannend wirds mal wenn du unter 1% kommst. Und das ist nicht schwer/keine Seltenheit. Gerne auch mal < 10^-6.

[Mechanics]

Xin schrieb:

Code runterkloppen macht sicherlich am meisten Spaß

Ah, ich weiß nicht. Ich schreib zwar gern neuen Code, aber irgendwelche komischen Bugs untersuchen macht mir auch sehr viel Spass. Ist bei mir so ähnlich wie bei dir, mittlerweile landen viele schwierige Bugs erstmal bei mir zum Untersuchen.
Ich bin da auch sehr hartnäckig und finde sogar Bugs, die keinen interessieren. Hatte z.B. einmal einen Absturz bei mir, den noch nie jemand gemeldet hatte und der sonst niemandem aufgefallen war. War auch nicht reproduzierbar. Ist also vielleicht insgesamt nur ein einziges mal aufgetreten. Hab mir den Code aber so lange angeschaut, bis ich einen Bug gefunden habe, der zu dem Absturz führen konnte. Das Timing Verhalten war aber echt extrem unwahrscheinlich.

[MfG]

Mechanics schrieb:

Xin schrieb:

Code runterkloppen macht sicherlich am meisten Spaß

Ah, ich weiß nicht. Ich schreib zwar gern neuen Code, aber irgendwelche komischen Bugs untersuchen macht mir auch sehr viel Spass. Ist bei mir so ähnlich wie bei dir, mittlerweile landen viele schwierige Bugs erstmal bei mir zum Untersuchen.
Ich bin da auch sehr hartnäckig und finde sogar Bugs, die keinen interessieren. Hatte z.B. einmal einen Absturz bei mir, den noch nie jemand gemeldet hatte und der sonst niemandem aufgefallen war. War auch nicht reproduzierbar. Ist also vielleicht insgesamt nur ein einziges mal aufgetreten. Hab mir den Code aber so lange angeschaut, bis ich einen Bug gefunden habe, der zu dem Absturz führen konnte. Das Timing Verhalten war aber echt extrem unwahrscheinlich.

so sehe ich das auch, manchmal ist es auch mit einem enormen wissenszuwachs verbunden, solche fehler überhaupt erst einmal zu identifizieren...

aber wenn man einen solchen fehler gemacht hat und verbessert hat dann kann ich das auch ...
wie auch microsoft ceo nadella sagte: ... (bin eig kein ms fan)
http://www.heise.de/newsticker/meldung/Nadella-an-der-TU-Berlin-Macht-Fehler-und-lernt-daraus-2452852.html

"Macht Fehler und lernt daraus"

desweitern denke ich das man eine programmierer lieber daran festmachen sollte wie viele(oder wenig...) fehler er produziert...
weil mir bringen 50 zeilen code am tag nix... wenn der programmierer daran nochmal 4 tage bug fixing betreibt...
dann doch lieber gleich richtig und etwas weniger neu gecodet...

[Auskenner]

MfG schrieb:

desweitern denke ich das man eine programmierer lieber daran festmachen sollte wie viele(oder wenig...) fehler er produziert...

Sag ich doch.

[Xin]

Mechanics schrieb:

Xin schrieb:

Code runterkloppen macht sicherlich am meisten Spaß

Ah, ich weiß nicht. Ich schreib zwar gern neuen Code, aber irgendwelche komischen Bugs untersuchen macht mir auch sehr viel Spass. Ist bei mir so ähnlich wie bei dir, mittlerweile landen viele schwierige Bugs erstmal bei mir zum Untersuchen.

Ich mache meine Bugs aber lieber selbst. Darin bin ich aber schlecht, wenn ich im Jahr zwei Bugs bekomme, die ich selbst verschuldet habe, ist das viel. Die meisten Bugs, die ich "verschuldet" habe, bekomme ich deswegen, weil jemand ungefragt unfertige Software von mir abgreift und Features als fehlerhaft beschreibt, die ich noch gar nicht geschrieben habe. Da könnte ich auch 'nen Hals bekommen...

Debugging ist interessant und kann auch eine ganz neue Form von Kreativität bedeuten, aber ich muss auch klar sagen, dass ich den Job zur 3D-Visualisierung angenommen habe, weil ich mal wieder sehen wollte, was ich programmiere. Ich mache sonst Compilerbau und wenn Du zwei Wochen Zeit investiert hast, der Compiler fehlerfrei läuft und nichts meldet, dann ist das... ähh... ein tolles Erlebnis, aber

> gsys testprogramm.g
>

schaffen andere mit in wenigen Sekunden mit einem int main() {}. Du weißt, was da intern alles passiert ist, aber man kann es nicht mal jemandem zeigen, der keine Ahnung davon hat.

Ich war mal bei meinem neuem Chef und erklärte ihm, dass ich Low-Level-Programmierung mache. Danach musste ich ihn davon überzeugen, dass Low-Level nicht bedeutet, dass ich unfähig bin, weil auf geistig niedrigem Niveau arbeite, sondern eben die Grundlagen beschreibt auf dem alles andere aufbaut.
Das Problem hat unser GUI-Praktikant nicht. Der leistet ja was - sieht man doch, der macht viele tolle neue Dialoge, die man dem Kunden präsentieren kann.

Andere Programmierer lösen Probleme. Die Testbeispiele laufen, das sieht cool aus. Dann gibt's Applaus, dann kommen die Anwender, die ihre Probleme mit der Software lösen wollen. Dann haben wir einen Bug und der Entwickler gerade keine Zeit.
Wenn ich dann die halbverstandene, unkommentierte Lösung des anderen Entwickler nachvollziehe, dann das Problem des Kunden nachvollziehe und feststelle, dass das die Lösung leider nicht zum Problem passt, werfe ich diese weg und schreibe eine allgemein passende Lösung. Der erste Entwickler hat das Problem in 2 Tagen gelöst und ich habe einen kleinen Fehler in 2 Wochen behoben. In der Wirkung kann die Software jetzt nicht mehr als vorher, nur dass das Beispiel vom Kunden jetzt auch funktioniert und nicht nur die Testbeispiele.
Wenn man dann noch hört, dass die vorherige Lösung "aus dem Internet inspiriert" war, also auch nicht wirklich nachvollzogen wurde, sondern nur lauffähig gemacht wurde, dann nervt das schon etwas, weil der Kollege hat seine Show gehabt und ich habe ja nur einen kleinen Fehler für den Kunden behoben.

Debugging macht schon Spaß, aber gelegentlich will man auch sehen und zeigen, was man erschaffen hat. Und das funktioniert mit Debugging leider nicht.

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden. Und es ist einfach geiler, wenn man ein neues Feature sieht als wenn man für ein bereits verbuchtes Feature einen Bugfix macht.

MfG schrieb:

so sehe ich das auch, manchmal ist es auch mit einem enormen wissenszuwachs verbunden, solche fehler überhaupt erst einmal zu identifizieren...

Als ich C und C++-Tutor war, habe ich den Leuten immer wieder Aufgaben gegeben, bei denen sie mit Sicherheit in gemeine Fehler laufen und lies sie dann debuggen, Fragen stellen, nachvollziehen, was passiert und ihre Erwartungen zu formulieren und zu gucken, warum was passiert nicht ihren Erwartungen entspricht.

Ich habe den Leuten nicht beigebracht, wie man es richtig macht, sondern wie man es nicht falsch macht. Und dafür mussten sie es halt erstmal falsch machen, um dann zu lernen, warum das ihr Fehler nicht funktioniert.

Mit der Zeit fingen sie an, vor dem Tippen nachzudenken, wo sie in Fehler laufen können, denn irgendwann hatten sie raus, dass alle meine Aufgaben gemein sind. Da ich sie immer mit Ankündigung dumm dastehen lies, wollten sie mir ja zeigen, dass sie kleverer sind als meine Aufgabenstellungen. ^^

[Loading]

Xin schrieb:

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden.

Kannst du das etwas geneuer ausführen, wie kann man denn aufs Debuggen verzichten?

[Xin]

Loading schrieb:

Xin schrieb:

Privat entwickle ich ja auch. Da habe keine Zeit zum Debuggen, entsprechend habe ich meine Herangehensweise optimiert, um Debuggen zu vermeiden.

Kannst du das etwas geneuer ausführen, wie kann man denn aufs Debuggen verzichten?

Vermeiden, nicht verzichten - soweit bin ich dann doch noch nicht.

Debuggen vermeiden bedeutet Fehler vermeiden.
Und Fehler vermeiden bedeutet die Sprache voll auszunutzen: Const-Correctness, Templates, Mehrfachvererbung, viele bezeichnende Datentypen. Auch mal Zeit investieren, um einen neuen Datentyp (z.B. class Position) aus einem alten (unsigned int Position) herauszuholen, wenn man ihn häufiger braucht, statt hier und da ein paar ints reinzustreuen.
Und nachdenken, bevor man was tippt. Oder das tippen eben sein lassen, wenn man merkt, dass man nur Matsch in der Birne hat und in der Zeit halt eher Quelltext aufräumen und kommentieren, statt Fehler einbauen. Oder Tests schreiben. Jedenfalls nichts komplexes tun, was noch komplexer zu debuggen ist, falls es schief geht.

Es geht vorrangig darum, nicht den richtigen Zeitpunkt für eine Aufgabe zu verpassen, bzw. umgekehrt eine Aufgabe nicht zum falschen Zeitpunkt zu beginnen.

[Gregor]

Xin schrieb:

Und Fehler vermeiden bedeutet die Sprache voll auszunutzen

Unter Umständen kann es aber auch bedeuten, bewusst auf bestimmte Sprachmittel und Herangehensweisen, zu denen eine Sprache einlädt, zu verzichten.