Archiv verlassen und diese Seite im Standarddesign anzeigen : Buchempfehlung - Code-Strukturierung bei objektorientierter Programmierung
Hi zusammen,
ich habe seit dem Lockdown angefangen mehr zu programmieren und habe dafür Python gewählt. Auf der Arbeit habe ich auch gute Anwendungsmöglichkeiten, um mich da mehr reinzuarbeiten. Ich komme auch gut voran und kann schon ganz coole kleine Tools umsetzen. Allerdings ist der Code noch Kraut und Rüben und man merkt, dass ich das nicht richtig gelernt habe (Ingenieur Automotive).
Ich möchte mich da aber mehr einarbeiten und suche nach Empfehlungen bezüglich Strukturierung und Organisierung für Code von Programmen.
Könnt ihr hier was spezielles empfehlen?
Monger
2021-01-08, 08:53:48
Schau dich doch mal auf Manning.com um. War eigentlich mit jedem Buch zufrieden was ich dort gekauft habe. Die wählen ihre Autoren gut aus.
Python ist jetzt halt aber auch ne funktionale Sprache. Guter funktionaler Stil ist doch was anderes als guter objektorientierter Stil.
Ein Klassiker ist hier sicher Clean Code von Robert Martin. Da geht es ganz allgemein und sprachunabhängig darum, wie man sauberen und vor allem testbaren Code schreibt.
Speziell zu Python ist Fluent Python von Luciano Ramalho gut geeignet, um den eigenen Code besser zu strukturieren, und vor allem idiomatisches ('pythonic') Python zu lernen.
maximAL
2021-01-08, 19:40:30
Für guten Code - Clean Code
Für gute Architektur - Clean Architecture
Die besten beiden Bücher über Softwareentwicklung, die ich bis jetzt gelesen habe.
Im Unterschied zu vielen anderen Büchern erklären sie nicht einfach nur was man tun soll, sondern vor allem auch warum anhand von negativ und positiv Beispielen.
Man muss allerdings etwas abstrahieren können, da die meisten Beispiele in C++ oder Java geschrieben sind. Die meisten Konzepte lassen sich aber auch auf Python übertragen.
Für Python speziell sollte man sich die PEPs in der Doku anschauen, da stehen für alles Mögliche Best Practices.
universaL
2021-01-08, 20:10:33
mehr generell: https://www.amazon.de/Pragmatic-Programmer-Journeyman-Master/dp/020161622X
mehr Java inspiriert, aber fand ich damals ganz nett am Anfang: Refactoring von Martin Fowler
Mega danke. Das klingt super!
Wenn ihr Einsteiger wärt, in welche Richtung würdet ihr gehen, was die Auswahl der Sprache angeht?
Ich komme aus der Ingenieursrichtung. Da wurde/wird viel mit Matlab gemacht, aber da das kostet (und mir im studium keinen Spaß gemacht hat) wollte ich davon weg. Was ich können möchte ist Programme im technischen, wissenschaftlichen Umfeld schreiben, die folgendes Leisten: Datenhandling mit Input/Outputs zw verschiedenen Programmen, Datenauswertung/Reportgenerierung/Plots, gesteuert über GUI. Cool wäre es wenn auch mobile Apps machbar wären.
Das alles möchte ich dann auf private Projekte übertragen können. Sollte also nicht zu speziell werden.
Java ist ja sehr weit verbreitet aber da habe ich, da ich nicht aus der Branche komme, keinen Überblick. Deshalb frag ich euch mal :)
Monger
2021-01-09, 12:02:08
Ich komme ja aus dem .Net Umfeld, also vorallem C#, Powershell.
Wenn ich heute frisch anfangen würde, würde ich mit Python anfangen. Man kann so viel damit machen, das Ökosystem ist inzwischen so riesig...
Java für Backend ist ne hervorragende Ergänzung.
Es ist sicher nicht verkehrt, wenn man Python im Werkzeugkasten hat. Damit macht man nichts falsch. Ich komme eher aus der hardwarenahen Richtung und da würde ich halt noch C++ ergänzen :)
Zu Java kann ich nur sagen: Jeder schimpft darüber und jeder benutzt es ^^. Manche vertreten auch die Meinung, dass Java die einzige Programmiersprache ist, in der man NICHT objektorientiert programmieren kann :D Für mich ist Java auch eher eine "klassenorientierte" als eine objektorientierte Sprache. Von daher mache ich um Java immer einen großen Bogen. Aber Java ist halt dennoch sehr weit verbreitet.
lumines
2021-01-09, 12:31:50
Python ist jetzt halt aber auch ne funktionale Sprache. Guter funktionaler Stil ist doch was anderes als guter objektorientierter Stil.
Python ist alles, aber definitiv keine funktionale Sprache. Man kann in Python funktional programmieren, aber eine besondere Stärke ist das eigentlich nicht.
Wenn ihr Einsteiger wärt, in welche Richtung würdet ihr gehen, was die Auswahl der Sprache angeht?
Ich komme aus der Ingenieursrichtung. Da wurde/wird viel mit Matlab gemacht, aber da das kostet (und mir im studium keinen Spaß gemacht hat) wollte ich davon weg. Was ich können möchte ist Programme im technischen, wissenschaftlichen Umfeld schreiben, die folgendes Leisten: Datenhandling mit Input/Outputs zw verschiedenen Programmen, Datenauswertung/Reportgenerierung/Plots, gesteuert über GUI. Cool wäre es wenn auch mobile Apps machbar wären.
Für Software im wissenschaftlichen und technischen Umfeld willst du definitiv Python nehmen. Numpy, Pandas und Co. sind genau das, was du suchst. Man sollte aber dazu sagen, dass der meiste wissenschaftliche Code nicht die Business Logic eines Unternehmens enthält und entsprechend etwas simpler gestrickt (im Hinblick auf die Architektur) und problemorientierter ist. Verschiedene Programmierparadigma zu kennen und anzuwenden ist da nützlich, aber du wirst sehr wahrscheinlich (vorerst) keine riesigen Softwarearchitekturen bauen.
Python ist zwar auch sehr objektorientiert, aber es ist eben nicht Java. Es ist auch nicht statisch typisiert (bzw. optional per Gradual Typing). Viele Konzepte aus der Java-Welt sind in Python nicht zwangsläufig nützlich.
Generell macht es wahrscheinlich Sinn, wenn du dir einmal anguckst, wie andere Projekte ihren Code strukturieren. Such dir eine populäre Library raus und schau dir den Code an. Vergleiche das mit den Konzepten, die du kennst oder gerade lernst. An einigen Stellen wirst du wahrscheinlich viele objektorientierte Konzepte erkennen, an anderen eventuell nicht.
Ansonsten solltest du dir aber auch einmal Ruby angucken. Ruby kommt aus einer ähnlichen Richtung wie Python, ist aber stärker auf Objektorientierung ausgelegt. In Ruby fehlt dir zwar die ganze wissenschaftliche Software, aber es ist sicher nicht die schlechteste Sprache, wenn man mehr über Objektorientierung lernen will, aber man die Enterprise-Welt mit Java und Co. eher meiden möchte.
universaL
2021-01-09, 14:17:55
schnipp...schnapp
Ansonsten solltest du dir aber auch einmal Ruby angucken. Ruby kommt aus einer ähnlichen Richtung wie Python, ist aber stärker auf Objektorientierung ausgelegt. In Ruby fehlt dir zwar die ganze wissenschaftliche Software, aber es ist sicher nicht die schlechteste Sprache, wenn man mehr über Objektorientierung lernen will, aber man die Enterprise-Welt mit Java und Co. eher meiden möchte.
dann vielleicht: Practical Object-Oriented Design (POODR) von Sandi Metz (https://sandimetz.com/products), bin mir aber nicht sicher wie anfängerfreundlich das Buch ist, habe nur mal durchgescrollt...
und für wissenschaftliche Sachen: Vielleicht ist Julia (https://julialang.org/) interessant, entwickelt sich gefühlt gerade relativ stark, insbesondere dann, wenn es auch um etwas Performance geht ;-)
maximAL
2021-01-10, 19:36:09
Wenn ihr Einsteiger wärt, in welche Richtung würdet ihr gehen, was die Auswahl der Sprache angeht?
Die, die deine Probleme löst ;)
So auf der grünen Wiese kann man mit Python aber sicher nichts falsch machen, weil man sich mit dem "Batteries included" Ansatz, den klaren Vorgaben zum Stil und der generellen Einfachheit aufs Wesentliche konzentrieren kann.
Man sollte auf keinen Fall eine Sprache aussuchen, einfach nur weil sie komplex ist, von großen Firmen genutzt wird oder man damit irgendwelche super krassen effizienten Sachen machen kann. Das war damals "zu meiner Zeit" immer ganz schlimm. Da musste es bei einigen Leuten immer nacktes C sein, weil das ja sooo super effizient ist. Und während andere funktionierende Programme geschrieben haben, haben diese Leute immer noch versucht ihre selbstgebastelten verketteten Listen ans laufen zu bringen.
Monger
2021-01-11, 21:34:36
Für gute Architektur - Clean Architecture
Danke für den Tipp. Habs grade durch. Kann bestätigen, gutes Buch!
Ich mag nur den Uncle Bob nicht so gerne. Komm glaub mit seinem unterkühlten Humor nicht klar. Aber was er so in den Raum schmeißt, ist lesenswert.
Ist für mich jetzt auch das erste mal, dass ich in nem Buch so klare Kritik an SoA und Microservices lese. Ich hatte das schonmal in ner Fortbildung, aber nicht so konkret. Und er hat wahrscheinlich recht damit.
Monger
2021-01-13, 00:21:49
Danke für den Tipp. Habs grade durch. Kann bestätigen, gutes Buch!
Ne, ich korrigiere mich da...
So bei genauerem Hinschauen ist das Buch eigentlich ne Kritik an gängigen Architekturstilen. Aber es wendet sich nicht an Einsteiger. Dafür reißt es zu viele Begriffe an, und setzt voraus dass man die kennt.
chetigol
2021-01-13, 09:09:41
Für den Einstieg die bereits erwähnten:
+ Clean Code
+ Clean Architecture
Weiter würd ich vorschlagen:
+ Objektorientierte Systementwicklung
Ist quasi eine Schritt-für-Schritt Anleitung von den Geschäftsanforderungen, Design/Architektur bis zum fertigen Code
https://www.amazon.de/gp/product/383480245X/ref=ppx_yo_dt_b_asin_title_o00_s01?ie=UTF8&psc=1
Etwas fortgeschritten:
+ Langlebige Software-Architekturen von Carola Lilienthal
https://www.amazon.de/gp/product/3864907292/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1
Hab mir Clean Code bestelltundhol dasmorgwn von DHL ab. Bin gespannt. Hab sowas noch nie gelesen.
Hab mich jetzt entschiedenmein kleines Tool neu aufzusetzen, da es stark gewachsen ist und irgwie wurde es ein pain in the ass... anstelle von Tkinter hab ich die GUI mit qt designer zusammen geklickt. So kann man super flexibel neu platzieren ohne im Programm an sich was zu verändern. Auch konnte ich die Basics des objektorientierten gleich anwenden. Ist mühsam aber geht :up:
Meine "Buchempfehlung" sind Vorlesungen von guten Unis auf Youtube. Leicht findest du Lehrplaene dazu.
Jeder Programmierer sollte mit den Grundlagen der Computerarchitektur anfangen. Ein x86-Simulator kann dabei sehr hilfreich sein.
Daraufhin solltest Du Dir die Grundlagen und einfach Beispiele von Algorithmen und Datenstrukturen anschauen.
Mit den Inhalten daraus solltest Du in C experimentieren.
Das soll nicht bedeuten dass du ein Studium in Computer Science nachmachen sollst, jedoch ist Quatsch wie OOP zu lernen, um ein wirkliches Verstaendnis von Programmieren erlangen, genauso unsinnig, wie ein schlechtes, over-engineered Fahrwerk zu konstruieren, ohne gekoppelte Differentialgleichungen zu verstehen.
Monger
2021-02-08, 23:00:35
Hab mir Clean Code bestelltundhol dasmorgwn von DHL ab. Bin gespannt. Hab sowas noch nie gelesen.
Hast du schon reingeschnuppert? Was ist dein Eindruck?
Jeder Programmierer sollte mit den Grundlagen der Computerarchitektur anfangen. {...} Mit den Inhalten daraus solltest Du in C experimentieren.Bloß nicht. Programmierer denken in Algorithmen, Softwareentwickler denken in Verantwortungen und Abhängigkeiten. Ersteren kann man kleine Softwareprojekte geben, letzteren kann man mittlere und große geben. Und den meisten hängt die Sprache, mit der sie angefangen haben, den Rest des Lebens nach. Ein Ausflug in Low-Level-Sprachen wie C oder C++ kann helfen, Leuten die Ignoranz auszutreiben, die mit C# oder Java angefangen haben, aber anfangen sollte man damit nicht.
Buchempfehlungen:
Clean Code kann man als Einsteiger machen, weiß aber nicht ob das wirklich hilfreich ist. Clean Architecture ist ein gutes Buch, sollte man IMHO für später aufheben.
Wenn man die Grundprinzipien wie Polymorphie etc. drauf hat, ist "Head First Design Patterns" ein gutes Buch, um seine Werkzeugkiste zu erweitern und Perspektiven zu geben. Gleichzeitig würde ich mir die SOLID-Prinzipien anschauen: http://www.blackwasp.co.uk/SOLID.aspx
Nachfolgend würde ich "Refactoring" von Martin Fowler und "Working with legacy code" von Michael Feathers empfehlen. Beide geben einem Werkzeuge an die Hand, Smells zu erkennen und Anwendungen wieder sauber zu kriegen und damit aber vor Allem das Verständnis deutlich zu erweitern, was eigentlich gut oder schlecht ist.
Spätestens ab hier, hat man hoffentlich genug Erfahrung, um aus allem Anregungen mitzunehmen, aber nichts unwidersprochen hinzunehmen, sondern immer ein eigenes Urteil zu fällen.
Danach gibt es u.a. "Agile Principles, Patterns and Practices" von Martin und Martin, "Patterns, Principles and Practices of Domain-Driven-Design" von Millet und Tune und eben "Clean Architecture".
Darüber hinaus wird es immer spezialisierter und man kann eigentlich keine Basisliteratur mehr empfehlen, weil man daraus praktisch nichts Neues mehr lernt.
Irgendwann zwischendurch rennt man übrigens mit ziemlicher Sicherheit in das "Second System Syndrome", was genauso lehrreich wie schmerzhaft ist. ;)
Bloß nicht. Programmierer denken in Algorithmen, Softwareentwickler denken in Verantwortungen und Abhängigkeiten. Ersteren kann man kleine Softwareprojekte geben, letzteren kann man mittlere und große geben. Und den meisten hängt die Sprache, mit der sie angefangen haben, den Rest des Lebens nach. Ein Ausflug in Low-Level-Sprachen wie C oder C++ kann helfen, Leuten die Ignoranz auszutreiben, die mit C# oder Java angefangen haben, aber anfangen sollte man damit nicht.
Buchempfehlungen:
Clean Code kann man als Einsteiger machen, weiß aber nicht ob das wirklich hilfreich ist. Clean Architecture ist ein gutes Buch, sollte man IMHO für später aufheben.
Wenn man die Grundprinzipien wie Polymorphie etc. drauf hat, ist "Head First Design Patterns" ein gutes Buch, um seine Werkzeugkiste zu erweitern und Perspektiven zu geben. Gleichzeitig würde ich mir die SOLID-Prinzipien anschauen: http://www.blackwasp.co.uk/SOLID.aspx
Nachfolgend würde ich "Refactoring" von Martin Fowler und "Working with legacy code" von Michael Feathers empfehlen. Beide geben einem Werkzeuge an die Hand, Smells zu erkennen und Anwendungen wieder sauber zu kriegen und damit aber vor Allem das Verständnis deutlich zu erweitern, was eigentlich gut oder schlecht ist.
Spätestens ab hier, hat man hoffentlich genug Erfahrung, um aus allem Anregungen mitzunehmen, aber nichts unwidersprochen hinzunehmen, sondern immer ein eigenes Urteil zu fällen.
Danach gibt es u.a. "Agile Principles, Patterns and Practices" von Martin und Martin, "Patterns, Principles and Practices of Domain-Driven-Design" von Millet und Tune und eben "Clean Architecture".
Darüber hinaus wird es immer spezialisierter und man kann eigentlich keine Basisliteratur mehr empfehlen, weil man daraus praktisch nichts Neues mehr lernt.
Irgendwann zwischendurch rennt man übrigens mit ziemlicher Sicherheit in das "Second System Syndrome", was genauso lehrreich wie schmerzhaft ist. ;)Ich bin mir nicht sicher ob dies Sarkasmus war.
"Erst ohne Grundlagenverständnis mit dem klar unsinnigen Polymorphismus und dann mit Design Patterns das Problem an die Problemlösung anpassen lernen und dann mit dem völligen Unverständnis weitermachen!!!1".
Du hast lediglich, im gleichen Sinne, vergessen zu erwähnen wie heilsbringend es ist immer den "neuesten" Programmiersprachen hinterher zu rennen.
Was du hier gesagt hast ist exakt der Schwachsinn, der alle Probleme in der Softwareentwickler-Branche verursacht hat.
RattuS
2021-03-07, 03:37:02
Grundsätzlich sollte man immer unterscheiden zwischen Design, Technologien und Werkzeugen. Software wird teuer, wenn sie undurchdacht ist und dort zu konkret ist, wo sie nicht konkret sein müsste. Technologien muss man kennen(lernen), verstehen und zum richtigen Zeitpunkt zur richtigen Technologie greifen. Die Werkzeuge sind das Glied in der Kette, das im Regelfall am leichtesten auszutauschen ist bzw. sein sollte.
Zum Thema Abstraktion beim Design gibt es einen guten Google Tech Talk auf YT. Sinngemäß geht es darum, dass man eine Implementierung immer so weit wie möglich hinauszögern können sollte. Entscheidend ist, dass die Abstraktion das Problem löst. Eine Implementierung kann man jederzeit ändern, Konzepte und Schnittstellen hingegen nicht so einfach. In der Anekdote geht es um die Datenbankanbindung. Die Ausgangsfrage, die zu Projektbeginn gestellt wurde, war: "Welches RDBMS verwenden wir?". Niemand konnte die Frage beantworten, also zögerte man es zunächst hinaus. Je weiter die Entwicklung kam, desto relevanter wurde die Frage, wie Daten denn nun gespeichert werden sollen. Damit man die Antwort darauf weiter hinauszögern kann, hat man einfach einen generischen Datenprovider angebunden, der in der Testumgebung nur irgendwelche Text-Dateien geschrieben hat. Dem Team ist dann irgendwann klar geworden, dass die Ausgangsfrage falsch gestellt war. Es geht nicht darum, welches RDBMS verwendet wird, sondern wie Daten gespeichert werden. Und die einzig richtige Antwort darauf lautet: "Irgendwie."
Software-Design hat nichts mit Technologie oder den Werkzeugen zu tun. Hier hilft Erfahrung am meisten. Die Leute, die ich in den letzten 10 Jahren ausgebildet habe, hatten Eines gemeinsam: Wer sich die Finger verbrennt, lernt daraus. Du kannst noch so viele Bücher lesen oder Meinung anhören, am Ende geht es eher darum, dass du die Wege, auf denen entlang du gestolpert bist, nie wieder gehen wirst. Das kommt mit der Zeit und Bücher helfen hier nur gewisse Wege frühzeitig zu erkennen und erst gar nicht einzuschlagen. Trotzdem würde ich einen Einsteiger immer erstmal stolpern lassen.
Zum Thema Technologie: Wichtig ist es eine Technologie zu verstehen. Zu viele (neuere) Entwickler springen auf Technologie X auf, weil sie trendig ist. Zwar gibt es meist auch einen guten Grund, warum sie im Trend sind, aber trotzdem sollte man zunächst verstehen, ob jene Gründe auch gut genug sind, wenn es darum geht, MEIN Problem zu lösen.
Mittlerweile auch oftmals übergangen sind Protokolle und Spezifikationen. Ich habe viele Leute kennengelernt, die im Web-Bereich tätig sind und nicht im Entferntesten wissen, wie HTTP funktioniert. Frontent-Entwickler, die React nutzen, aber nichts über das DOM wissen. Windows-Entwickler, die ACL nicht kennen und deren Programm nicht funktioniert, wenn sie nicht als Administrator gestartet werden. So manche Lösungen, die es mittlerweile breit auf dem Markt gibt, lassen die neuen Leute richtig verblöden. Convenience and Time-to-Market war nie wichtiger. Und darunter leidet Wissen, das es sich anzueignen gilt.
Zuallerletzt die Werkzeuge und darunter fallen Programmiersprachen. Hier hat sich viel getan und definitiv zum Guten. Ich gehöre noch zu den Leuten, die mit Assembler eingestiegen sind und lange habe ich versucht mir etwas darauf einzubilden. Aber die Wahrheit ist: heutzutage ist das einfach nicht mehr wirklich relevant. Natürlich ist es hilfreich zu verstehen, was unter der Haube abgeht, und es gibt auch noch ausreichend Anwendungsfelder, wo man nicht auf eine Hoch- oder gar Skriptsprache setzen kann. Aber insgesamt ist dieser Bereich in meinen Augen am unwichtigsten. Sprachen werder kontinuierlich weiterentwickelt, Paradigmen wandeln sich. Tools zur Automatisierung von Test-, Build- und Deploymentprozessen sind wie auch Virtualisierung und Skalierbarkeit weit fortgeschritten. Hier lohnt es sich, regelmäßig zu evaluieren, ob man noch gut genug fährt mit dem, was man hat. Der Vorteil: Sprachen und Systeme ähneln sich sehr stark und sind leicht zu erlernen. Von daher sollte die Antwort auf die Frage nach der ersten Programmiersprache darauf abzielen, wie der Schüler sich am besten motivieren kann. Vielen Leuten fällt es leichter, wenn sie Ergebnisse schnell und unkompliziert erreichen und die Gründe warum das so ist, erst später erfahren und kennenlernen. Es gibt aber auch Leute, die keine Befriedigung aus einer Blackbox ziehen.
Mein Tipp für den TS: Nimm dir ein kleines(!) Problem zur Hand und entwickle eine Lösung dafür. Fang ganz klein an und arbeite dich Stück für Stück in umfangreichere Aufgaben. Beginne nicht jedes Mal ein neues Projekt, sondern überlege dir, wie du vorhandene Projekte ausbauen könntest. Du wirst dabei deinen inneren Schweinehund kennenlernen, dem es zu widerstehen gilt. Wenn du deine ersten Projekte umgesetzt hast, schau dir Design-Patterns an. Erkennst du vielleicht deinen Ansatz dort irgendwo wieder? Die Wahrscheinlichkeit ist hoch, aber trotzdem wirst du feststellen, dass gewisse Konzepte noch mehr Feinheiten definieren, die du nicht bedacht hast. Das ist der Lerneffekt, den du erreichen willst.
Ich bin mir nicht sicher ob dies Sarkasmus war.
"Erst ohne Grundlagenverständnis mit dem klar unsinnigen Polymorphismus und dann mit Design Patterns das Problem an die Problemlösung anpassen lernen und dann mit dem völligen Unverständnis weitermachen!!!1".
Du hast lediglich, im gleichen Sinne, vergessen zu erwähnen wie heilsbringend es ist immer den "neuesten" Programmiersprachen hinterher zu rennen.
Was du hier gesagt hast ist exakt der Schwachsinn, der alle Probleme in der Softwareentwickler-Branche verursacht hat.
Die Frage könnte man auch bei der Empfehlung eines x86 Simulators für den Einstieg stellen.
Ich kenne leider zu viele studierte Informatiker, die sich genau das zu Herzen genommen haben scheinen.
Ein denkwürdiger Kandidat war ganz empört, dass das Team foreach statt for-Schleifen nutzt, weil der erstellte Iterator ja Performance kostet. Gleichzeitig war er der Meinung, dass man sich nicht darauf verlassen darf, dass der Compiler das (zumindest für einfache Fälle) schlicht umwandelt. Wo kämen wir denn da hin, wenn wir nicht jedes i++ zu einem ++i optimieren!?
Hat leider öfter mal versehentlich quadratische Laufzeiten produziert, weil er sich zwar tatsächlich recht gut mit dem Lowlevel auskannte, aber keinerlei Verständnis für Algorithmen hatte.
Ein aktuelles Beispiel ist ein weiterer C++ Fanboy, der darauf besteht, dass unsere Anwendungen ihre Daten per Shared-Memory austauschen - aus Performancegründen.
Wohlgemerkt eine Datenstruktur, die kaum 100 byte groß ist und einer Häufigkeit von < 1/s.
Er war nur all zu bereit festzulegen, dass beide Anwendungen zwingend auf dem selben Rechner laufen müssen, damit TCP/IP nicht zum Bottleneck wird...
Ich will nicht sagen, dass es nicht nötig ist Rechnerarchitektur zu verstehen.
Aber es ist halt auch nicht nötig x86 zu verstehen, während man von allem anderen keine Ahnung hat. Das sind zu viele, zu spezifische Details. Die abstrakten Grundlagen einer ALU, Register, Speicher und einfacher Befehle reichen völlig aus. Und selbst die sind für den Anfang zu viel.
Die Spezifika des Sprach-, OS- oder Architektur-Ökosystems (s. Rattus) sind für eine wart- und benutzbare Anwendung idr. wesentlich wichtiger. Und selbst die kommen nur nach und nach.
Erst das grobe Verständnis, dann die Details. Sonst kommen schnell so Missverständisse auf, wie Premature Optimization wäre eine Best Practice.
(Das bedeutet aber auch, dass man lange nicht fertig ist wenn man die Sprache beherrscht. Und ich verstehe auch den Frust, dass auch dieser Fehlschluss das Selbstverständis vieler Programmierer ausmacht.)
Monger
2021-03-07, 10:16:09
Ach, die Diskussion wieder... hab mal ne Studie gesehen: nahezu alle Softwareentwickler sind rückblickend davon überzeugt, die richtigen Kenntnisse aufgebaut zu haben - und zwar völlig unabhängig von den Kenntnissen.
Jeder glaubt, das richtige zu wissen. Und wahrscheinlich stimmt das auch: gibt über Softwareentwicklung so unfassbar viel zu wissen, Hauptsache man lernt. Das führt teils zu sehr unterschiedlichem Domänenwissen und Vorgehen, aber so ist es halt. Gibt auch nach über nem halben Jahrhundert IT keine Musterlösung.
Exxtreme
2021-03-08, 00:03:14
Zum Thema Technologie: Wichtig ist es eine Technologie zu verstehen. Zu viele (neuere) Entwickler springen auf Technologie X auf, weil sie trendig ist. Zwar gibt es meist auch einen guten Grund, warum sie im Trend sind, aber trotzdem sollte man zunächst verstehen, ob jene Gründe auch gut genug sind, wenn es darum geht, MEIN Problem zu lösen.
Meistens gibt es nur einen einzigen Grund warum eine Technologie trendy ist: cargo cult. Das ist etwas was ich an der IT-Industrie so richtig hasse. Dieses stumpfe Abkopieren von dem was eine der FAANG-Firmen macht. Ein gutes Beispiel ist das Thema Microservices. Netflix hat es vorgemacht und jetzt wird das ohne Sinn und Verstand eingeführt und zwar in vielen Firmen, die nicht einmal ein Promille der IT brauchen, die Netflix so auffährt. Und heraus kommen dann 20 Tomcats, die dann über REST + JSON so eine Art Möchtegern-RPC machen oder gar auf die gleiche DB zugreifen. Und wenn einer der Tomcats dann nicht will dann funktionieren die anderen 19 auch nicht weil man dann merkt, dass man einen verteilten Monolithen gebastelt hat und keine Microservices. Ohh mann, da könnte ich mich aufregen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.