TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #721 · 26.12

Почему я люблю языки с сильной системой типов, проверяемой статическим анализом кода — хорошо написанная программа является своей собственной спецификацией и позволяет выражать через язык программирования законы существования предметной области. Когда-то давно я писал на ActionScript. Там была система типов, но вот десериализация JSON'ов по-умолчанию была в какой-то общий Object, к полям которого нужно было обращаться ["по_строковому_имени"]. В один момент мне потребовалось написать что-то на C#, который я совсем не знал, я стал гуглить, как десериализовать JSON, и с удивлением обнаружил кучу советов заранее объявить класс со всеми нужными полями и десериализовать в него. "Какой ужас!", — подумал я тогда, — "Это же дико неудобно! А если я не знаю полей JSON? А если их много? Отвратительный язык!" Теперь то я прекрасно понимаю, что JSON это контракт, и что правильная десериализация только такая и должна быть, и что в хорошем API в одном поле никогда не бывает данных принципиально разных типов, и так далее. Нет, если вы набиваете вечерами пет-проект или сидите бессонную ночь на хакатоне, нет ничего плохого в том, чтобы взять простой язык с динамическими типами вроде JavaScript или Python, не требующий описывать данные. Но вот в энтерпрайзе, особенно когда над одним проектом работает много людей (а бывает это очень часто) — хорошее использование системы типов убережёт разработчиков от огромного количества ошибок, будет бить их по рукам, когда они пытаются сделать что-то не то, и будет подсказывать, когда они не уверены в чём-то. С помощью статической типизации можно на уровне кода обозначить правила, по которым ведёт себя предметная область вашей программы в реальном мире. Разработчику не только будет сложно их нарушить, но он ещё и станет узнавать какие-то вещи, которые мог не знать раньше. Например, если мы делаем медицинскую CRM, и больница заводит новых пациентов только тогда, когда знает их группу крови, мы можем объявить тип "Пациент" (или, если точнее, "Карта пациента") и запретить создавать экземпляры этого типа, не передав в конструктор группу крови (которая, в свою очередь, тоже является типом, вероятнее всего ValueObject'ом). Если новый программист пришёл в проект, он, во-первых, не сможет записать в БД некорректную карту пациента. Понятно, мы не учитываем случаи, когда новый программист переделывает модели предметной области — это будет хорошо видно на кодревью. А, во-вторых, даже если ему никто не сказал, что пациенты должны быть с группой крови, он узнает это из кода. И уже будет понимать, что в тех процессах реальной жизни, которые он описывает кодом, карта пациента создаётся только при наличии группы крови. А, значит, нужно искать какой-то способ сначала эту группу крови получить, и только потом создавать карту. Программирование моделирует реальный процесс. В настоящей работе даже на языках с типами, конечно, без должного контроля можно написать что угодно. Нужна управленческая воля, компетентность руководства, понимание опасности техдолга, в идеале отдельные должности для архитекторов, опытные лиды и старшие разработчики. Но когда всё это есть, можно отсекать много проблем ещё на старте и проще погружать новичков. #dev

Hashtags

Резултати

Намерени 4 подобни публикации

Търсене: #hilt

当前筛选 #hilt清除筛选
Android Broadcast

@android_broadcast · Post #9806 · 18.01.2026 г., 12:22

🤯Dagger Hilt блокирует переход на AGP 9.0 UPD. 21 января вышел Dagger 2.59 с поддержкой AGP Android Gradle Plugin 9.0 официально зафиксировал новый стабильный конфигурационный API (вышла стабильная версия с релизом AS Otter FD 3) — это одно из самых значимых изменений в инфраструктуре Android и Kotlin Multiplatform за последние годы. Цели понятны и правильные лучше работа с кэшем и общая скорость сборок. Подробнее про все изменения я писал в отдельном посте Google несколько релизов подряд аккуратно готовил экосистему к этому переходу, заранее добавив новый API и дав время авторам плагинов адаптироваться. Но на практике всё упирается в плагины. Я столкнулся с тем, что Gradle-плагин Dagger Hilt до сих пор использует старую модель конфигурации и несовместим с новым DSL из AGP 9.0. В результате проект нельзя перевести на новую версию без отключения Hilt или включения режим совместимости. Иронично, что именно официальный инструмент от Google сейчас становится блокером для обновления. Да, в AGP оставили compatibility-флаги, позволяющие продолжать сборку по старым правилам. Это спасает проекты от немедленного падения, но полностью отключает все ключевые преимущества AGP 9.0 — configuration cache, ускоренную конфигурацию и новую модель плагинов. 💬 Вы уже пробовали миграцию на AGP 9.0? Что блокирует? Делитесь в комментариях мнением. UPD. По заявлениям подписчиков также есть проблемы в работе KAPT и KSP #Android#AndroidDev#Gradle#Dagger#Hilt

Android Broadcast

@android_broadcast · Post #9550 · 08.10.2025 г., 11:50

🤖 Если вы искали альтернативу Dagger/Hilt, но с поддержкой Kotlin Multiplatform, то как раз вышла свежая версия Koin Annotations, которая значительно упрощает миграцию! #dagger#hilt#koin

Android Broadcast

@android_broadcast · Post #8901 · 05.04.2025 г., 10:43

🤖Альтернативный способ обработке one-off событий из ViewModel (EN, 10м) В статье рассказывается в чем сложность с обработкой одноразовых событий, которые надо передать из ViewModel в UI. Автор рассматривает способ через callback интерфейс в конструкторе ViewModel @HiltViewModel class MyViewModel @Inject constructor( // inject the interface private val toastMessages: ToastMessages, ) : ViewModel() { fun doSomething() { viewModelScope.launch { try { // execute async operation here } catch (e: CustomException) { // initiate a one-off event toastMessages.showToast(e.localizedMessage) } } } } 🔗 Альтернативная ссылка на статью #android#viewmodel#dagger#hilt

Android Broadcast

@android_broadcast · Post #9569 · 17.10.2025 г., 07:58

‼️Не тяните зависимости из графа сразу! Одна из частых ошибок при использовании DI — получать все зависимости из графа сразу (например, в конструкторе класса). Так делать не стоит 😬 Получение зависимости из графа — это каскадный процесс, и он должен выполняться только в момент использования. Поэтому я всегда рекомендую инжектить зависимости для Dagger/Hilt через Lazy (не путайте с kotlin.Lazy) или Provider. class ViewModel @Inject constructor( // Зависимость получается из графа сразу при создании private val useCase: DataUseCase, // Получаем зависимость из графа каждый раз при обращении Provider.get() private val useCaseFactory: Provider<DataUseCase>, // Получаем зависимость из графа при первом обращении // и затем она кэшируется в Lazy объекте private val useCaseLazy: Lazy<DataUseCase>, ) 💡 Чтобы перейти на Lazy без боли в существующем коде — можно использовать делегаты свойств в Kotlin: // Вариант использования без Lazy class ViewModel @Inject constructor( private val useCase: DataUseCase ) // Миграция на Lazy без потери API совместимости class ViewModel @Inject constructor( useCaseFactory: Lazy<DataUseCase>, ) { private val useCase: DataUseCase by useCaseFactory } И небольшой хелпер, чтобы это работало красиво 👇 // Функция расширения для использования property делегата operator fun <T> Lazy<T>.getValue(thisRef: T, property: KProperty<*>): T = get() Таким образом, вы снижаете нагрузку на DI граф, откладываете инициализацию и избегаете ненужных каскадов при старте компонентов. #di#dagger#hilt#лучшиепрактики