Вадим Ярощук
Я інженер-програміст та архітектурний ентузіаст із Мюнхена. Найбільше мене цікавить системний дизайн та екосистема Kotlin — особливо ті неочевидні структурні виклики, які часто залишаються поза увагою. Тут я досліджую, як будувати надійне програмне забезпечення: через чіткі контракти, свідоме проектування та код, що не потребує зайвих пояснень.
Коротко про себе
Нотатки
Помилки, які ми моделюємо неправильно
Ми часто ставимося до ексепшнів, null та Result як до простих інструментів, змінюючи їх залежно від стилю чи звички. Але кожен твій вибір — кинути помилку, повернути безпечний тип чи мовчки впасти — насправді визначає прихований контракт із тим, хто викликає код. Ця стаття досліджує, чому 'обробка помилок' — це насправді про управління порушеними обіцянками, і як перестати брехати своїм користувачам (і собі) про те, що насправді робить твій код.
Семантична типізація, яку ми ігноруємо
Ми всі дивилися на сигнатуру функції, не впевнені, що вона насправді очікує, лише щоб витратити час на копання в деталях реалізації, тому що документація була відсутня. Але що, якщо проблема не в документації, а в тому, як ми пишемо сам код? Це дослідження семантичної типізації в Kotlin розглядає, як перейти від менталітету "це просто рядок" до підходу "це концепція", перетворюючи підсвідомі звички проєктування на чіткі правила для побудови кращих, самодокументованих доменних моделей.
Іменування пакетів, про яке ви не дбаєте (але повинні)
Ви коли-небудь замислювалися, чому назви пакетів у коді часто не мають значення — але, можливо, повинні? Донедавна, окрім підсвідомих рішень, я не міг повністю пояснити, коли є сенс створювати пакет, а коли ні. Як результат, я спробував скласти змістовне пояснення та правила щодо цього питання.
