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