Основная фишка модуля в том, что он собирается отдельно, за счёт этого ускоряется сборка Gradle при изменениях. Сложно представить сценарий, когда меняешь api, но не меняешь impl. Наоборот, конечно, частый случай, но ты серьезно собираешься экономить на пересборке нескольких интерфейсов?
Вот и выходит, что профита 0, а сложность проекта на ровном месте растёт. Проще по пакетам разложить нормально.
Нет четкого определния по грейдам, каждый понимает что-то свое. Как можно понять, что ты перешагнул ступень между Junior и Middle, между Middle и Senior? А еще есть Team lead - это Middle с административными функциями или Senior?
А еще можно другие грейды рассмотреть: Programmer, Developer, Software Engineer. Это как связать? Интуитивно разница понятна, но вот сформулировать проблемно.
На мой взгляд, курсы в статье больше для PM'а подходят.
Полагаю, что под доп. навыками имеется ввиду работу с особо опасными и технически сложными объектами - это как бы отдельная категория. Или, например, проектирование в определенных условиях: сейсмика, карсты, оползни, вечная мерзлота и т.д. Ничего такого сверхъестественного тут, конечно, нет, но если никогда не имел с такими вещами дело, то могут возникнуть трудности.
Меня интересует, каким вообще образом навыки коррелируют с зарплатой? С зарплатой могут как-то быть в связке решаемые задачи. Навык игры на гитаре, очевидно, никак не повлияет на грейды. Т.е. руководство компании должно обозначать то, что нужно отрабатывать сотрудникам.
Должно быть что-то типа такого. Приходит менеджер и вещает: "Так, дамы и господа, теперь мы на подсосе у администрации Краснодарского края. Нам нужна пара конструкторов со скиллом по кессонным фундаментам. Осваивайте и повысим зарплату".
Ок, я прочитал перевод документации с гугловского сайта.
Делал как-то раз с хранением настроек в DataStore. А давай ка я сохраню не примитивы, а объект. Ну а чо? Удобно же, современный фреймворк. После 1,5 часов собирания пазла из версий kotlin, kotlinCompiler, ksp, protobuf и compose, а также Gradle скриптов, оно всё таки завелось и корректно работало. Сижу потом и думаю: "А чем мне Shared preferences то не угодил? Ключ - значение, просто и надёжно, как топор."
В чём прикол делить модуль на подмодули api/impl?
Основная фишка модуля в том, что он собирается отдельно, за счёт этого ускоряется сборка Gradle при изменениях. Сложно представить сценарий, когда меняешь api, но не меняешь impl. Наоборот, конечно, частый случай, но ты серьезно собираешься экономить на пересборке нескольких интерфейсов?
Вот и выходит, что профита 0, а сложность проекта на ровном месте растёт. Проще по пакетам разложить нормально.
Нет четкого определния по грейдам, каждый понимает что-то свое. Как можно понять, что ты перешагнул ступень между Junior и Middle, между Middle и Senior? А еще есть Team lead - это Middle с административными функциями или Senior?
А еще можно другие грейды рассмотреть: Programmer, Developer, Software Engineer. Это как связать? Интуитивно разница понятна, но вот сформулировать проблемно.
На мой взгляд, курсы в статье больше для PM'а подходят.
И ни слова о Mutex или atomic... На корутинах словить race condition можно очень легко.
Полагаю, что под доп. навыками имеется ввиду работу с особо опасными и технически сложными объектами - это как бы отдельная категория. Или, например, проектирование в определенных условиях: сейсмика, карсты, оползни, вечная мерзлота и т.д. Ничего такого сверхъестественного тут, конечно, нет, но если никогда не имел с такими вещами дело, то могут возникнуть трудности.
Меня интересует, каким вообще образом навыки коррелируют с зарплатой? С зарплатой могут как-то быть в связке решаемые задачи. Навык игры на гитаре, очевидно, никак не повлияет на грейды. Т.е. руководство компании должно обозначать то, что нужно отрабатывать сотрудникам.
Должно быть что-то типа такого. Приходит менеджер и вещает: "Так, дамы и господа, теперь мы на подсосе у администрации Краснодарского края. Нам нужна пара конструкторов со скиллом по кессонным фундаментам. Осваивайте и повысим зарплату".
Ок, я прочитал перевод документации с гугловского сайта.
Делал как-то раз с хранением настроек в DataStore. А давай ка я сохраню не примитивы, а объект. Ну а чо? Удобно же, современный фреймворк. После 1,5 часов собирания пазла из версий kotlin, kotlinCompiler, ksp, protobuf и compose, а также Gradle скриптов, оно всё таки завелось и корректно работало. Сижу потом и думаю: "А чем мне Shared preferences то не угодил? Ключ - значение, просто и надёжно, как топор."