Frage von Loltana, 78

Woher merke ich dass ich gut programmieren kann?

Woher?

Expertenantwort
von TeeTier, Community-Experte für programmieren, 23

Vorweg: Das ist Definitions- oder Ansichtssache! :)

Allgemein könnte man so etwas ähnliches formulieren, wie:

Entweder wenn du dich beim Betrachten des Disassemblates darüber ärgerst, dass der Compiler deinen schönen Code schon wieder so ineffezient übersetzt hat und deine - händisch in Inline-Assembler geschriebene - Testalternative diesen Verdacht auch unter einem Profiler bestätigt. :)

Oder wenn "Scott Meyers" persönlich auf dich zu kommt, und dich um Erlaubnis bittet, deinen Code als Paradebeispiel für Eleganz in einem seiner Werke verwenden zu dürfen. :)

Meine persönliche Meinung sieht so aus:

(Achtung: jetzt wirds etwas philosophisch)

Vom Begriff "gut programmieren" würde ich mich verabschieden. Denn wenn du wirklich diesen Anspruch hast, wirst du ihn niemals befriedigen können. Und dein falsches Gefühl, dass du im Moment "gut programmieren" kannst, wird nur so lange anhalten, bis du etwas Neues lernst, und erkennen musst, dass du ja vorher wohl doch nicht sooo "gut" warst.

Das wiederholt sich dann für 10 bis 15 Jahre, bis das eigene Gehirn dann endlich irgendwann mal geschnallt hat, dass man nie "gut" sein wird, egal wie oft man diese Schleife durchläuft.

Allerdings wird man mit jedem mal "besser"! Und wenn dir das erst mal bewusst geworden ist, und du nicht mehr so häufig denkst, dass du jetzt "gut" bist, sondern dich stattdessen auf die zukünftig real erreichbaren "besser"-Level freust, und zwar ohne bewusst oder gar unbewusst den Anspruch "gut" zu haben, erst dann bist du auf dem besten Wege, ein "guter" Programmierer zu werden. Dass du dieses Ziel trotzdem nie erreichen wirst, spielt dann auch keine Rolle mehr. :)

Beachte bitte: Das heißt im Umkehrschluss nicht, dass du für immer "schlecht" programmieren wirst. Das Gegenteil von "gut" ist nämlich nicht "schlecht". :)

Ich habe noch nie einen "guten" Programmierer gesehen, viele "schlechte" und "bessere" hingegen schon. Allerdings je "besser", desto rarer.

Fazit: Anstatt hier also die Frage zu stellen, woran du erkennst, dass du "gut" bist, frage lieber danach, wie du "besser" werden kannst. :)

Das ist im wahrsten Sinne Stoff für eine andere Frage und würde hier den Rahmen sprengen. Der Vollständigkeit halber nur ein paar Stichworte, die dir sprachübergreifend grob ein Wegweiser sein sollen:

- Software-Architektur

- Sotware-Tests inkl. Mock-Objekten und Coverage

- Profiling inkl. Metriken

- Entwurfsmuster und Code-Smells

- Defensives Programmieren

Es gibt noch unendlich viel mehr, und die angerissenen Gebiete sind nur Oberkategorien von Oberkategorien. Vermutlich musst du pro einzelnem Punkt ca. zwei Jahre Lernzeit einplanen. Aber erstens lohnt sich das, und zweitens wirst du dadurch tatsächlich sogar deutlich "besser" werden.

Außerdem werden sich "bessere" Programmierer kaum Gedanken über die Syntax oder Sprachkonstrukte ihrer eingesetzten Sprachen machen, als viel mehr um teilweise trockenes (aber höchst interessantes) Drumherum.

Das ist so ähnlich, als wenn man bisher nur einfaches Rechnen in der Schule hatte, und plötzlich mit Hochschulmathematik konfrontiert wird. Auf einmal benutzt du gar keine Zahlen mehr, stattdessen überall nur noch Buchstaben aus aller Herren Länder, die durch Symbole zu größeren Objekten verbunden werden. Am Anfang mag das abschrecken, aber schon relativ schnell wirst du merken, wie "hammer geil" das Ganze im Vergleich zu dem ist, mit dem du dich früher beschäftigt hast.

In diesem Sinne: Viel Spaß beim "besser" werden! :)

Antwort
von Fireonic, 34

