Про мышление технаря - возможно им действительно проще и не возникает сложности с выбором.
Про работу мозга полностью согласен и благодарю за подробное описание некоторых особеностей мышления.
По поводу единственного критерия "время" - не соглашусь. У меня не так. Возможно для кого-то время и постановка целей работает, но не для меня. Есть люди, которым важен результат. Мне важен процесс. Ведь работа - это часть жизни, и от качества того как я буду себя ощущать на работе - будет зависеть качество моей жизни. Но это также моё мнение, не претендую на истину.
Вариан "мне это просто нравится" у меня не прошёл, т.к. мне нравятся все 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 лет выбирал, а полгода-год.
Я бы не сказал, что там нет бизнес-логики. Просто она не такая, как в АБС.
Во фронтах бизнес-логика больше связана с UX и управлением бизнес-процессом.
В АБС бизнес-логика больше про управление данными и процессинг.
Нормальный процедурный язык где есть типы данных с фиксированной точкой (для которых реализована вся арифметика, в т.ч. такие вещи как "присвоение с округлением" если переменная с большим количеством разрядов присваивается переменной с меньшим), удобно со строками работать, много функций работы с датой-временем и поддержкой самых разных форматов дат и времени... Плюс он дает достаточно быстрый и эффективный код на выходе. Плюс имеет как встроенные функции работы с таблицами, так и возможность вставлять SQL операторы непосредственно в код...
Это описание мне напомнило 1С))) Ну может кроме большого количества разрядов и "быстрый и эффективный код на выходе"))) "Вьетнамские флешбеки"))) Благо из 1С ушёл в более техническую разработку.
Больше года думал, чем я хочу заниматься и не мог на чём-то конкретном остановиться. Так что обращение к психологу и ментору лично мне помогло быстро определиться.
Ментору я заплатил за помощь в решении моего вопроса. Он мне помог. Я тогда не знал про икигай. И только потом, когда узнал о нём - то вспомнил, что ментор мне задавал похожие вопросы. Кстати, ментор недавно запустил IT-бизнес в банковском секторе с которого получает несколько миллионов в месяц. Это я к тому, что он не представитель инфоцыган, а реальный бизнесмен.
мотивации "хочу в мобилки" и "хочу в ии" слишком широкие и абстрактные
Чтобы прийти к чему-то конкретному нужно сначала определиться в этих широких и абстрактных понятиях.
"игрофикация" вообще относится к менеджменту или коучингу а не к программированию.
Я привёл мои сферы интересов для примера и да, некоторые из них не из IT. В частности "игрофикация" скорее ближе к маркетингу (или к менеджменту, если используется для улучшения внутренних процессов компании)
Знаком с Lean Startup. В нём не совсем так. Скорее: Можно зарабатывать на том, что является "болью" клиента. И это западный подход, через "боль".
"Икигай" это восточный подход, чтобы его понять - нужно другое мышление, "не западное". В восточном подходе можно начать получать доход как благодарность за счастье, а не как избавление от "боли". Ближе всего из известному к этому подходу "донейшн" - когда не указана цена, и человек сам решает сколько заплатить.
А если "мир" не готов за это платить, то значит ему не сильно нужно. А если вы думаете, что миру что-то нужно, но не попытались это продать, значит это гипотеза, которую вы не проверили (и которая скорее всего не работает).
Тут всё сложнее. За некоторые вещи "мир" не может платить столько сколько нужно, чтобы окупиться. Тут не нулевая цена. Тут вопрос соответствия цены спроса и предложения. Часто бывает, что цена спроса ниже, чем цена предложения. И это не значит, что люди не готовы платить. Просто они не могут или не готовы платить больше.
Так что при оценке "готов ли мир платить" нужно оценивать не да/нет, а например в конкретных цифрах: сколько готов платить и сколько заказчиков готовы столько платить.
Про мышление технаря - возможно им действительно проще и не возникает сложности с выбором.
Про работу мозга полностью согласен и благодарю за подробное описание некоторых особеностей мышления.
По поводу единственного критерия "время" - не соглашусь. У меня не так. Возможно для кого-то время и постановка целей работает, но не для меня. Есть люди, которым важен результат. Мне важен процесс. Ведь работа - это часть жизни, и от качества того как я буду себя ощущать на работе - будет зависеть качество моей жизни. Но это также моё мнение, не претендую на истину.
Вариан "мне это просто нравится" у меня не прошёл, т.к. мне нравятся все 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 лет выбирал, а полгода-год.
Я бы не сказал, что там нет бизнес-логики. Просто она не такая, как в АБС.
Во фронтах бизнес-логика больше связана с UX и управлением бизнес-процессом.
В АБС бизнес-логика больше про управление данными и процессинг.
Это описание мне напомнило 1С))) Ну может кроме большого количества разрядов и "быстрый и эффективный код на выходе"))) "Вьетнамские флешбеки"))) Благо из 1С ушёл в более техническую разработку.
Больше года думал, чем я хочу заниматься и не мог на чём-то конкретном остановиться.
Так что обращение к психологу и ментору лично мне помогло быстро определиться.
Ментору я заплатил за помощь в решении моего вопроса. Он мне помог. Я тогда не знал про икигай. И только потом, когда узнал о нём - то вспомнил, что ментор мне задавал похожие вопросы. Кстати, ментор недавно запустил IT-бизнес в банковском секторе с которого получает несколько миллионов в месяц. Это я к тому, что он не представитель инфоцыган, а реальный бизнесмен.
Чтобы прийти к чему-то конкретному нужно сначала определиться в этих широких и абстрактных понятиях.
Я привёл мои сферы интересов для примера и да, некоторые из них не из IT. В частности "игрофикация" скорее ближе к маркетингу (или к менеджменту, если используется для улучшения внутренних процессов компании)
Знаком с Lean Startup. В нём не совсем так. Скорее: Можно зарабатывать на том, что является "болью" клиента. И это западный подход, через "боль".
"Икигай" это восточный подход, чтобы его понять - нужно другое мышление, "не западное". В восточном подходе можно начать получать доход как благодарность за счастье, а не как избавление от "боли". Ближе всего из известному к этому подходу "донейшн" - когда не указана цена, и человек сам решает сколько заплатить.
Тут всё сложнее. За некоторые вещи "мир" не может платить столько сколько нужно, чтобы окупиться. Тут не нулевая цена. Тут вопрос соответствия цены спроса и предложения. Часто бывает, что цена спроса ниже, чем цена предложения. И это не значит, что люди не готовы платить. Просто они не могут или не готовы платить больше.
Так что при оценке "готов ли мир платить" нужно оценивать не да/нет, а например в конкретных цифрах: сколько готов платить и сколько заказчиков готовы столько платить.