Wie wird man ein besserer Programmierer?



  • 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.



  • Kurz zusammengefasst: Diejenigen Programmierer, die boost flüssig lesen können und hinterher ein Gedicht darüber schreiben!



  • Austeiger schrieb:

    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.

    fehler die durch unsauberen code entstehen und auch daraus folgernde schlechte wartbarkeit machen den code am ende teurer als wenn du gleich von vorneherein ordentlich entwickelst... !! ( google mal TDD - Test Driven Development , das ist genau das!! )

    und wnen dein chef selber entwickler ist dann sollte er die wichtigkeit /relevanz von guter codequalität zu schätzen wissen...

    ps. wenn die der code aufgrund von fehlender tests oder geringer code qualität "um die ohren fliegt" und dabei schaden entsteht...
    deine firma dann eine schadensersatzklage bekommt und dir nachgewiesen wird das es fahrlässig war um die produktionskosten zu senken... dann kannst auch dicht machen (in meinen augen auch 100% korrekt!! denn solche software möchte ich nicht nutzen und würde sie erst recht niemandem verkaufen... !! )

    aber wird schon gut laufen... tests und code qualität sind nur überflüssiger schnick schnack und am ende eh für niemanden interessant... ( und dann schaust du nach 4 jahren nochmal auf deinen code uns sollst das login verbessern, dann brauchst du 4 mal so viel zeit anstatt von vornerherein ordentlich wartbar zu coden... )



  • nachtrag:
    auch für andere programmierer ist es wesentlich angenehmer deinen code zulesen!! zu erweitern oder zuwarten...!!

    oder bei versionskontrollsystemen kannst du bei gewisser "schlechten" qualität nicht mal einchecken!... -> d.h dir bring funktionalität auch nix wenn der code quick & dirty ist...
    oder nicht einem vorher festgelegten min. standart entspricht...

    also für mich und bei mir ist codequalität wichtig und das finde ich auch zu 100% richtig!! (leider wird das viel zu wenig erst genommen !!)



  • Hyde++ schrieb:

    Meine Frage:
    Wie schafft man es, sich nicht endlos in Details zu versteigen, einfach mal was fertig machen und dabei trotzdem etwas halbwegs lesbares zu produzieren? Und zusaetzlich: Ist der Ansatz, wie ich es mache, eurer Meinung nach in Ordnung, oder wuerdet ihr das ganz anders machen?

    Vielen Dank fuer das Lesen von dich relativ viel Text!

    Details sind halt letzlich das, was einen guten Programmierer von einem sehr guten unterscheidet.

    Je komplexer das Programm, desto mehr Detailfragen müssen beachtet werden.
    Details lassen sich meiner Ansicht nach gut handeln, wenn man sie in der Planung kapseln kann.



  • Hyde++ schrieb:

    Hallo!

    Ich programmiere jetzt seit ein paar Jahren in C++, manchmal auch in C oder Lua.

    Ein paar Jahre am Stück, oder nur ab und zu mal C++?

    Hyde++ schrieb:

    Ich habe als Einstieg das Buch von Breymann gelesen, dann als Steigerung den Stroustroup.
    Anschliessend noch Effective C++, ein bisschen Boost (irgendein einfuehrendes Buch) und momentan lese ich das Buch ueber Designpatterns der GoF.
    Darueberhinaus lese ich hier auch schon eine Weile mit, ich wuerde daher sagen, dass ich die typischen Fallstricke kenne, weiss, dass man keine globalen Variablen nutzen sollte, kein rohes new, immer schoen RAII, kein std::endl usw.

    Wenns aber ans konkrete Programmieren geht, stehe ich immer auf dem Schlauch.

    Vom Lesen allein lernt man nicht viel, dss erkennt man dann daran, dass man die gelesenen Themen gar nicht so richtig einzusetzen weiß. Programmieren lernen tut man durch programmieren.


Anmelden zum Antworten