Wie wird man ein besserer Programmierer?



  • Mfg schrieb:

    - vll ne blöde frage aber warum kein std::endl?

    Naja, das war nur ein random Beispiel. Ich meinte, kein std::endl, wenn '\n' gemeint ist. Eben eine typische Anfaengersache.

    Mfg schrieb:

    - hab eben noch gesehen... du hast i.wie keine fehlerbehandlung wenn ich es richtig gesehen habe... (bin mir nicht ganz sicher)
    also bei if(!std::cin){break;} geht das prog. aus aber keiner weiß warum?
    - ist vll nicht schön aber da kannst auch einfach nochn text ausgeben oder sowas... 😃

    Da das ein Kommandozeilenprogramm werden soll, wird das Programm durch eingeben eines end-of-file (ctrl-D bzw. ctrl-z) beendet, das ist ein featuer 😉

    Vielen Dank fuer deine Antwort, aber das hilft mir nicht wirklich weiter. Mal davon abgesehen, dass ich das bewusst nicht als GUI auslegen moechte, deshalb also auch kein QT nutzen werde, ist der Rest etwas allgemein gehalten.
    Klar, ich denke auch darueber nach, was ich brauche, mache mir auch mal Struktogramme oder so was, wobei ich damit noch nicht so wirklich produktiv war.
    Ich dachte, moeglicherweise kann ich mir ein paar Tipps von erfahrenen Programmieren abholen, die dieses Problem kennen und gut verstehen. Dabei ist es verstaendlicherweise nicht einfach, das nicht zu theoretisch zu halten. Vielleicht kennt jemand ja auch ein fuer die Praxis ausgelegtes Buch oder ein gut dokumentiertes kleines Projekt, am besten mit einer dokumentierten Herangehensweise/Strategie.

    Auch der Blick in Open-Source-Projekte ist eher ernuechternd. Da wird doch haeufig genau das gemacht, von dem einem alle abraten (z.B. 40 globale Variablen verwenden).



  • @MfG: War das Fullquote denn nötig?



  • Hyde++ schrieb:

    Mfg schrieb:

    - vll ne blöde frage aber warum kein std::endl?

    Naja, das war nur ein random Beispiel. Ich meinte, kein std::endl, wenn '\n' gemeint ist. Eben eine typische Anfaengersache.

    Mfg schrieb:

    - hab eben noch gesehen... du hast i.wie keine fehlerbehandlung wenn ich es richtig gesehen habe... (bin mir nicht ganz sicher)
    also bei if(!std::cin){break;} geht das prog. aus aber keiner weiß warum?
    - ist vll nicht schön aber da kannst auch einfach nochn text ausgeben oder sowas... 😃

    Da das ein Kommandozeilenprogramm werden soll, wird das Programm durch eingeben eines end-of-file (ctrl-D bzw. ctrl-z) beendet, das ist ein featuer 😉

    Vielen Dank fuer deine Antwort, aber das hilft mir nicht wirklich weiter. Mal davon abgesehen, dass ich das bewusst nicht als GUI auslegen moechte, deshalb also auch kein QT nutzen werde, ist der Rest etwas allgemein gehalten.
    Klar, ich denke auch darueber nach, was ich brauche, mache mir auch mal Struktogramme oder so was, wobei ich damit noch nicht so wirklich produktiv war.
    Ich dachte, moeglicherweise kann ich mir ein paar Tipps von erfahrenen Programmieren abholen, die dieses Problem kennen und gut verstehen. Dabei ist es verstaendlicherweise nicht einfach, das nicht zu theoretisch zu halten. Vielleicht kennt jemand ja auch ein fuer die Praxis ausgelegtes Buch oder ein gut dokumentiertes kleines Projekt, am besten mit einer dokumentierten Herangehensweise/Strategie.

    Auch der Blick in Open-Source-Projekte ist eher ernuechternd. Da wird doch haeufig genau das gemacht, von dem einem alle abraten (z.B. 40 globale Variablen verwenden).

    - ach so...
    - joa man sollte kein std::endl anstatt \n nutzen , aber das ist doch auch allgemein?

    - naja eig sind diese "herangehsweisen" PAPs und alles mögliche was es da noch so gibt... -> ansonsten gibt es noch generell Entwicklungsmethoden (z.B. Scrum etc... )
    - eig machst du ja solche "vorüberlegungen" um "produktiver" zu sein... bzw. schneller zu coden und die Probleme schonmal vorher zu durch denken um später nicht erst auf probleme zu stoßen...

    - ist nat. etwas allgemein... aber ich hab keine zeit deinen code jetzt zeile für zeile durch zu gehen(hab ich oben auch geschrieben...) und dir dann alle schönheits markel aufzuzeigen (sofern überhaupt welche vorhanden)...

    - eigentlich hast du bei OpenSource eine Qualitätskontrolle... die lässt dich gar nicht "einchecken" wenns nich passt... außerdem achten die entwickler auch untereinander auf code-qualität... (gibt sicherlich auch ausnahmen) 😮

    - normalerweise werden dort außer es muss unbedingt sein keine globalenvariablen genutzt... und vom code-stil und so etwas ist opensource schon sehr gut... 🙄
    welches projekt /-e hast du dir angeschaut?

    - es gibt auch fälle da kann/sollte man globalevariablen nutzen(z.B. int _CRT_glob für Globbing einstellungen bei MinGW) ... 🙄

    - ok wenn es gezielt als konsolenanwendung gewünscht war ist ja ok...
    - wollte nur sagen das es mit den qt-klassen (gibts auch für konsolenanwendungen) evt. einfacher geht(schon vorhandene klassen, methoden gibt) und somit der code etwas kürzer wird... (was die leserlichkeit und wartbarkeit erhöht...) 🙄

    - und jetzt mal ganz blöd gefragt: warum willst du eig nicht eine schöne tabellenansicht, deiner Daten wenn du ein programm baust mit dem du listen verwaltest/bearbeitest oder einfach ausgibst? 😕

    na ja egal... ist nicht meine baustelle... 🙄



  • Sich endlos in Details zu verlieren ist häufig ein Zeichen dafür, das man das Problem und die Tools die man verwendet, doch noch nicht so richtig verstanden hat. Haufig hilft es einfach einen Schritt zurück zu gehen, Grundlagen zu lernen und sich nur darauf zu konzentrieren was man auch verstanden hat.

    Ansonsten spielt natürlich die Erfahrung immer eine große Rolle.



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


Anmelden zum Antworten