Про 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 года, теперь я мидл/синьор/тимлид и сам ищу себе стажёров, также как и вы))) Успехов со стажёрами, коллега :)
Бэкенд — это, наверное, одна из немногих сфер, где сейчас популярно несколько языков. Тут придётся определиться более точно со сферой.
Большинство сайтов во всём мире написаны на php, так что если хочется писать бэкенд для сайтов за границей, то php — это лучший выбор.
Я сразу написал, что - популярно несколько языков, и далее - большинство сайтов написано на php. Конечно многое сейчас написано на python и JS, но по количеству сайтов - лидирует php. Да, наверно они скоро догонят и обгонят его, но пока так.
Что касается выбора - я описывал свою историю. По большому счёту все 9 направлений - это разные миры. И в каждом из этих миров я немного разбирался, т.к. люблю развиваться и постоянно искать и изучать что-то новое. У вас видимо другая жизненная стратегия - заниматься тем, чем вы занимаетесь. Это тоже нормальная стратегия - потому у вас видимо не было подобных сложностей в выборе.
Про 15 лет... Когда работал в 1С или руководителем в Сбере меня всё устраивало. И мне нужно было за полгода-год решить куда двигаться дальше. Так что я не 15 лет выбирал, а полгода-год.
Про диаграмму Вена - да, у меня тогда был сложный период в жизни, и я умею в самоиронию)
Про 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 года, теперь я мидл/синьор/тимлид и сам ищу себе стажёров, также как и вы))) Успехов со стажёрами, коллега :)
Видимо вы не внимательно читали, цитата:
Я сразу написал, что - популярно несколько языков, и далее - большинство сайтов написано на php. Конечно многое сейчас написано на python и JS, но по количеству сайтов - лидирует php. Да, наверно они скоро догонят и обгонят его, но пока так.
Что касается выбора - я описывал свою историю. По большому счёту все 9 направлений - это разные миры. И в каждом из этих миров я немного разбирался, т.к. люблю развиваться и постоянно искать и изучать что-то новое. У вас видимо другая жизненная стратегия - заниматься тем, чем вы занимаетесь. Это тоже нормальная стратегия - потому у вас видимо не было подобных сложностей в выборе.
Про 15 лет... Когда работал в 1С или руководителем в Сбере меня всё устраивало. И мне нужно было за полгода-год решить куда двигаться дальше. Так что я не 15 лет выбирал, а полгода-год.