У них там отдельное окошко ада при попытке зарегистрироваться разработчиком и попытке опубликовать своё приложение на Android. Фото паспорта и фото кредитной карты, которое они просят прислать для верификации - это лишь вершина айсберга.
Про 15, 10 и 3 года - действительно не сходится, т.к. не стал писать про опыт до 1С и после Сбера. Добавил в статье, благодарю за то, что обратили внимание.
Рассказывал в 2023 про свой опыт, который был в 2019. Благодарю за ваш комментарий - внёс корректировку в статью. Это действительно было не очевидно, что я описываю прошлый опыт.
Про мышление технаря - возможно им действительно проще и не возникает сложности с выбором.
Про работу мозга полностью согласен и благодарю за подробное описание некоторых особеностей мышления.
По поводу единственного критерия "время" - не соглашусь. У меня не так. Возможно для кого-то время и постановка целей работает, но не для меня. Есть люди, которым важен результат. Мне важен процесс. Ведь работа - это часть жизни, и от качества того как я буду себя ощущать на работе - будет зависеть качество моей жизни. Но это также моё мнение, не претендую на истину.
Вариан "мне это просто нравится" у меня не прошёл, т.к. мне нравятся все 9 направлений, перечисленных в начале статьи. Как вариант я мог бы подбрасывать монетку. Но решил не доверять этот выбор случайности, а выбрать сам.
Как описание подхода к проектированию больших приложений - ок.
Как руководство к проектированию любой системы - нет, т.к. оторвано от реальной жизни, где бывают и маленькие проекты, и текучка кадров, и решения по слиянию/разделению приложений и прочее.
Например сейчас я занимаюсь проектом, который сначала сделали сложным (примерно как описано в статье) на миксе архитектур Clean+MVVM, потом другой разработчик пришёл и решил "упростить" переписав часть приложение в что-то вроде MVI. Я уже 3й разработчик и пытаюсь во всём этом разобраться. Мозг взрывается от смеси 2х архитектур. Если бы приложение было на чистом MVP или MVVM - то я мог бы стоящие передо мной задачи сделать за полчаса каждую. Но в итоге уже несколько дней сижу, пытаясь понять, как прогнать данные через несколько "слоёв" или "зон ответственности", чтобы оно корректно отработало. Ладно, я как мидл за недельку-другую разберусь в любой архитектуре и заставлю всё работать как надо. Но джун такой проект точно не потянет.
Я не первый раз вижу, что синьоры переусложняют архитектуру, чтобы соответствовать принципам SOLID, CLEAN и т.д., но забывают что этой архитектурой будут пользоваться джуны, которые могут и не понять как всё это работает. И если для больших приложений (банков, маркетплейсов и т.д.) это оправдано, т.к. разрабу дают обычно ограниченный модуль, в рамках которого он делает свои задачи. То для небольшого и среднего приложения такое усложнение архитектуры считаю избыточным. Для большинства проектов достаточно MVP/MVVM + Repository
В любом случае благодарю за статью - теперь понимаю чем руководствуются синьоры, делая такие сложные архитектуры.
Осталось подождать ещё 120 лет, чтобы во всех лестницах добавили более пологую полосу для качения, а так же во все бордюры добавили частый сьезд, а также чтобы везде рядом с брусчатской/плиткой добавили ровную дорожку для использования колёс.
Пару лет назад помогал колясочнице доехать в Мск от кинотеатра Октябрьский до Гагаринского переулка... Это был не простой квест даже для 2х сопровождающих мужчин.
Ну и периодически приходится с чемоданом ехать от вокзалов на метро с пересадками и многие станции не предназначены для использования чемоданов с колесами (хоть формально там сделаны полозья, которыми невозможно пользоваться), приходится часто нести чемодан на руках.
Простые вещи и в Swift/Kotlin делаются просто. Например тут можно было бы остановиться на статическом номере и вручную его менять когда нужно. Но хотелось именно автоматизировать процесс, чтобы забыть о этих номерах версий. Именно тогда и вылезли описанные в статье подводные камни.
Да всё нормально. Я сначала хотел на средний уровень разработчиков поставить этот пост. Но в редакции Хабра мне порекомендовали поставить для начинающих. В принципе, если бы когда я начинал разработку попал на эту статью - она бы мне помогла начать.
Надеюсь статья получилась не слишком сложной для начинающих.
Я сейчас параллельно учусь в школе 21 (от Сбера) и как раз один из текущих проектов, это проект CI/CD, где бонусным заданием как раз надо создать CI/CD бота. Так что у меня скоро появится такой бот и прикручу его к своим проектам.
Мы сборки под Firebase не делали. У нас у всех проектов свой бекенд и публикуем сразу в AppStore/GooglePlay. Тестировщики тестируют на своих девайсах или эмуляторах.
Если вы делаете сборки с разных веток, то это не значит, что одна версия более свежая. Это значит что у вас 2 совершенно разные версии. Соответственно для тестирования нужны совершенно разные номера версий. Как вариант, после номер версии ещё выводить хеш-код коммита, его не сложно добавить. Но лично мне так не нравится, выглядит "не красиво" - хотя в сторах видел много приложений, у которых в номере версии указывается хеш-код коммита.
Про Kotlin + Compose + kts и SwiftUI, планировал следующую статью в зависимости от того, как эта зайдёт. Спасибо за совет про toml-файл - когда буду готовить следующую статью, то посмотрю на этот файл.
Наоборот - версию выставлять через гит практично. Но для этого должна быть корректно выстроена работа с гит. Мы выкладывали в TestFlight/тестовый Google Play версии только с ветки "rc" - наверно напишу отдельную статью про git, GitHub, GitLab - у начинающих часто с ними проблемы... Это позволит версиям быть последовательно, а не хаотично, и всегда у сборки будет новый номер.
Да, можно поставить, но лично для меня это не принципиально. Скорость сборки проектов актуальна для больших проектов, когда важна каждая миллисекунда. Для пет-проектов и небольших проектов, считаю не тем, на что нужно обращать внимание.
Про тесты согласен. Пет-проекты обычно пишутся без тестов. И это также более актуально для больших проектов. С fastline к сожалению не довелось работать.
Благодарю за комментарии и подробные предложения по редактуре. Как буду немного посвободней - внесу предложенные изменения в статью.
Статья писалась для начинающих, для тех, кто ни разу не пробовал React и хотел бы разобраться с ним. Да, за основу я взял официальную документацию, но там многие моменты не были расписаны или наоборот было много воды. Хотелось сжать информацию, чтобы с основами можно было ознакомиться за 10 минут, а не за день (сколько мне потребовалось на изучение документации).
То что статья кажется слабой для мидлов и синьоров - возможно. Но она писалась не для них, а для трейни и джунов, которым интересно попробовать React и решить хотят они дальше его изучать или нет.
И спасибо за ссылку - почитал, там действительно всё подробно описано.
Так у каждого свои кружочки. В статье я показал мои кружочки. В моих нет embedded. Кстати сегодня выступал с этой темой на мероприятии от МТС и понял, что мне снова надо рисовать кружочки, и выбирать на чём сконцентрироваться)))
3 года назад ходил в вашу компанию на собеседование (правда по Android). Тогда я был джуном, а ваша компания искала только мидлов/синьоров и мне отказали. Прошло 3 года, теперь я мидл/синьор/тимлид и сам ищу себе стажёров, также как и вы))) Успехов со стажёрами, коллега :)
У них там отдельное окошко ада при попытке зарегистрироваться разработчиком и попытке опубликовать своё приложение на Android. Фото паспорта и фото кредитной карты, которое они просят прислать для верификации - это лишь вершина айсберга.
Про диаграмму Вена - да, у меня тогда был сложный период в жизни, и я умею в самоиронию)
Про 15, 10 и 3 года - действительно не сходится, т.к. не стал писать про опыт до 1С и после Сбера. Добавил в статье, благодарю за то, что обратили внимание.
Рассказывал в 2023 про свой опыт, который был в 2019. Благодарю за ваш комментарий - внёс корректировку в статью. Это действительно было не очевидно, что я описываю прошлый опыт.
Про мышление технаря - возможно им действительно проще и не возникает сложности с выбором.
Про работу мозга полностью согласен и благодарю за подробное описание некоторых особеностей мышления.
По поводу единственного критерия "время" - не соглашусь. У меня не так. Возможно для кого-то время и постановка целей работает, но не для меня. Есть люди, которым важен результат. Мне важен процесс. Ведь работа - это часть жизни, и от качества того как я буду себя ощущать на работе - будет зависеть качество моей жизни. Но это также моё мнение, не претендую на истину.
Вариан "мне это просто нравится" у меня не прошёл, т.к. мне нравятся все 9 направлений, перечисленных в начале статьи. Как вариант я мог бы подбрасывать монетку. Но решил не доверять этот выбор случайности, а выбрать сам.
Как описание подхода к проектированию больших приложений - ок.
Как руководство к проектированию любой системы - нет, т.к. оторвано от реальной жизни, где бывают и маленькие проекты, и текучка кадров, и решения по слиянию/разделению приложений и прочее.
Например сейчас я занимаюсь проектом, который сначала сделали сложным (примерно как описано в статье) на миксе архитектур Clean+MVVM, потом другой разработчик пришёл и решил "упростить" переписав часть приложение в что-то вроде MVI. Я уже 3й разработчик и пытаюсь во всём этом разобраться. Мозг взрывается от смеси 2х архитектур. Если бы приложение было на чистом MVP или MVVM - то я мог бы стоящие передо мной задачи сделать за полчаса каждую. Но в итоге уже несколько дней сижу, пытаясь понять, как прогнать данные через несколько "слоёв" или "зон ответственности", чтобы оно корректно отработало. Ладно, я как мидл за недельку-другую разберусь в любой архитектуре и заставлю всё работать как надо. Но джун такой проект точно не потянет.
Я не первый раз вижу, что синьоры переусложняют архитектуру, чтобы соответствовать принципам SOLID, CLEAN и т.д., но забывают что этой архитектурой будут пользоваться джуны, которые могут и не понять как всё это работает. И если для больших приложений (банков, маркетплейсов и т.д.) это оправдано, т.к. разрабу дают обычно ограниченный модуль, в рамках которого он делает свои задачи. То для небольшого и среднего приложения такое усложнение архитектуры считаю избыточным. Для большинства проектов достаточно MVP/MVVM + Repository
В любом случае благодарю за статью - теперь понимаю чем руководствуются синьоры, делая такие сложные архитектуры.
Осталось подождать ещё 120 лет, чтобы во всех лестницах добавили более пологую полосу для качения, а так же во все бордюры добавили частый сьезд, а также чтобы везде рядом с брусчатской/плиткой добавили ровную дорожку для использования колёс.
Пару лет назад помогал колясочнице доехать в Мск от кинотеатра Октябрьский до Гагаринского переулка... Это был не простой квест даже для 2х сопровождающих мужчин.
Ну и периодически приходится с чемоданом ехать от вокзалов на метро с пересадками и многие станции не предназначены для использования чемоданов с колесами (хоть формально там сделаны полозья, которыми невозможно пользоваться), приходится часто нести чемодан на руках.
Простые вещи и в Swift/Kotlin делаются просто. Например тут можно было бы остановиться на статическом номере и вручную его менять когда нужно. Но хотелось именно автоматизировать процесс, чтобы забыть о этих номерах версий. Именно тогда и вылезли описанные в статье подводные камни.
Да всё нормально. Я сначала хотел на средний уровень разработчиков поставить этот пост. Но в редакции Хабра мне порекомендовали поставить для начинающих. В принципе, если бы когда я начинал разработку попал на эту статью - она бы мне помогла начать.
Надеюсь статья получилась не слишком сложной для начинающих.
Благодарю, изучу этот проект позже https://github.com/android/nowinandroid
Я сейчас параллельно учусь в школе 21 (от Сбера) и как раз один из текущих проектов, это проект CI/CD, где бонусным заданием как раз надо создать CI/CD бота. Так что у меня скоро появится такой бот и прикручу его к своим проектам.
Да, потому что у вас видимо не маленький проект. А я пишу как раз для начинаюших, у кого ещё нет CI/CD и прочего)
Круто. Тоже планировал бота написать, но пока руки до этого не дошли.
Мы сборки под Firebase не делали. У нас у всех проектов свой бекенд и публикуем сразу в AppStore/GooglePlay. Тестировщики тестируют на своих девайсах или эмуляторах.
Для фиче-веток можно отдельные теги вводить ;)
Если вы делаете сборки с разных веток, то это не значит, что одна версия более свежая. Это значит что у вас 2 совершенно разные версии. Соответственно для тестирования нужны совершенно разные номера версий. Как вариант, после номер версии ещё выводить хеш-код коммита, его не сложно добавить. Но лично мне так не нравится, выглядит "не красиво" - хотя в сторах видел много приложений, у которых в номере версии указывается хеш-код коммита.
Про Kotlin + Compose + kts и SwiftUI, планировал следующую статью в зависимости от того, как эта зайдёт. Спасибо за совет про toml-файл - когда буду готовить следующую статью, то посмотрю на этот файл.
Наоборот - версию выставлять через гит практично. Но для этого должна быть корректно выстроена работа с гит. Мы выкладывали в TestFlight/тестовый Google Play версии только с ветки "rc" - наверно напишу отдельную статью про git, GitHub, GitLab - у начинающих часто с ними проблемы... Это позволит версиям быть последовательно, а не хаотично, и всегда у сборки будет новый номер.
Да, можно поставить, но лично для меня это не принципиально. Скорость сборки проектов актуальна для больших проектов, когда важна каждая миллисекунда. Для пет-проектов и небольших проектов, считаю не тем, на что нужно обращать внимание.
Про тесты согласен. Пет-проекты обычно пишутся без тестов. И это также более актуально для больших проектов. С fastline к сожалению не довелось работать.
Благодарю за комментарии и подробные предложения по редактуре. Как буду немного посвободней - внесу предложенные изменения в статью.
Статья писалась для начинающих, для тех, кто ни разу не пробовал React и хотел бы разобраться с ним. Да, за основу я взял официальную документацию, но там многие моменты не были расписаны или наоборот было много воды. Хотелось сжать информацию, чтобы с основами можно было ознакомиться за 10 минут, а не за день (сколько мне потребовалось на изучение документации).
То что статья кажется слабой для мидлов и синьоров - возможно. Но она писалась не для них, а для трейни и джунов, которым интересно попробовать React и решить хотят они дальше его изучать или нет.
И спасибо за ссылку - почитал, там действительно всё подробно описано.
Так у каждого свои кружочки. В статье я показал мои кружочки. В моих нет embedded.
Кстати сегодня выступал с этой темой на мероприятии от МТС и понял, что мне снова надо рисовать кружочки, и выбирать на чём сконцентрироваться)))
3 года назад ходил в вашу компанию на собеседование (правда по Android). Тогда я был джуном, а ваша компания искала только мидлов/синьоров и мне отказали. Прошло 3 года, теперь я мидл/синьор/тимлид и сам ищу себе стажёров, также как и вы))) Успехов со стажёрами, коллега :)