Wie wird man ein besserer Programmierer?
-
oenone schrieb:
@MfG: War das Fullquote denn nötig?
Ich wollte auch grad schreiben "Fullquote FTW!!!
".
Naja gut. Jetzt hab' ich's ja geschrieben
-
Hyde++ schrieb:
Wie schafft man es, sich nicht endlos in Details zu versteigen, einfach mal was fertig machen und dabei trotzdem etwas halbwegs lesbares zu produzieren?
Das funktioniert zwar nicht immer, aber ich versteigere mich auch ziemlich selten in irgendwelche Details. Zum einen "braucht" man dafür Erfahrung. Ich habe einfach schon einen gewissen Stil und muss bei Kleinigkeiten nicht lang überlegen, wie ich das mache. Brauchen hab ich jetzt in Anführungszeichen geschrieben, weil das jetzt nicht heißt, dass man mit Erfahrung automatisch besseren Code schreibt. Ich weiß durchaus, dass mein Code meist bei weitem nicht optimal ist. Ich könnte mir gut vorstellen, dass mir die Lösung anderer Entwickler desselben Problems besser gefallen würde. Nur ist es auch so, dass ich meine Lösung auch eben gut genug finde und kein Bedürfnis empfinde, an denen ewig rumzufeilen. Und ich weiß aus Erfahrung auch, dass mein Code meist schon ganz brauchbar ist.
Zum anderen interessieren mich Details mittlerweile auch weniger, als das große Ganze. Ich hab meist keine "Projekte" (zumindest das, was ich als Projekt bezeichnen würde, irgendwelche Kleinigkeiten zwischendurch muss man natürlich ständig machen), bei denen es um paar Klassen geht. Meist sind es größere Module, und da interessiert mich die Architektur mehr als Details. Ob eine Klasse dann perfekt ausgearbeitet ist, ist im Gesamtkonzept für mich meist irrelevant.
-
Mechanics schrieb:
und da interessiert mich die Architektur mehr als Details. Ob eine Klasse dann perfekt ausgearbeitet ist, ist im Gesamtkonzept für mich meist irrelevant.
finden Deine Auftrag-/Arbeitgeber das auch?
-
großbuchstaben schrieb:
Mechanics schrieb:
und da interessiert mich die Architektur mehr als Details. Ob eine Klasse dann perfekt ausgearbeitet ist, ist im Gesamtkonzept für mich meist irrelevant.
finden Deine Auftrag-/Arbeitgeber das auch?
Natürlich, die interessiert Details sowieso nicht. Für die ist das Gesamtkonzept sowieso viel wichtiger. Da geht es mehr um solche Punkte wie, wie gut skaliert das ganze, wenn man mit sehr vielen Daten umgehen muss, kommt das System mit mehreren Benutzern zu Recht, wie stabil und fehlertolerant ist es, wie gut ist es wartbar, wie schnell kann man neue Anforderungen umsetzen usw.
Außerdem hab ich nie behauptet, dass die Details bei mir "schlecht" wären. Das würde fast automatisch dazu führen, dass das Gesamtsystem weniger stabil und wartbar wäre.
-
@Hyde: Es gibt bestimmt noch Dinge an deinem Code zu verbessern, aber das gibt es immer. Für mich sieht das so aus, als hättest du die Grundlagen sehr gut verstanden und leidest eher an analysis paralysis, also genau das Gegenteil von dem, was viele andere machen, nämlich einfach irgendwelchen Frickelcode rauszuhauen und nie auch nur drüber nachzudenken, wie man es sauberer lösen könnte.
Also ich könnte mir vorstellen, dass es dich weiter bringt, einfach mal ein paar größere Projekte fertigzustellen auch wenn der Code nicht perfekt ist. Manchmal ist es vernünftiger eine doofe Stelle im Code zu haben, die einem später eventuell Ärger für ein paar Tage macht als mit dem release wochenlang nicht voran zu kommen, bzw. irre Template-Akrobatik zu machen, nur um wirklich 100%ig DRY zu sein.
-
Hallo,
lass dich von diesem Forum nicht abschrecken
In der Industrie habe ich einen interessanten Effekt festgestellt:
da gibts Leute, die liefern echt miesen Code ab. Der macht Probleme, und da muss man auch nichts dazu sagen.
Dann gibt es Leute, die verbringen Stunden und Tage nur um ein total simples Problem zu lösen, dafür ist der Code perfekt. Alles durchdacht, zig Templates sodass alles generisch ist. Teilweise ist der Code aber auch recht kompliziert, sodass andere sich damit schwertun.
Und dann gibt es die wirklich produktiven Leute, die auch guten Code abliefern, sich dabei aber aufs Wesentliche konzentrieren. Die verwenden die praktischen Dinge von C++ wie RAII, Containerklassen, ...Ich kann dir nur empfehlen zu versuchen, C++ als Werkzeug zu sehen und dir ein paar praktische Dinge rauszusuchen die dir bei der Arbeit helfen. Dann nämlich bist du produktiv.
Wenn du Spaß daran hast, deinen Code bis ins Unendliche zu perfektionieren, kannst du das natürlich auch gerne machen. Zumindest als Hobby.
-
fdsfsdfsf schrieb:
Ich kann dir nur empfehlen zu versuchen, C++ als Werkzeug zu sehen und dir ein paar praktische Dinge rauszusuchen die dir bei der Arbeit helfen. Dann nämlich bist du produktiv.
Dem ist wenig hinzuzusetzen.Ein besserer Programmierer verwendet allein jene Dinge, die er voll beherrscht und
eignet sich jene Dinge an, die er noch nicht voll beherrscht. Ansonsten steht immer
die nachvollziehbare Realisierung einer Aufgabe im Vordergrund, die auch von anderen
verstanden werden muss, also wartbar ist.
-
das hab ich doch schon gesagt!
-
Vielen Dank fuer die Antworten, ich werde versuchen, die Tips umzusetzen.
-
Nach 15 Jahren Erfahrung als Software-Entwickler kann ich nur sagen, dass beim Löwenanteil der Projekte, an denen ich mitgearbeitet habe, eben nur am Anfang etwas geplant wurden. Dann wechselten die Mitarbeiter, der Zeitdruck wurde größer und so weiter und so fort. Unter dem Strich muss eine Funktionalität in erster Linie fertig werden, ob es schöner Code ist ist in den allermeisten Fällen total unwichtig. Zeit für Planung, Testen usw vom Arbeitgeber zu bekommen ist nur in gewissen Maßen in Zeiten möglich wo nicht viel los ist.
Schönen Code habe ich eigentlich nur privat und mit viel Zeit geschrieben. In der Praxis habe ich mich dem Codestil des Projektes versucht anzupassen und halt gesehen dass es irgendwie fertig wird. Die meiste Zeit ging immer dafür drauf überhaupt herauszufinden wie der Programmcode was macht. Oft gab es eine Doku, die mal Anfang gepflegt wurde, aber dann irgendwann, wieder aus Zeitnot, nur stiefmütterlich weitergeführt wurde. Dann hatte ich Projekte wo ich gar nichts hatte- Nicht mal einen technischen Ansprechpartner, der war nämlich von heute auf morgen ich dann.
Ich habe immer nur davon gehört, dass es Firmen gibt die wirkliche Software-Entwicklung, wie aus den Fachbüchern, betreiben. Persönlich gesehen habe ich so etwas noch nie.
Was solls, ich bin persönlich aus der Branche ausgestiegen, habe jetzt viel viel Freizeit und programmiere nur noch für mich. Ob ich je wieder als Software-Entwickler arbeiten will, ist fraglich. Es gibt einfach Stress, den muss ich nicht haben.
-
Aussteiger schrieb:
Was solls, ich bin persönlich aus der Branche ausgestiegen, habe jetzt viel viel Freizeit und programmiere nur noch für mich. Ob ich je wieder als Software-Entwickler arbeiten will, ist fraglich. Es gibt einfach Stress, den muss ich nicht haben.
Interessenfrage: Was machst du jetzt?
-
Erstmal ein Jahr Pause von allem mit Therapie zur Stressbewältigung und dann wahrscheinlich eine Berufsreha, wenn das nicht klappt dann Frührente. Also entweder anderen Job, oder gar nicht mehr arbeiten und den Rest meines Lebens das machen was mich interessiert. Geld ist kein Thema, ich brauche nicht viel.
-
Aussteiger schrieb:
Unter dem Strich muss eine Funktionalität in erster Linie fertig werden, ob es schöner Code ist ist in den allermeisten Fällen total unwichtig.
Ja, aber die Kunst dabei ist, trotzdem "fast" schönen Code abzuliefern. Mit etwas Erfahrung gelingt das auch ziemlich oft. Wenn man seinen eigenen Stil entwickelt hat, tüftelt man nicht mehr stundenlang jede Klasse aus. Und für Architekturüberlegungen kann man sich die Zeit meist schon nehmen. Vielleicht nicht immer so viel, wie man gern hätte, aber ich habs jedenfalls noch nie erlebt, dass ich selbst oder andere etwas total vermurkstes abliefern mussten, nur weil die Zeit für Planungen nicht gereicht hätte. Eher reicht die Zeit für die Implementierung, Feintuning und Tests nicht.
-
Ja klar, versucht man sein bestes, aber der Kunde zahlt nun einmal nicht für schönen Code, der ist nur da damit wir besser mit zurecht kommen können. Wenn der Chef Planung, Test, schönen Code und Doku mit in die Kostenkalkulation einbringen würde, dann könnten die meisten ihre Firma einfach dicht machen. Das sollte nicht so sein, ist aber leider oft so. Na jedenfalls war es in der vier Firmen, in denen ich gearbeitet, hatte so. Mal mehr mal weniger stark ausgeprägt. Was anderes ist es, wenn man an hauseigenen Produkten arbeitet, die über Jahre wachsen. Und nochmal anderes ist es, wenn der Chef selbst Entwickler ist.
-
Austeiger schrieb:
der Kunde zahlt nun einmal nicht für schönen Code, der ist nur da damit wir besser mit zurecht kommen können.
Und wenn wir besser zurecht kommen, brauchen wir langfristig weniger Zeit, und senken somit die Gesamtkosten, vorausgesetzt natürlich die Schöncoderei wird nicht übertrieben.
Doof ist natürlich wenn die Verschönerung auf unbestimmte Zeit verschoben und dann nie gemacht wird. Dann wirds teuer und nervig.
Es tut mir natürlich leid wenn jemand (wie du zb, so wie es aussieht) hauptsächlich sowas erlebt hat.
-
Ja, so ähnlich habe ich es auch immer versucht den Chefs zu verkaufen. Die Antwort war dann: "Entweder so, oder wir machen bald dicht." Ja, schade, dass ich nicht anderes Arbeiten kennen gelernt habe, aber nun bin ich so ziemlich endgültig raus aus dem Bereich, jedenfalls beruflich. Die Jahre haben mich einfach fertig gemacht und meiner Gesundheit sehr geschadet. Ich hoffe, ich kann überhaupt noch mal arbeiten gehen, man wird sehen, ich arbeite auf jeden Fall dran.
-
Dass du sowas wie "Ich arbeite dran." schreibst, erweckt bei mir den Eindruck, dass du es schaffen wirst.
-
Austeiger schrieb:
Was anderes ist es, wenn man an hauseigenen Produkten arbeitet, die über Jahre wachsen.
Ist bei uns gemischt. Ist zwar unser eigenes Produkt, das über die Jahre gewachsen ist, aber es ist nicht für Endkunden sondern für große Firmen und wir orientieren uns natürlich hauptsächlich daran, was die Kunden wollen.
Meist geht es auch nicht anders, als Prototypen rauszugeben. Viele unserer Funktionen wachsen sehr stark mit der Zeit. Wenn wir eine Idee haben oder eine Idee von einem Kunden bekommen, ist es oft so, dass es viele Jahre dauern würde, diese Idee komplett umzusetzen, und dabei wären die Anforderungen noch gar nicht so wirklich klar. Deswegen machen wir meist eine überschaubare Basisversion, die einbisschen was kann und mit der man zeigen kann, in welche Richtung es geht, mit der man aber auch arbeiten kann. Kann sein, dass es eh nicht ankommt, dann wirds wieder eingestampft. Aber wenn das ankommt, dann kommen oft ziemlich unterschiedliche Ideen und Anforderungen von 20-30 verschiedenen Kunden und dann ist schon viel eher klar, wie sich das Produkt entwickeln wird. Würde aber natürlich trotzdem sehr lange dauern, das alles umzusetzen. Deswegen wird meist ein neuer Milestone definiert, der die wichtigsten Anforderungen umfasst und dann wird er released. Und dann gehts so weiter und nach und nach kommen mehr Features hinzu, es wird schneller, stabiler usw.
Kann natürlich passieren, dass man nach drei Jahren sagt, so wie wir vor drei Jahren angefangen haben wird es nichts mehr, die Struktur passt nicht mehr zu dem, was wir aktuell machen. Das sieht der Chef dann schon ein, wenn wir sagen, das passt alles nicht mehr, müssen wir von Grund auf neuschreiben. Da ist es aber auch gut, dass wir ganz am Anfang nicht ewig viel Zeit in Planungen reingesteckt haben, weil die Enwicklungen wären nicht abzusehen gewesen.
-
Ich hab hier ein hauseigenes Produkt an dem ich arbeite, das über einen Zeitraum von ca. 10 Jahren sukzessive zerstückelt und vernichtet wurde.
Genau nach der Masche "das muss schneller gehen, sonst können wir bald zusperren".
Soviel dazu.ps.: Ich würde mich auch nicht trauen da ein allgemeines Statement abzugeben. Also wo mehr gepfuscht wird, bei Auftrgsarbeiten oder bei Eigenentwicklungen. Klar, bei Eigenentwicklungen könnte der Gedanke "wir müssen mit dem Code vermutlich lange leben/den Code lange warten" helfen. Funktioniert aber halt nur wenn der Entwicklungsleiter es einsieht und auch die Eier hat das gegenüber dem Chef zu verteidigen. Dafür könnte bei Auftragsarbeiten der Gedanke "der Kunde könnte da drübergucken, und wenn es das totale Chaos ist dann reisst er uns vermutlich den Kopf ab (oder zahlt einfach nicht)" helfen. Was schwerer wiegt trau ich mich nicht schätzen.
-
Aussteiger schrieb:
Unter dem Strich muss eine Funktionalität in erster Linie fertig werden, ob es schöner Code ist ist in den allermeisten Fällen total unwichtig.
Ergibt bis zu einem gewissen Maß auch Sinn.
Ich persönlich mag schönen Code sehr und unternehme wenn Zeit ist Anstrengungen in der Hinsicht, aber das darf nicht in Fluff, Bloat, Ineffizienz, Code-Bürokratie und Dogmatik ausarten, und ich ertappe mich zumindest dabei dass das dazu ausartet.
Ich sehe in der OOP Welt leider sehr viel davon, auch in C++ aber vor allem jenseits davon (Java, C#)Meiner Erfahrung nach gibt es keinen Ersatz dafür, das ein Programmierer Code 100% vor dem Mentalen Auge hat, Struktur und Architektur intuitiv versteht und ihr zu jeder Zeit gewahr ist, auch um 3 Uhr nachts wenn du ihn weckst.
Anders gesagt - und das mag trivial klingen, ist es aber nicht - es gibt keinen Ersatz für Programmirer die Code einfach checken. Die schreiben keinen bloat und sind nicht dogmatisch. Die verstehen code ob er nun schön und formell/den Konventionen nach korrekt geschrieben ist oder nicht, ob er dicht ist oder hübschifiziert, ob die Namen sprechen oder aus 3-7 Buchstaben bestehen, ob drei Sterne oder Referenzen - und ob nun gut Dokumentiert oder nicht.
Diese Programmierer sind die besten.