Ich denke, gutes Programmieren ist, wenn der Code funktioniert und du auch noch nach Wochen, ohne Kontakt mit ihm, oder andere, die ihn noch nie gesehen haben, auf Anhieb verstehst, was er tuen soll.

Antwort
von DontHaveAName, 45

Gut programmieren? Dafür muss man die Eigenschaften der Sprache drauf haben.

Das allein reicht aber immer noch nicht um eine gute Software zu schreiben.

Dazu gehören viel mehr Dinge. Und damit meine ich den ganzen Kram von Planung bis hin zur Implementierung der Software, sowie entsprechende Unittests usw. usf.

Man muss allgemein das ganze Werkzeug gut beherrschen um wirklich gut zu sein.

Kommentar von TeeTier ,

Wer seine Tests, nur auf Unittests beschränkt, der wird verdammt viele Fehler übersehen. Das ist vergleichbar mit früheren Regressionstests, die nach und nach durch Unittests ersetzt wurden, und daraufhin verdammt viele - bis dato unbekannte - Fehler zu Tage fördern.

Allein schon die Tatsache, dass viele Leute ihre Unittests ohne Analyse der Abdeckung laufen lassen, schwächt diese Art von Tests so massiv, dass sie teilweise sinnlos werden.

Ich sehe immer wieder Entwickler, die zum ersten mal ein Coverage-Tool einsetzen, und dann geschockt fragen: "Au weia, weniger als 50%???". :)

Das gleiche Verhalten sieht man auch bei Menschen, denen man erklärt, dass wenn als Ergebnis von foo() die Zahl 123 erwartet wird, und foo() tatsächlich 123 zurück liefert, es sich trotzdem um einen Fehler handeln kann, den man in dieser Form mit herkömmlichen Unittests eben nicht abfangen wird. (Klingt cool, oder? Da stellt man die bisherige Teststrategie schon in Frage.)

Setzt man dann entsprechende Testtechniken ein, die solch ein Verhalten berücksichtigen, findet man auf einmal überraschend viele Fehler, die vorher allesamt durchgerutscht sind. Wohlgemerkt auch bei 100% Unittest-Abdeckung. :)

Wie beim Computer: Der Schritt von Single- auf Multi-Core brachte große Performance-Gewinne (so wie Unittests plötzlich viele Fehler fanden) und danach gab es nochmal einen ähnlichen Effekt, als alle anfingen, ihre Festplatten durch SSDs zu ersetzen.

Beide Schritte waren riesig. Aber warum machen die meisten beim PC weiter, bleiben aber bei Unittests stehen? Es gibt enorm viele Fehler, die man mit anderen Techniken finden kann, bzw. finden wird! Und hat man damit erst mal angefangen, wird man nicht mehr zurück wollen. Ich spreche da aus Erfahrung. :)

Und dann kommt noch das große Thema Fuzzing hinzu, welches ich nur als Randnotiz erwähne ... Hand aufs Herz, wie viele Firmen entwickeln ihre Software so, dass sie leicht fuzzbar ist, und integrieren diese Funktionalität auch in ihre Testserver? Das tun die wenigsten. :)

So wie man Regressionstests nur dann alleinig einsetzen sollte, wenn man a) mit Legacy-Code zu tun hat, und b) das Budget zu knapp für vernünftiges Refactoring kalkuliert ist, sollte man ausschließlich Unittests nur dann einsetzen, wenn Punkt b) zutrifft.

"Testen" ist eine Kunst, und das "Unit" hat im Namen erst mal überhaupt nichts zu suchen, da die eigentlichen Unittests ja nur einen Teil vom ganzen Prozedere ausmachen.

Aber zugegeben, da fast alle Entwickler auf Unittests fokussiert sind, ist die Anzahl der Tools, die tatsächlich mehr können, leider (noch) sehr übersichtlich. Momentan kommt man leider nicht drum herum, sich seine eigenen Testframeworks und Tools zu bauen, auch wenn es da gerade im letzten Jahr bei vielen Projekten Aufwind gab.

Aber wer denkt, JUnit, NUnit, unittest, test/unit und Konsorten reichen aus, der sollte wirklich ganz dringend eine Weiterbildung machen oder Fachliteratur konsumieren. :)

Antwort
von maxi1202, 51

Das du alle aufgaben die du bekommst bewältigst 

Antwort
von 1234567890PH, 44

Indem du alles in guter Laufzeit und übersichtlich scheibst ^^

Keine passende Antwort gefunden?

Fragen Sie die Community

Weitere Fragen mit Antworten