Der Beste Programmier-Tipp, Den Ich Je Bekommen Habe
ฝัง
- เผยแพร่เมื่อ 7 ส.ค. 2024
- Hier geht's zum Newsletter newsletter.timleuschner.de
Was können wir von Elon Musk beim Programmieren lernen? Bestimmt mehr als du denkst. Dass er aber den besten Programmiertipp gibt, das hätte ich nicht erwartet. Was dieser ist, erfährst du im Video.
00:00 Intro
00:33 Teil 1
02:32 Teil 2
04:21 Teil 3
06:19 Teil 4 - วิทยาศาสตร์และเทคโนโลยี
echt spannendes Video :)
Kann man auf jeden Fall in vielen Bereichen anwenden, nicht nur beim Programmieren.. machen ist auf jeden Fall besser, als nicht ins Handeln zu kommen
Lebensweisheiten getarnt als Programmiervideo 🤝
Gilt auch für erfahrene Programmierer, die vor lauter Perfektionismus gar nicht erst mit programmieren anfangen.
Sehr korrekt
Im analogen Leben heißt sowas Prototyp. 😮 Man baut also erstmal was zusammen, was funktioniert und danach kommt das Finetuning und die Modularisierung.
Das ist alles nichts Neues, aber viele ITler haben nur die Schulbank gedrückt und sonst keine Lebenserfahrung und das machts oft schwer.
Das Ziel ist das Ziel, nicht der Weg! 🎉 😂
Das Endprodukt ist dann gut, wenn du es nach 2 Jahren mal wieder öffnest und ohne viel Aufwand erkennst, was da drin los ist (logo, dann auch jeder Andere, der rein schaut). Kommentare sind zudem keine Unsauberkeit sondern extremst wichtig für die Effizienz! Wer was anderes sagt ist nur ein Theoretiker in der Bildung, oder bald pleite. 😂
Beim Compilieren oder Interpretieren werden Kommentare sowieso entsorgt oder ignoriert.
Für den produktiven Einsatz auf Servern kann man auch bereinigten Code erstellen.
Wenn du ein neues Programm schreiben musst, gehe davon aus, dass du es noch mindestens einmal noch einmal schreiben musst. Ich habe dazu auch ein Literaturtipp : "Managing the Development of Large Software Systems" von Dr. Winston W. Royce. Ja, das ist der Artikel, der von vielen als Einführung in das Wasserfallmodell betrachtet wurde. Leider haben diese Leute nicht den ganzen Artikel gelesen, sonst hätten sie erkannt, dass es eine Kritik am naiven Wasserfallmodell ist.
Ich glaube, dass es wahrscheinlicher ist, dass es Feen gibt, als dass Kunden wissen, was sie wollen.
Ich hatte bei einem sehr ambitionierten Projekt ein ähnliches Problem und habe mir auch schon Gedanken in die Richtung gemacht. Danke für das Video!
Sehr gutes Video !
Ich hab mit dem Video meine Probleme. Ich verstehe deine Aussage und würde diese auch teilen, allerdings ist es nun mal so, dass wenn dein Code nicht den Projekt-Anforderungen entspricht, du erstens nicht durchs Quality-Gate kommst und zusätzlich noch die Kollegen dastehen und fleißig kommentieren werden. Diese Probleme wirst du erst resolven müssen, um überhaupt mal in den DEV-Branch geschweige denn in den Master zu mergen / dein Ticket abzuschließen. Du wirst vom QG und dem Team erzogen und wenn du nicht ein gewisses Niveau lieferst, richtige Probleme bekommen..
& Alleine arbeiten wirst du in den seltensten Fällen haben / erleben.
Ich finde diese Frage interessant, da ich diese Probleme bisher nicht hatte.
Ich bin schon länger in der Software Entwicklung seit einer Zeit, in der man noch nicht wusste, was guten Code ausmacht. Somit konnte ich durch Übung automatisch besser werden, so dass diese Bedenken nicht aufkamen.
wieso ist extra eine Klasse für das User-Model >_<
Einfach eine Funktion und exportieren, wenn es sein muss als key eines Objektes für namespace.
Cooles Video!
Danke :)
Einfach drauf los programmieren ist ein guter Hinweis. Ein Design kann sich auch beim Schreiben entwickeln.
Wenn man aber spaghetti code geschrieben hat, um schnell zu einer Lösung zu kommen, sollte man bei späteren Änderungen etwas Zeit einplanen für refactoring. Ein Stück Code ist kein Kunstwerk, das man nachträglich nicht verändern darf. Also gern auch Mal alten Code wegwerfen und besser machen.
Ich hätte gedacht dass die Musk Methode ist, einfach für die nächsten 10 Jahre zu behaupten, dass du bis Ende dieser Woche einen Merge request einstellen wirst.
Das ist auch eine Möglichkeit
haha, hab das Buch über ihn gelesen, da kommt dieses Thema öfter vor, was er alles verspricht und eigentlich nie gehalten hat, zumindest den Fertigungszeitpunkt.
Nein, ganz so einfach ist es nicht. Du musst außerdem behaupten, dass Dein Code absolut revolutionär sein wird.
Als Anfänger kommt man nicht umhin schlechten Code zu schreiben, weil die Erfahrung fehlt. Wichtig ist das man sich weiter bildet und so seine Erfahrungen erweitert. Bücher wie Clean Code sind gute Bücher, aber erstmal nichts für Anfänger.
Unterschied und Gefahr macht auch das lernen wenn man Azubi in einem Unternehmen. Leider ist es so das wenn man Entwickler hat/kennt die zum Beispiel 10-15 Jahre programmieren, automatisch als gut und Erfahren gelten. Und sie haben natürlich die ein oder andere Software geschrieben. Nur sind es meistens dann die einzigen die ihre Programme auch erweitern können.
Wenn diese Künstler dann auch noch Leute ausbilden, kommen tatsächlich kleine Elon Musks heraus. Nur eben arm im Geldbeutel und im Geist 😅
Wenn man guten Code schreiben will, darf man nicht in der Komfortzone verbleiben und sich auf den ersten Erfolgen ausruhen. Man muss weiter gehen und sich mit höheren Themen beschäftigen wie Design Patterns, Strukturen der Daten und Code, Frameworks, anderen Code lesen. Durch diese Erfahrungen lernt man einschätzen wann die eigene Arbeit dann endlich gut wird.
Letztlich mussten wir Programmieren auch Stück für Stück lernen. Am besten geht das mit eigenen Projekten. Da ist man selber der Kunde und kann mit dem Ergebnis nur sich selbst nerven oder schaden.
Bist du mit einer Celine Leuschner aus Burgwedel verwandt?
Jeder ist mit jedem verwandt, hast du Darwin nicht gelesen?
@@Simchen Dich hat keiner gefragt, Kevin.
@@martapfahl940 Und ob, deine Frage ist öffentlich, Peter.
Ich finde persönlich, nach 6 Jahren kann man noch nicht von Programmiererfahrung sprechen, man merkt, dass da viel bla bla im Video ist. Genau wie mir junge Java-Entwickler in Projekten vorkommen, viel Overhead, Boilerplate, viel heiße Luft, am Ende ist dann halt doch nichts fertig, aber schön Retro, Review und Dailys gemacht.
Interessante Sichtweise - was für bla bla kann ich streichen und ist unnötig für dich? Ab wann darf man von Programmiererfahrung sprechen?
Dein Punkt, dass es nicht voran geht, ist doch genau Thema des Videos. Du hast offensichtlich mehr Erfahrung als deine jungen Kollegen - nimm sie doch an die Hand und zeig ihnen, wie sie es besser machen können :)
Super Video. Allerdings bin ich bei 2:05 überhaupt nicht einverstanden. Für mich war A deutlich besser lesbar und verständlicher. Sicherlich, etwas mehr zu lesen, aber eindeutig klar was die einzelnen Zeilen tun sollen. B war für mich überhaupt nicht verständlich. Mir war überhaupt nicht klar, was das der code sagen soll. Die Abkürzungssyntax finde ich schrecklich. Ich bin der Meinung, Code sollte unabhängig von der Syntax trotzdem lesbar bleiben.
dann vergleich mal den Aufwand, um bei A die Farbe "yellow" hinzuzufügen, mit dem Aufwand, um bei B "yellow" hinzuzufügen...
@@maximilianzirpel1720 Was bringt denn ein reduzierter Aufwand, wenn man mit der Syntax nicht vertraut ist? Ist für mich wesentlich mehr Aufwand nachzuschlagen, was die spezifische abgekürtzte Schreibweise bedeutet, als die klassischer herkömmliche Methode.
@@RP-ou6kr ich habe das Gefühl, dass die Syntax hier nicht das Problem ist, sondern dass dir fundamentale Kenntnisse zu Datenstrukturen, die man beim Programmieren nutzen kann, fehlen...
Lesbarkeit und Verständnis sind wieder sehr subjektive Faktoren - für mich war B einfacher zu lesen, weil ich gerne Maps/Objekte verwende und aus den im Video gennanten Gründen.
Besser wartbar und einfacher zu verändern, bleibt aber Beispiel B
Das täuscht. Du hast erstmal viel Text das du lesen und schreiben musst. Der Code wiederholt sich und hier können Fehler entstehen, weil man sich verschrieben hat. Und das Beispiel A ist noch klein. Denke mal an 100 Zeilen oder 10000 Zeilen. Wenn du das als normal erachtest, dann hast du es nicht anders gelernt und bisher verpasst dich weiter zu bilden.
Das Beispiel B ist wirklich einfacher, weil du Daten für sich stehen hast und nur Daten schreiben musst. Diese Daten kannst auch in anderen Programm-teilen verwenden. Die letzten Zeilen fragen diese Daten einfach ab.
In Beispiel A sind die Daten in Code eingebunden. Wenn du die selben Daten dann wo anders brauchst, musst du wohl den Code kopieren. Kann man machen aber sich bitte dann nicht wundern, wenn der Code kritisiert wird.
wenn du ineffektiven code schreibst oder nicht robust gegen sicherheitslücken bleibst dann schmeiß ich dich ausm team, bye bye
Dann bin ich mit Javascript ja gleich raus :(
Man kann zunächst einen Code schreiben der funktioniert. Dann "cleaned" man den durch ein refactoring. Am nächsten Tag liest man den nochmal, stellt dann meistens fest, daß Benennungen suboptimal waren und verbessert die auch noch. So mache ich es. Meistens kann man dann auch Kommentare wieder löschen. Die Kommentare stehen da ja, weil etwas nicht offensichtlich war.