Иногда складывается ощущение, что сторонники Kotlin начали чувствовать давление со стороны Flutter, и из-за этого начинают топить за любимый стек. Синдром утёнка?
В статье есть несколько неточностей, но на них указали в комментариях ниже.
Насчёт специфики мобильных платформ - я скорее не соглашусь, чем соглашусь. Да, команда из Android и iOS разработчиков идеальна, но это совершенно необязательно.
Я как-то фрилансил, и был проект, в котором были сканирование QR-кодов камерой, работа с Bluetooth (соединение с аппаратным сканером QR-кодов и RFID меток), работа с сетью, локальное хранение данных. Изначально клиент хотел только Android-приложение, но я решил сделать всё на Flutter, для практики. Тестировал только Android. Когда я сдавал проект, клиент захотел и iOS, и как удачно это всё было на Flutter'е, я просто сделал сборку iOS (предварительно настроив используемые библиотеки для платформы, это заняло до 30 минут) и отправил клиенту.
Знание специфики работы платформы необходимо только при разработке своей кросс-платформенной библиотеки, тесно работающей с платформой, что требуется не так уж и часто.
А Hot Reload вообще перевернул с ног на голову. Так больно ждать сборку Android-проекта даже 1 минуту (а некоторые проекты собираются значительно дольше) после незначительных изменений, когда можно нажать "Сохранить" и наблюдать изменения спустя секунду.
Т.е. не имея сколько бы то ни было релевантного опыта с данным подходом Вы его критикуете? Вам же отвечают люди, которые работают с TDD и довольно успешно. Будь я читатель со стороны, я бы прислушался не к Вам, а к ним.
Вы повесили ярлык «ритуал» и пытаетесь всё показывать в отрицательном контексте.
>адепты тдд никогда не обосновывают почему делают то, что делают — только в очередной раз повторяют заученный цикл
Но ведь неправда! Вам уже несколько раз указали, что сталкивались со случаями, когда новый тест, который, по идее, должен падать, проходит. Если бы сначала было написано поведение, под которое был написан этот тест, а тест, оказывается, проходит и без нового кода, значит тест был написан с ошибкой, и по факту он ничего не тестирует, и если новый код ведёт себя неправильно, то программист об этом узнает уже от тестировщика или конечного пользователя. И не надо тут опять это «надо включать голову». Все делают ошибки, даже очень тривиальные.
Это Вы почему-то всеми правдами и неправдами пытаетесь отстоять своё очень субъективное мнение о ненужности TDD. Лично мне оно жизнь спасало не раз.
Хороший комментарий. У Koin есть возможность провалидировать граф. Но для этого Koin создаёт каждую зависимость, что, с моей точки зрения, является костылём. С другой стороны, это работает и граф валидируется, пусть и не в compile time, а при прогоне соответствующего теста.
По Вашей просьбе добавил в конец статьи тот же пример на Dagger. Цель статьи не показать, что Koin лучше Dagger'а, а привести пример, что Service Locator можно использовать для Dependency Injection.
Иногда складывается ощущение, что сторонники Kotlin начали чувствовать давление со стороны Flutter, и из-за этого начинают топить за любимый стек. Синдром утёнка?
В статье есть несколько неточностей, но на них указали в комментариях ниже.
Насчёт специфики мобильных платформ - я скорее не соглашусь, чем соглашусь. Да, команда из Android и iOS разработчиков идеальна, но это совершенно необязательно.
Я как-то фрилансил, и был проект, в котором были сканирование QR-кодов камерой, работа с Bluetooth (соединение с аппаратным сканером QR-кодов и RFID меток), работа с сетью, локальное хранение данных. Изначально клиент хотел только Android-приложение, но я решил сделать всё на Flutter, для практики. Тестировал только Android. Когда я сдавал проект, клиент захотел и iOS, и как удачно это всё было на Flutter'е, я просто сделал сборку iOS (предварительно настроив используемые библиотеки для платформы, это заняло до 30 минут) и отправил клиенту.
Знание специфики работы платформы необходимо только при разработке своей кросс-платформенной библиотеки, тесно работающей с платформой, что требуется не так уж и часто.
А Hot Reload вообще перевернул с ног на голову. Так больно ждать сборку Android-проекта даже 1 минуту (а некоторые проекты собираются значительно дольше) после незначительных изменений, когда можно нажать "Сохранить" и наблюдать изменения спустя секунду.
Т.е. не имея сколько бы то ни было релевантного опыта с данным подходом Вы его критикуете? Вам же отвечают люди, которые работают с TDD и довольно успешно. Будь я читатель со стороны, я бы прислушался не к Вам, а к ним.
>адепты тдд никогда не обосновывают почему делают то, что делают — только в очередной раз повторяют заученный цикл
Но ведь неправда! Вам уже несколько раз указали, что сталкивались со случаями, когда новый тест, который, по идее, должен падать, проходит. Если бы сначала было написано поведение, под которое был написан этот тест, а тест, оказывается, проходит и без нового кода, значит тест был написан с ошибкой, и по факту он ничего не тестирует, и если новый код ведёт себя неправильно, то программист об этом узнает уже от тестировщика или конечного пользователя. И не надо тут опять это «надо включать голову». Все делают ошибки, даже очень тривиальные.
Это Вы почему-то всеми правдами и неправдами пытаетесь отстоять своё очень субъективное мнение о ненужности TDD. Лично мне оно жизнь спасало не раз.