Вадим Ярощук
Я інженер-програміст із 6-річним досвідом, отриманим здебільшого завдяки власним проєктам. Хоча мій комерційний досвід обмежений, я здобув практичні навички, працюючи над різними додатками, зосереджуючись на Kotlin Multiplatform та клієнт-серверній розробці. Мені подобається вирішувати складні задачі, спрощувати код та ділитися тим, що я вивчив, через навчання та написання статей.
Загальна інформація
- ☕️ Англійська (B2+)
- 🇩🇪 Німецька (B1)
- 🇺🇦 Українська (Рідна)
- 🏳️ Російська (Рідна)
- Kotlin/Java
- PHP
- TS/JS
- Python
- Android
- iOS
- Web
- JVM (Desktop, Backend)
Нотатки
Помилки, які ми моделюємо неправильно
Ми часто ставимося до ексепшнів, null та Result як до простих інструментів, змінюючи їх залежно від стилю чи звички. Але кожен твій вибір — кинути помилку, повернути безпечний тип чи мовчки впасти — насправді визначає прихований контракт із тим, хто викликає код. Ця стаття досліджує, чому 'обробка помилок' — це насправді про управління порушеними обіцянками, і як перестати брехати своїм користувачам (і собі) про те, що насправді робить твій код.
Семантична типізація, яку ми ігноруємо
Ми всі дивилися на сигнатуру функції, не впевнені, що вона насправді очікує, лише щоб витратити час на копання в деталях реалізації, тому що документація була відсутня. Але що, якщо проблема не в документації, а в тому, як ми пишемо сам код? Це дослідження семантичної типізації в Kotlin розглядає, як перейти від менталітету "це просто рядок" до підходу "це концепція", перетворюючи підсвідомі звички проєктування на чіткі правила для побудови кращих, самодокументованих доменних моделей.
Іменування пакетів, про яке ви не дбаєте (але повинні)
Ви коли-небудь замислювалися, чому назви пакетів у коді часто не мають значення — але, можливо, повинні? Донедавна, окрім підсвідомих рішень, я не міг повністю пояснити, коли є сенс створювати пакет, а коли ні. Як результат, я спробував скласти змістовне пояснення та правила щодо цього питання.
