Vadym Yaroshchuk
Ich bin ein Software-Ingenieur mit 6 Jahren Erfahrung, hauptsächlich durch persönliche Projekte. Obwohl meine berufliche Erfahrung begrenzt ist, habe ich praktische Fähigkeiten durch die Arbeit an verschiedenen Anwendungen erworben, wobei mein Schwerpunkt auf Kotlin Multiplatform und der Entwicklung von Client-Server-Anwendungen liegt. Ich löse gerne komplexe Probleme, vereinfache Code und teile mein gelerntes Wissen durch Lehren und Schreiben.
Allgemeine Informationen
- ☕️ Englisch (B2+)
- 🇩🇪 Deutsch (B1)
- 🇺🇦 Ukrainisch (Muttersprache)
- 🏳️ Russisch (Muttersprache)
- Kotlin/Java
- PHP
- TS/JS
- Python
- Android
- iOS
- Web
- JVM (Desktop, Backend)
Notizen
Fehlschläge, die wir nicht korrekt modellieren
Wir behandeln Exceptions, null und Results oft als bloße Werkzeuge, die wir nach Stil oder Gewohnheit austauschen. Aber jede Entscheidung, die du triffst – einen Fehler zu werfen, einen sicheren Typ zurückzugeben oder stillschweigend zu scheitern – definiert eigentlich einen versteckten Vertrag mit dem Aufrufer. Dieser Artikel untersucht, warum es beim 'Error Handling' eigentlich um das Management gebrochener Versprechen geht und wie man aufhört, seine Nutzer (und sich selbst) darüber anzulügen, was der Code tatsächlich tut.
Semantische Typisierung, die wir ignorieren
Wir haben alle schon auf eine Funktionssignatur gestarrt, unsicher, was sie eigentlich erwartet, nur um Zeit damit zu verbringen, Implementierungsdetails zu durchforsten, weil die Dokumentation fehlte. Aber was, wenn das Problem nicht die Dokumentation ist, sondern wie wir den Code selbst schreiben? Diese Untersuchung der semantischen Typisierung in Kotlin betrachtet, wie man von einer "das ist nur ein String"-Mentalität zu einem "das ist ein Konzept"-Ansatz übergeht und unterbewusste Designgewohnheiten in klare Regeln für den Aufbau besserer, selbstdokumentierender Domänenmodelle verwandelt.
Paketbenennung, um die sich niemand kümmert (aber sollte)
Haben Sie sich jemals gefragt, warum Paketnamen im Code oft keine Rolle spielen – aber vielleicht sollten sie es? Bis vor kurzem konnte ich, abgesehen von unterbewussten Entscheidungen, nicht vollständig erklären, wann es sinnvoll ist, ein Paket zu erstellen und wann nicht. Als Ergebnis habe ich versucht, eine aussagekräftige Erklärung und Regeln für diese Angelegenheit zu entwerfen.
