Hallo Leute! Ich habe eine zusage für einen Job als Softwareentwickler, ich bin allerdings sehr aufgeregt wegen des Berufsstarts. Ich habe schon Software entwickelt, allerdings hauptsächlich für die Konsole. Grafisch ganz wenig. Jetzt hab ich mir ein Buch zum Thema gekauft und ich fühle mich nicht in der Lage dazu, das zu liefern was der Arbeitgeber möchte. Ich habe alles wahrheitsgemäß erklärt im BG, also nicht das Blaue vom Himmel versprochen. Es geht hierbei um C++. Objektorientierung habe ich schon benutzt und auch Polymorphie. Allerdings sagen mir die modernen Sprachkonstrukte wie Smart-Pointer, Templates usw. nur relativ bedingt etwas. Aus der STL kenne ich nur vector als Container, map usw. habe ich nie benutzt... Der AG sagt, dass man das lernen kann, Hauptsache Interesse und technisches Verständnis ist vorhanden. (Bin ursprünglich Techniker). Allerdings möchte ich ungern während der Probezeit rausgeschmissen werden. Und jetzt das schwierigste. Ich beschäftige mich jetzt vorbereitend einen Monat mit der Sprache, aber ich kriege es einfach nicht hin ein Programm zu schreiben, das den SOLID-Kriterien entspricht. Ich wollte eine relationale Datenbank bauen und Adressen darin speichern. Dazu Modernes C++ benutzen und nach SOLID... ich muss zugeben, ich bin gescheitert, würde es aber gerne lernen. Gibt es hier jemanden, der mir dabei didaktisch weiterhelfen kann und ein paar Tipps hat?
Total geile Idee sowas, das sichert den Profis die Jobs, die hinterher den Schaden reparieren und die Bugs fixen müssen!
Ben B. schrieb: > das sichert den Profis die Jobs, die hinterher > den Schaden reparieren und die Bugs fixen müssen! Zum Glück wurdest du als Experte geboren.
Tiefsetzsteller schrieb: > Smart-Pointer, > Templates usw. nur relativ bedingt etwas. Aus der STL kenne ich nur > vector als Container, map usw. habe ich nie benutzt... Der AG sagt, dass > man das lernen kann, Hauptsache Interesse und technisches Verständnis > ist vorhanden. (Bin ursprünglich Techniker). Allerdings möchte ich > ungern während der Probezeit rausgeschmissen werden. Templates anschauen - oder erkläre was du daran nicht verstehst die STL basiert so ziemlich 99.89891% darauf - ohne Template-Grundkenntnisse geht es nicht Container: std::vector, std::map sind erst mal wichtig - es gibt noch viele andere Container aber das wirst du mehr oder minder in jeder C++/STL Software finden, einfach anschauen was die können und ein bisschen auswendig lernen - du merkst schon das dir die Container was bringen wenn du entsprechende Anforderungen hast Algorithmen: das Iteratoren-Konzept ein bisschen anschauen später dann <algorithm> aber das ist auch nicht so das damit jeder Entwickler arbeitet
Rom wurde nicht an einem Tag erbaut. Für gute Programme braucht man Übung, Übung und Übung. Da ist ein Monat zu kurz für. Und da ich aus dem Post nicht erkenne, woran du gescheitert bist, kann ich auch keine konkreten Tips geben. Also musst du für dich deine erkannten Probleme analysieren und verbessern.
Vielen Dank an diejenigen, die Helfen! @PittyJ Erstmal würde mich interessieren, wie man am besten dabei vor geht. Nutzt mal UML-Diagramme um erstmal die Rel.-Datenbank zu bauen? Sagen wir mal, die Datenbank steht, wie arbeitet man heutzutage? Ich überlege das im Bezug zur Programmgeschwindigkeit. Ich habe gelesen, dass oft beim Programmstart alles aus der Datenbank in eine map geladen wird, um während der Benutzung der Software Wartezeiten und Ruckler zu vermeiden. Ist das korrekt? (Lesen der Adresseinträge) Ist des dann im Umkehrschluss so, dass man eine map befüllt um beim beenden des Programms erst die Daten in die Datenbank schreibt? Was ist der Standard heutzutage? Ihr merkt hoffentlich, dass ich ein gewissen Verständnis für Software habe. Allerdings fehlt mir die Übung und ich möchte mir einfach nichts Schlechtes/Falsches antrainieren bzw. schlechten Stil.
Tiefsetzsteller schrieb: > Ich habe gelesen, > dass oft beim Programmstart alles aus der Datenbank in eine map geladen > wird, um während der Benutzung der Software Wartezeiten und Ruckler zu > vermeiden. Ist das korrekt? (Lesen der Adresseinträge) Das ist so pauschal gesagt sicherlich falsch. Man kann Teile der Datenbank im Speicher behalten, wenn das hier und da Vorteile bietet. Allerdings haben die gängigen Datenbanken schon viele Optimierungen drin, sodass das nur im Ausnahmefall notwendig ist. Premature optimization is the root of all evil.
MaWin schrieb: > Das ist so pauschal gesagt sicherlich falsch. > Man kann Teile der Datenbank im Speicher behalten, wenn das hier und da > Vorteile bietet. > Allerdings haben die gängigen Datenbanken schon viele Optimierungen > drin, sodass das nur im Ausnahmefall notwendig ist. > > Premature optimization is the root of all evil. Ja gut, ok. Kannst du das bitte weiter ausführen oder hast du eine Quelle zum nachlesen für mich? Ein How to Programmaufbau o.ä? Tutorial? Ich bin auch gerne bereit den ein oder anderen Euro für ein gutes Tutorial zu bezahlen! (Buch hat schon 40€ gekostet, Handbuch C++ 20 Torsten T. Will). Aber ich vertraue den Bewertungen von bspw. Udemy nicht! Danke.
Tiefsetzsteller schrieb: > > Sagen wir mal, die Datenbank steht, wie arbeitet man heutzutage? Ich > überlege das im Bezug zur Programmgeschwindigkeit. Ich habe gelesen, > dass oft beim Programmstart alles aus der Datenbank in eine map geladen > wird, um während der Benutzung der Software Wartezeiten und Ruckler zu > vermeiden. Ist das korrekt? (Lesen der Adresseinträge) > .. du machst Dir jetzt schon Gedanken zu Geschwindigkeit ? Fang klein an. Generell muss so ein DB-Backend ja CRUD unterstützen. Also C = Create new Entry R = Read Data , Select ... U = Update Data D = Delete Entry und bevor das geht , steht ja erstmal der Connect zur DB, hierfür brauchts Credentials, HostIp , User , Passwort , DB-Name die z.B. aus einem Konfig-File kommen. Damit fängst Du an 1. Konfig lesen 2. DB-Connect 3. Close Connect. Dann geht es an die Funktionen , da fängst Du bei Create.. an. Ich denke da hast Du Weihnachten über erstmal zu tun.. Evtl. möchte man die DB ja auch gleich erzeugen, falls sie noch nicht existiert,und ein paas Indices sind evtl. auch nicht verkehrt... Erstmal ein bisschen grober anfangen und dann immer mehr ins Detail gehen, zumindest am Anfang, wenn man so etwas bisher noch gar nicht gemacht hat. Gruß Ingo
:
Bearbeitet durch User
Tiefsetzsteller schrieb: > Kannst du das bitte weiter ausführen oder hast du eine > Quelle zum nachlesen für mich? Ein How to Programmaufbau o.ä? SW-Entwicklung ist mehr als das Herunterbeten von Paradigmen. Man kann kein Buch oder HowTo schreiben, in dem die richtige Art und Weise mit Datenbanken umzugehen beschrieben ist, weil es eben nicht die richtige Art und Weise gibt. Wenn du irgendwas mit Datenbanken machen willst, fang einfach damit an. Wenn du dann merkst, dass es zu langsam ist, dann ist der richtige Zeitpunkt über Optimierungen nachzudenken. Es gibt nur einen einzigen Weg SW-Entwicklung zu lernen: Man macht es. Und man macht Fehler. Und dann verbessert man die Fehler. Goto 1.
UML Diagramme nutze ich gar nicht. Dazu habe im im Embedded-Bereich einfach zu wenig Nutzen davon. Meist reichen State-Machine Diagramme bei meinem Anwendungen. Meine DB sind meist klein. Im Studium hatte man Übungen wie man die Normalformen erstellt. https://de.wikipedia.org/wiki/Normalisierung_(Datenbank) Bei meinen kleinen DBs ist das vollkommen überzogen, da reicht ein einfaches 'Design nach Gefühl'. (sind nur 2 Tabellen) Aber vielleicht wäre für dich ein Buch zur Datenbank-Theorie ganz nützlich. Ich lade nie alles, eher im Gegenteil. Nur wenn man etwas braucht. Zumal die DB auch parallel läuft, ein anderer Prozess kann etwas hinein schreiben. Von daher ist das komplette Laden am Anfang bei mir nicht gut. Also, da sind schon so viele Fazetten, die man erst im Lauf des Lebens kennenlernt. Und jede Anforderung ist anders. Kommt immer darauf an, was das System nachher machen soll. Optimiert wird erst ganz am Schluss. Wenn klar ist, was evtl zu langsam läuft.
Danke dafür erstmal! Über Gespräche und andere Forenbeiträge, hatte ich den Eindruck bekommen, dass Code und Datenbanken eigentlich am besten direkt komplett richtig mit Gedanken zu Geschwindigkeit und co. erstellt werden sollten, da ansonsten Ggf. eine Änderung des Systems ein unglaublicher, quasi nicht hinnehmbarer Mehraufwand ist. U.u. ist es garnicht mehr möglich Rel.DBs zu ändern, da zu komplex und verschachtelt.
Tiefsetzsteller schrieb: > dass Code und Datenbanken eigentlich am besten direkt komplett > richtig mit Gedanken zu Geschwindigkeit und co. erstellt werden sollten, Das ist natürlich der theoretische Idealfall. Den erreicht man aber meistens nicht. Das kann verschiedene Gründe haben. z.B. man hat nicht genug Erfahrung. Oder die Kosten/Aufwand wiegen den Nutzen nicht auf. Wenn du schon zu Beginn diesen Idealfall 100% erzwingen willst, wirst du nie etwas funktionierendes erschaffen. Lernen ist iterativ und der Fehlschlag ist ein essentieller Teil davon.
.. wenn Du so an die Sache rangehst wird das nichts ! Wie MaWin schon schrieb, fang einfach an ! Tiefsetzsteller schrieb: > Danke dafür erstmal! > > Über Gespräche und andere Forenbeiträge, hatte ich den Eindruck > bekommen, dass Code und Datenbanken eigentlich am besten direkt komplett > richtig mit Gedanken zu Geschwindigkeit und co. erstellt werden sollten, > da ansonsten Ggf. eine Änderung des Systems ein unglaublicher, quasi > nicht hinnehmbarer Mehraufwand ist. U.u. ist es garnicht mehr möglich > Rel.DBs zu ändern, da zu komplex und verschachtelt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.