Hier können Artikel, Tutorials, Bücherrezensionen, Dokumente aller Art, Texturen, Sprites, Sounds, Musik und Modelle zur Verfügung gestellt bzw. verlinkt werden.
Forumsregeln
Möglichst sinnvolle Präfixe oder die Themensymbole nutzen.
Sauber programmieren und trotzdem ordentliche Performance bauen?
Ich habe um die Feiertage herum einen Podcast angefangen zu produzieren. Er besteht aus 6 Folgen, wovon 3 Folgen schon releast sind.
Ihr könnt den Podcast gerne auf Soundcloud abonnieren. Soundcloud bietet so eine Distributions-Funktion an, das die Tracks auf alle möglichen Plattformen hochlädt. Die wirklich wichtigen Podcast-Apps wie iPhone und so weiter sind da aber leider nicht dabei :(
Hi, ich hab mir die Folgen mal angehört. Finde den Podcast prinzipiell schon gut produziert: Du hast dir offensichtlich vorher ausreichend Gedanken über jede Folge gemacht, hast eine Idee was du beschreiben willst und auch wie. Die Tonqualität ist gut und der Stimme kann man auch gut zuhören. Soweit passt alles :)
Zum Thema selbst: 'Sauberer Code' ist halt immer irgendwie etwas schwammig. Mit fallen zu jeder 'Regel' Fälle ein, wo es besser ist das gerade nicht so zu machen, was aber natürlich nicht gegen die Grundidee dahinter spricht. Prinzipiell ist es glaube ich schon gut, möglichst viele Entwurfsmuster mal gesehen zu haben um dann entscheiden zu können, welches in welcher Situation sinnvoll ist. Ich bin mir auch nicht sicher ob ein Podcast das beste Format ist um darüber zu sprechen. Vielleicht hätte ein Blog-Post mit Codebeispielen auch viel für sich.Den Podcast kann man sich halt durchhören und sich vielleicht etwas davon mitnehmen, aber um etwas durchzuarbeiten finde ich meistens Text besser.
Vielleicht wäre es auch nicht schlecht, die Zielgruppe etwas klarer auszudefinieren. Sauberer Code ist ja (hoffentlich!) eher ein Anfängerproblem, vielleicht wäre es nicht verkehrt sich da einfach mal auf eine Sprache festzulegen und das konkret vorzumachen. Es fühlt sich für mich ein wenig so an als sei der Podcast aus der Idee heraus entstanden, dass du mal über etwas reden möchtest, worüber duch dich auskennst und was du spannend findest. Aber es wäre vielleicht auch gut zu überlegen wer den Podcast hören soll und weshalb. So könntest du den viel zielgerichteter Bewerben udn vermutlich auch viel mehr positives Feedback bekommen.
der Podcast richtet sich entgegen deiner Annahme nicht an Programmieranfänger, sondern im Gegenteil an diejenigen, die Objektorientierung bis zum Letzten beherrschen. Dass man Variablen richtig benennen muss, setze ich voraus.
Im Podcast gehe ich Stück für Stück auf Techniken beyond OOP ein (SQL Query Merging trotz ORM, Aspektorientierte Programmierung), was man erst versteht, wenn man alle Techniken der "alten Welt" auch beherrscht.
Ich habe auch mal reingehört, weil mir das Thema am Herzen liegt. Ich fände weiterführende Links gut. Teilweise scheinen mir die Vokabeln etwas exotischer zu sein und Googlen hilft nicht so richtig. Was verstehst Du z.B. unter "SQL Query Merging"? Ist das ein geläufiger Begriff?
Bzgl. AOP und Code-Generierung bin ich mir nicht sicher, ob das wirklich empfehlenswert ist. Da hat man ganz schnell Voodoo-Architektur mit einer eingebauten Debug-Hölle. Dependency Injection (die man ja auch mit Code-Generierung machen kann) ist da ja noch harmlos. Das hört sich alles ein bisschen nach "Enterprisy Makro- und Template-Programmierung" für mich an. Das ist sicher ein Trade-off, aber Du scheinst sehr in die Richtung "Generic thing machine" zu tendieren :)
Chromanoid hat geschrieben: ↑26.01.2021, 23:42Teilweise scheinen mir die Vokabeln etwas exotischer zu sein und Googlen hilft nicht so richtig. Was verstehst Du z.B. unter "SQL Query Merging"? Ist das ein geläufiger Begriff?
Zu seiner Verteidigung kann ich das ohne DB-Erfahrung und ohne googeln: Zusammenfassen von SQL-Queries, um den Durchsatz zu verbessern :P
Dass es sowas heißen kann, ist mir schon klar 🤓. Aber geläufig ist mir das zumindest als "Fachwort" nicht. Hört sich das einfach schöner an als "Union Queries" oder ist damit noch mehr bzw. etwas anderes gemeint?
@antisteo Oben habe ich unhöflicherweise etwas ganz vergessen zu schreiben: Ich finde Du trägst das sehr angenehm vor und ich habe gerne zugehört.
Heute gegen Abend kommt die nächste Folge raus mit dem Titel "Folge 6: 100-fache Performance durch LEFT-JOIN-Trick bei SQL"
Beim SQL Query Merging reduzierst du IO-Overhead, indem du Joins auf SQL-Seite schon ausrechnest und anschließend auf Client-Seite wieder auftrennst. Gleichzeitig ist das ziemliches Code-Gepuzzel, d.h. im gleichen Atemzug gebe ich Tipps, wie man sich ein schönes Interface um diese Optimierung baut.
btw das mit den verlinkten Code-Beispielen ist keine Dumme Idee. Mündlich zu erklären, welche JOIN in welcher Query rein muss, ist auch bei einer guten Vorstellungskraft schwierig
Huhu, ich habe mal Deinen neuen Beitrag gehört, weil mich das SQL Query Merging doch sehr neugierig gemacht hat :) Wieder schön produziert. Du meintest das N+1 Query Problem. Zumindest in Java unterstützen das geschilderte Vorgehen zur Lösung Hibernate und bestimmt die meisten anderen JPA-Implementierungen (mindestens über FetchType.EAGER, aber auch sowas wie Entity Graphs), aber auch Späße wie ebeans im Rahmen der sog. "Fetching Strategies" direkt. Da muss man sich bei Hibernate meist nur wenig drum kümmern (aber natürlich darüber nachdenken, wie man es haben will). Was meintest Du da mit "trotz ORM" - oder war auch ohne ORM gemeint?
Zu dir, Chromanoid: Ich meinte trotz ORM. Ich kenne es noch aus Zend-Zeiten, dass ein ORM aus jedem Call eine eigene Query gemacht hat und diese auch ausgeführt hat. Ultra-langsam. Ein intelligentes ORM sollte erst mal alle Queries sammeln, dann mergen und anschließend ausführen. Das setzt natürlich programmiererische Planung voraus und zerpflückt den Code komplett, weil man schon am Anfang über alle benötigten Daten Bescheid wissen muss. Auf dieses Problem gehe ich in späteren Folgen sogar ein und schlage dort vor, das "zerpflücken" des eigenen Codes zu automatisieren - als Sprachfeature.
