Человек работает в компании А и получает за 8 часов работы, из них 4 часа он работает в компании Б, а компании А говорит что работал 8. Его никак не проверить. Сейчас дофига таких.
Бизнес пока еще не просек про ребят на удаленке, которые работают на 2х работах. Содержать удаленного работника, который за твой деньги работает на другой бизнес оч круто .)
Если у вас есть более хорошее название для класса, метода, то надо в пул реквесте сразу и предложить его, а не заставлять человека угадывать, что вы от него хотите. Он к вам в голову не залезет и на работу ходит не в загадки играть.)
Читая эту статью можно подумать будто в проектах покрытами тестами не копится тех долг. А сопровождение тестов тоже бесплатно и не затрачивает времени на разработку, когда тесты реагируют на каждое изменение и ломаются.
И чрезмерное размазывание архитектуры по слоям не тратит времени ни на проектирование, ни на сопровождение, если у вас нет четкой договоренностей, регламентов что за что отвечает .)
Ставить под сомнение что-то тоже нормально. Это можно выработать новый правильный, хороший подход, который подходит вашей компании — проекту.
А вот быть идиалистом и перфекционистом оч спорно, можно тратить кучу времени на то, что не будет нужно или вообще выкинут. Оч зависит от компании и целей ее разработки, что вам нужно? Быстрый mvp или оч качественный продукт без сбоев.
Ну и закреплять то, что у вас в компании надо внутренним регламентом компании, а не статьями на хабре.
Очень много минусов. За простотой скрыто понимание как там работает внутри.
Store монолит. нельзя отдельно протестировать actor, reducer.
К стору также нужно обязательно аттачить view, что также сказывается на тестировании. Нельзя к нему приаттачить TestObservable какой нибудь и протестировать смену стейтов.
В результате теряется главный плюс MVi, слабосвязанность и хорошая тестируемость отдельных компонентов.
EventBus желательно использовать только если все приложение имеет какое то состояние и все приложение может его слушать и при этом лучше подписываться на бродкасты приложения.
Размазывать синглтон типа отто по всему приложению, потом оттираться замучаетесь.
Для 2 отдельных компонентов то сервис с подпиской и лучше, это их личная зависимость.
Каждый знает, что вот зависит от такого сервиса, вполне тестируемо, подменяемо.
Всегда радует, когда badoo пишет про Kotlin Multiplatform. Сразу появляется надежда на MVICore Multiplatform. )
А то пока приходится пользоваться своим кроссплатформенным велосипедом, который хоть и едет, но не такой красивый.
Честно говоря, вы не объяснили, что вам не хватило в предыдущей реализации и что именно вы решили дописывать. Поэтому статья сразу становится непонятной.
Он работает в обоих компаниях за деньги, причем компания А теряет 50 процентов от его результативности, платя за все 100 процентов.
Токсичное поведение похоже уже норма в айти.
И чрезмерное размазывание архитектуры по слоям не тратит времени ни на проектирование, ни на сопровождение, если у вас нет четкой договоренностей, регламентов что за что отвечает .)
Ставить под сомнение что-то тоже нормально. Это можно выработать новый правильный, хороший подход, который подходит вашей компании — проекту.
А вот быть идиалистом и перфекционистом оч спорно, можно тратить кучу времени на то, что не будет нужно или вообще выкинут. Оч зависит от компании и целей ее разработки, что вам нужно? Быстрый mvp или оч качественный продукт без сбоев.
Ну и закреплять то, что у вас в компании надо внутренним регламентом компании, а не статьями на хабре.
Разве управлять самим состоянием экрана не удобней, чем доверять его Navigation Component-у? ) Там и миграция на композ будет потом легкой .)
Store монолит. нельзя отдельно протестировать actor, reducer.
К стору также нужно обязательно аттачить view, что также сказывается на тестировании. Нельзя к нему приаттачить TestObservable какой нибудь и протестировать смену стейтов.
В результате теряется главный плюс MVi, слабосвязанность и хорошая тестируемость отдельных компонентов.
Размазывать синглтон типа отто по всему приложению, потом оттираться замучаетесь.
Для 2 отдельных компонентов то сервис с подпиской и лучше, это их личная зависимость.
Каждый знает, что вот зависит от такого сервиса, вполне тестируемо, подменяемо.
Далее работаешь также как и с остальными объектами экрана
А то пока приходится пользоваться своим кроссплатформенным велосипедом, который хоть и едет, но не такой красивый.
Честно говоря, вы не объяснили, что вам не хватило в предыдущей реализации и что именно вы решили дописывать. Поэтому статья сразу становится непонятной.
Просто сейчас много людей с курсиков, которые курсики закончили, а думать своей головой еще не научились. Таких не берут.