Podcast by Carl-Philip Hänsch
Pro-Grammierer-Podcast
Claim This Podcastby Carl-Philip Hänsch
13 episodes
Updated Daily
Accepts GuestsHas SponsorsLocation 🇩🇪
Podcast Overview
1 verified contact email on file for Pro-Grammierer-Podcast
Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.
Recent Episodes
August 6, 2021
Folge 11 – Das CRUD - Pattern
Folge 11 – Das CRUD-Pattern CRUD – Alptraum und Lebenselexier jedes Entwicklers. CRUD steht für CREATE READ UPDATE DELETE und sind die 4 Daten-Operationen, die man einbauen muss, um eine sinnvolle Oberfläche oder API zu designen. CREATE – irgendwie muss man den Datensatz erstellen können. Ein Anlege-Formular muss die Felder des Datensatzes leer oder mit Default-Werten gefüllt anbieten. Per Knopfdruck wird der Datensatz erstellt. READ – Bei den Leseoperationen gibt es generell 2 Arten: Die Liste bzw. Tabelle, in der man ALLE Datensätze sieht: Tabellarisch, durchsuchbar, filterbar; Und dann gibt es noch den Detail-View, also die Detail-Ansicht. Während man in der Tabelle die Spalten weglässt, die nicht unbedingt für eine Suche oder das Wiederfinden von Datensätzen notwendig sind, sind im DetailView dann alle Daten eingeblendet. Handelt es sich im relativ einfache Datensätze wie z.B. eine einfache Relation mit 2 Spalten, kann man den DetailView auch weglassen. UPDATE – Das Update-Formular ist wie das Create-Formular aufgebaut: Die Spalten, die man noch bearbeiten können soll, werden mit den bisherigen Daten des Datensatzes gefüllt, man bearbeitet diese und drückt auf Speichern. Viele Entwickler versuchen, Zeit zu sparen und lassen immer wieder CRUD-Operationen weg. Meist leidet darunter die UPDATE-Funktion. Auf diese kann man noch am ehesten verzichten: anstatt einen Datensatz zu bearbeiten kann ihn ja der User löschen und neu anlegen. DELETE – Beim Löschen gibt man meistens dem Nutzer noch einmal die Möglichkeit, vor dem Löschen zustimmen zu müssen. All diese 4 CRUD-Operationen für jeden Datensatz umzusetzen ist eine WAHNSINNS Arbeit. Doch Entwickler, die auch nur eine davon weglassen, produzieren damit schlechte Software. Als Entwickler solltest du lieber schauen, dass du dir ein einheitliches System überlegst, mit dem du für jeden beliebigen Datensatz deine CRUD-Operationen AUTOMATISCH bekommst. Ein solches System ist die FOP-Programmiersprache. Beim FOP entwickelt man ein Datenschema und bekommt eine Oberfläche zum Manipulieren der Daten gratis dazu. Wenn du wissen willst, wie man FOP benutzt, wie man damit unheimlich schnell Web-Portale und komplexe Software-Projekte erstellt, dann abonniere diesen Podcast.
February 22, 2021
Folge 10 - Technische Schulden
Bei der Softwareentwicklung gibt es ein magisches Dreieck: Der Kunde will gleichzeitig Hohe Qualität, niedriges Budget, schnelle Fertigstellung. Es gibt ein geflügeltes Wort: Hohe Qualität, niedriges Budget, schnelle Fertigstellung - Das sind die 3 Eigenschaften, die du willst. Suche dir 2 davon aus. Bei technologischen Schulden entschied man sich für niedriges Budget und schnelle Fertigstellung unter Aufopferung der Qualität. Faktoren, die führen zu technischer Schuld führen können, sind: • Unwissenheit • Faulheit • Zeitdruck • Geldmangel • die bewusste Entscheidung, unreife Prototypen zu produzieren, um sie zu testen Technische Schulden drücken sich insbesondere durch schlecht strukturierte IT-Lösungen aus. Daraus folgen: • Sicherheitslücken • Nach Updates funktionieren einige Dinge nicht mehr • Neue Funktionen hinzuzufügen wird sehr teuer/aufwendig Technische Schulden muss man abbauen – aber nicht immer. Denn der Grund, warum man Technische Schulden überhaupt macht ist, dass das Projekt schneller voran geht. Oft weiß man nicht, ob der Kunde ein Feature später behalten oder wieder wegwerfen will. Auch will man die Zeit nicht direkt investiren, alles „ordentlich“ zu machen, da man noch genügend andere Sachen zu tun hat. Technologische Schulden fordern Zinsen, aber auch Zinseszinsen. Und genau um die Zinseszinsen soll es gehen: Ist eine Software oder ein IT-Projekt schlecht strukturiert, kann man den Fehler am Anfang noch einfach beheben. Je mehr darauf aufbaut, desto schwieriger wird es aber, die Fehler aus der Vergangenheit zu korrigieren. So entstehen zum Beispiel auf den Provisorien weitere Übergangslösungen und Hacks, die die Komplexität des IT-Projekts unheimlich in die Höhe treiben. Zu dem ursprünglichen Ziel, Zeit zu sparen und schnell nutzbare Ergebnisse haben, kommen nicht nur die Kosten des “Aufräumens” hinzu, sondern es werden komplett neue Systeme um das schlecht Strukturierte System herum gebaut, die im Falle einer Korrektur wieder obsolet werden – sprich: Verlust durch Abschreibung. Für den Entwickler können wir folgende Faustregel mitgeben: Bevor man ein System um eine Funktion erweitert, wird das System geprüft, ob es für diese neue Funktion geeignet ist oder umstrukturiert werden sollte. Das ist zwar etwas mehr Arbeit, während der Kunde auf die schnelle Umsetzung seines Features wartet. Es lohnt sich aber: Der Implementierungsaufwand für die neue Funktion sinkt drastisch, wenn das darunterliegende System besser geeignet ist. Veranschaulicht heißt das: Bevor man neue technologische Schulden aufnimmt, muss man die alten Kredite abbezahlen Damit man Herr über seine Schulden bleibt, sollte man diese in einer Art „technischem Schuldenbuch“ dokumentieren. Dazu eignen sich prinzipiell zwei Techniken: In der ersten Technik schreibst du alles, was du noch nicht implementieren willst, als Kommentar in den Code: Ausgelassene Sicherheitsprüfungen mit /* TODO: sanitizen */ - an eine Klasse konkrete Infos: TODO: Diese Klasse mit Klasse Y zu gemeinsamer Klasse Z zusammenführen. In der zweiten Technik nutzt du dein Issue-Tracking-System, um die TODOs zu organisieren. Wenn du ganz schlau bist, kombinierst du beide Techniken: Im Code machst du einen Kommentar TODO: #1337: Refactorn und unter der 1337 hinterlegst du dann genaue Beschreibungen, was du dort genau weggelassen hast. Wenn dich diese Sachen weitergebracht haben, dann abonniere diesen Podcast.
February 15, 2021
Folge 9 - Kompression Von Quellcode
Quellcode kann unheimlich redundant sein. Wir haben bereits in einer älteren Folge darüber gesprochen, dass man durch geschicktes Refactoring Code-Duplikation entfernen kann. Quellcode ist Information. Wenn ich in der Lage bin, ein- und dasselbe Programm einmal mit 1000 Zeilen Code und einmal mit 300 Zeilen Code zu implementieren, dann hat das Programm nur einen Informationsgehalt von 300 Zeilen! Kurzer Code ist schön. Die restlichen 700 Zeilen verkomplizieren das Programm nur. Dabei gehe ich von sauber geschriebenem Code aus und zähle die Kommentare nicht als Codezeilen mit. Es geht rein um die Anzahl an Anweisungen, Ausdrücken, Schleifen und Funktionen im Code. In der Folge 4 „Kurzer Code ist schön“ habe ich bereits angedeutet, dass zum einen weniger Code weniger Probleme bedeutet: Weniger Bugs, weniger Code zu warten, weniger Code zu lesen. Außerdem habe ich eine Technik vorgestellt, mit der man durch ein Zwischen-Interface aus m*n Codezeilen m+n Codezeilen umschreiben kann. Diesmal geht es um eine andere Technik: Projektübergreifendes Refactoring. Projektübergreifendes Refactoring ist das mächtigste Werkzeug, wenn man jedes einzelne Projekt mit minimalem Aufwand umsetzen will.
13 total episodes available
Deep-dive analytics for Pro-Grammierer-Podcast
Frequently asked questions
Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.
- What is Pro-Grammierer-Podcast?
- How often does this podcast release new episodes?
This podcast updates daily.
- Where can I listen to this podcast?
This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.
- Does this podcast accept guests?
No, this podcast does not typically feature guests.
Legal Disclaimer
Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.
All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.
We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.
While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.
By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.