Всё несколько сложнее. Хоть нейросетки и помогают с рутиной, но требуют квалифицированной проверки и допиливания результата из-за галлюцинаций.
Подобное мизерное освобождение от рутины может привести к увольнению разве тогда, когда над одним проектом работают десятки людей одинаковой компетенции, за счёт уменьшения рутины. В реальности же такое не часто встречается, чаще большие проекты делятся на небольшие функциональные команды, ведь частая смена контекста снижает погруженность и производительность уже человека.
Соответственно, экономия идёт и ещё долго будет идти не от увольнения 1300 из этих 25000, а от выполнения большего объема задач сотрудником за то же время и чуть более быстрых сроков реализации задач.
В очень отдаленной перспективе использование "ИИ" подобным образом как раз и может дать бесконечную реиграбельность. Условно - поменял пару параметров при запуске и у тебя уже совершенно другая игра в совершенно другом сеттинге с совершенно другими событиями по сюжету. Бесконечная реиграбельность.
Сейчас в новости это конечно не более чем первый шаг младенца, но перспективы просто огромны.
Это лишь означает, что для решения подобной редкой задачи достаточно просто знать, что за графы такие, а дальше рнд и вперёд. Знать все возможные алгоритмы на графах заранее для решения вовсе не обязательно.
А это не особо важно, где денег хватит - там и придётся перекупать.
Все равно кроме этих двух способов решения проблемы дефицита опытных разработчиков - других способов не предусмотрено. Ну не прилетят из космоса с инопланетянами прям завтра десятки и сотни тысяч свободных мидлов и сеньоров. И через год не прилетят, и через 10 лет тоже. И ни какие курсы или универы не будут выдавать десятки тысяч мидло-сеньоров в год.
>> не хватает и программистов ... далеко не всегда могут найти себе работу ... индустрия нуждается в качественных кадрах
Ничего нового для решения проблемы кадров не придумать:
чтобы завтра можно было закрыть позицию на мидла или сеньора, надо не обманываться, что завтра после курсов или универа вдруг волшебным образом будут выходить мидлы с 3+ лет опыта работы и сеньоры с 6+ лет, а нанимать джунов с 0 лет опыта уже сегодня.
либо перекупать зарплатами у других стран, где таких мидлов таки взяли на работу 3+ года назад джунами.
Похоже мы немного о разных задачах для примеров говорим.
Маленьким простым примерам - место в документации, просто показать использование очередной фичи коротким куском кода.
Большое сложное приложение - позволяет показать в реальной жизни жизнеспособность либы, применяемость различных фич либы, различные трейдофы (а они есть всегда) и как их оптимальнее обыгрывать и тд. Да еще и в процессе переписывания такого приложения повсплывает всякое, что заставит выпустить еще десяток версий.
Предлагается, как бы, либа, вокруг которой будет строиться всё приложение и мало кому хотелось бы самому собирать все возможные грабли, а в итоге понять, что тоже самое на реакте было бы лучше, удобнее, быстрее, производительнее, понятнее, протестированнее, менее глючное, да еще и разрабов не надо переучивать.
Как верно замечено, нужен минимум Realworld, а еще лучше какая-нибудь большая админка на реакте, взять тот же react-admin. Чем больше в проекте разнообразных фич будет покрыто - тем больше кейсов выплывет, когда либу придется переписывать и патчить, порой отказываясь от неудачных решений и концепций вообще.
Сейчас, на основе этой статьи как-бы особой ценности от либы не видно вообще, кроме того, что будет чуть меньше строк кода из-за отсутствия useState да useCallback, но получив за это фактическое отсутствие реактивности. Это очень странный кейс для продвижения.
Ну право, сейчас не времена jQuery, чтобы можно было выехать только на наличии jsx синтаксиса. Нужны реальные причины, для чего разрабу брать в проект неоттестированную либу с кучей неизвестных подводных камней, о которой только известно то, что на ней покороче туду-листы с каунтерами получаются.
Именно, потому что если какие-то решения хороши для каунтера и тудушки, то это совсем не означает, что они будут хороши для чего серьезного, с кучей фич и требований.
Я бы не назвал полноценными приложениями - мелкие примеры на десяток файлов.
Еще раз - основная проблема продвижения очередного "убийцы реакта" в том, что на самом реакте люди, от которых зависит выбор стека (хотя бы для внутренних проектов компаний, на внешние никто в здравом уме не потянет кота в мешке), понаписали многие сотни тысяч и миллионы строк кода, понимают минусы-плюсы различных решений на реакте, знакомы с десятками и сотнями библиотек, знают, что при росте проекта всегда смогут найти разработчиков. Им от этих мелких примеров - ни холодно ни жарко.
Нужен действительно большой проект и в первую очередь ориентированный на всякие админки (только на подобных проектах еще возможно затянуть в прод не самое популярное решение "для опыта", если мы говорим о чем-то больше туду-листа на гитхабе). Со всякими графиками, формами, таблицами, пагинациями, правами и тд.
Все эти примеры в репе - конечно окей, но в реальности это было просто потерей времени, которое ничего не даст. Я серьезно, ищите большую админку и переписывайте на свою либу сопровождая серией статей с процессом переписывания и выводами - выводами в чем плюс выбрать именно данную либу, на фоне уже имеющихся и привычных многим решений.
Маленький пример маленького компонента - это конечно весело показывать в выгодном свете. Но если хочется именно попытаться собрать комьюнити и попробовать занять хоть немного места в нише фронта, то видится мне, что для популяризации очередного "убийцы реакта", надо не показывать очередной каунтер с кнопкой, а брать большой серьезный проект на том же гитхабе и переписывать его на своего "убийцу реакта".
И писать уже большую серию статей с конкретными примерами, в чем именно стало лучше и проще и выводами, по типу:
кодовая база сократилась на N%
размер бандла сократился на M%
скорость сборки ускорилась на L%
производительность на клиенте улучшилась на K%
время разработки теоретически могло сократиться на J человекочасов
Без серьезного подхода и серьезных выводов - на либе и через год максимум кто-то набросает очередной каталог фильмов и очередные туду-листы.
Если человек не считает легаси кодом код своего прошлого проекта - то за всё это время с того проекта он ничему не научился и ничего нового не узнал, остался стоять на месте.
Добавим в ситуацию работник-работодатель еще и третье лицо - еще одного работника, работающей в команде с работником на той же должности с теми же трудовыми обязанностями, но из другой страны. И сразу ситуация заиграет другими красками, более интересными.
И получаем, что при значительном падении/росте любой из двух валют либо первый работник, либо второй работник имели бы ЗП в два раза меньше другого в пересчете в любую валюту, хотя имеют ровно те же самые должностные обязанности и делают ровно одинаковый объем работы. Несправедливо же, не?
Вот компания и выравнивает как может. Надо посмотреть где у Озона основная масса кадров, на тот рынок она и будет ровняется. Вряд-ли Озон вообще способен на 40% поднять зп основной массе разработчиков в рублевой зоне, значит остается уменьшать меньшинству в Армении.
Справедливость, она такая, у разных сторон она порой противоположна.
Безотносительно к конкретным странам, компаниям и валютам, но сходу можно придумать контр-пример:
Наоборот, валюта в стране Б значительно опустились по сравнению со страной А, из которой работодатель. Тогда джун в команде из страны А будет получать больше, чем лид из страны Б в этой же команде.
И тогда этот же человек из Б хотел бы перерасчета уже в валюте А и считал именно такой вариант самым справедливым и никакой другой.
А вообще, как уже заметили, самое действенное, что вы можете - уйти в другую компанию и желательно местную, чтобы не было привязки ни к каким курсовым разницам, ни в плюс, ни в минус. Это будет самое справедливое.
Какая-то особая расширяемость компонентов, разве только если это не какая-то библиотека общих ui элементов, в продуктовом проекте практически всегда идет по грани нарушения принципа yagni.
Если проект не мертвый на поддержке, то он активно развивается, вводятся новые фичи, удаляются неудачные фичи, зачастую возможны редизайны (в том числе серьезные, а не просто цвет да шрифт поменялись немного), версии для мобилок, таблета, десктопа могут различаться не только стилями, но и вообще поведением и логикой взаимодействия компонентов между собой. Зачастую, вместо того, чтобы городить абстракцию над абстракцией ради абстракции и пробовать строить расширяемость ради расширяемости, лучше добавить обычный параметр компоненту или вообще скопипастить общую часть, все равно потом делить по чанкам и лишнего не загрузится, если оно не нужно.
Если все постоянно покрывать тестами - то в итоге получится написание тестов ради самих тестов, которые еще и придется часто переделывать, при этом увеличивая time-to-market.
Если для каких-либо чисто утилитарных функций еще можно понять, все же это редко меняется в проекте, то для вью слоя это бесполезная трата времени.
Оправдать написание тестов на вью можно разве что если хочется дать задачу для начинающего, чтобы человек разобрался с этой темой, для общего кругозора, понимания и галочки в резюме.
Я выше уже написал про допущение, что при подборе известно, что там конкретно 4 осмысленных и безошибочных слова.
Заменяем пробелы и буквы на спецсимволы, не случайные для конкретного человека, но которые ему очень легко запомнить и готово - привет старый добрый брутфорс с миллионами лет.
Например:
"ехал грека через реку" -> "@[!k1uh@r!2x@h@p3h@r%"
Пароль легко запомнить, принцип замены также простой - пробелы заменены цифрой с инкрементом, гласные заменены спецсимволом по порядку.
Сдается мне, что в этих расчетах закралось маленькое такое допущение - злоумышленнику заранее известно, что в подбираемом пароле 4 именно осмысленных слова.
Делаем простейшую замену букв на спецсимволы по какому-нибудь легко запоминаемому конкретным человеком алгоритму (скажем в первом слове первая и последняя буква, во втором вторая и предпоследняя и тд), и все эти расчеты сразу можно выкинуть.
Можно посмотреть ченджлоги драйверов для той же нвидии. Что не версия - то список конкретных игр, под которые подпиливали драйверы. Также сами игры разрабатывают и проверяют работу на соответствующем железе.
Чтобы понять, достаточен ли рынок меньше 100 миллионов, попробуйте просто назвать парочку производителей собственных чипов для видеокарт в странах с таким населением, да еще и с продажами только на своем рынке.
nVidia, AMD, Intel - за таких производителей не считаем, они на глобальном рынке с 6 млрд человек.
Нет таких? Ну вот и ответ - достаточен ли такой рынок. Был бы достаточным - были бы десятки и сотни производителей самых разных видеокарт.
Есть понимание, что собственного рынка в 150млн человек (и даже этот рынок уже занят другими производителями) недостаточно для разработки и производства видеокарт с условием достижения окупаемости и получения прибыли (а для чего еще бизнесу этим заниматься?), а внешнего рынка для гипотетических карт нет. Для "имиджевого" проекта как-то слишком дорогое удовольствие для любого местного бизнеса.
Таким образом данное предприятие может быть только сжиганием бюджетных денег чтобы потешить геймеров "отечественной видеокартой", что так-то им и не особо надо.
Всё несколько сложнее. Хоть нейросетки и помогают с рутиной, но требуют квалифицированной проверки и допиливания результата из-за галлюцинаций.
Подобное мизерное освобождение от рутины может привести к увольнению разве тогда, когда над одним проектом работают десятки людей одинаковой компетенции, за счёт уменьшения рутины. В реальности же такое не часто встречается, чаще большие проекты делятся на небольшие функциональные команды, ведь частая смена контекста снижает погруженность и производительность уже человека.
Соответственно, экономия идёт и ещё долго будет идти не от увольнения 1300 из этих 25000, а от выполнения большего объема задач сотрудником за то же время и чуть более быстрых сроков реализации задач.
В очень отдаленной перспективе использование "ИИ" подобным образом как раз и может дать бесконечную реиграбельность. Условно - поменял пару параметров при запуске и у тебя уже совершенно другая игра в совершенно другом сеттинге с совершенно другими событиями по сюжету. Бесконечная реиграбельность.
Сейчас в новости это конечно не более чем первый шаг младенца, но перспективы просто огромны.
Это лишь означает, что для решения подобной редкой задачи достаточно просто знать, что за графы такие, а дальше рнд и вперёд. Знать все возможные алгоритмы на графах заранее для решения вовсе не обязательно.
А это не особо важно, где денег хватит - там и придётся перекупать.
Все равно кроме этих двух способов решения проблемы дефицита опытных разработчиков - других способов не предусмотрено. Ну не прилетят из космоса с инопланетянами прям завтра десятки и сотни тысяч свободных мидлов и сеньоров. И через год не прилетят, и через 10 лет тоже. И ни какие курсы или универы не будут выдавать десятки тысяч мидло-сеньоров в год.
>> не хватает и программистов ... далеко не всегда могут найти себе работу ... индустрия нуждается в качественных кадрах
Ничего нового для решения проблемы кадров не придумать:
чтобы завтра можно было закрыть позицию на мидла или сеньора, надо не обманываться, что завтра после курсов или универа вдруг волшебным образом будут выходить мидлы с 3+ лет опыта работы и сеньоры с 6+ лет, а нанимать джунов с 0 лет опыта уже сегодня.
либо перекупать зарплатами у других стран, где таких мидлов таки взяли на работу 3+ года назад джунами.
Похоже мы немного о разных задачах для примеров говорим.
Маленьким простым примерам - место в документации, просто показать использование очередной фичи коротким куском кода.
Большое сложное приложение - позволяет показать в реальной жизни жизнеспособность либы, применяемость различных фич либы, различные трейдофы (а они есть всегда) и как их оптимальнее обыгрывать и тд. Да еще и в процессе переписывания такого приложения повсплывает всякое, что заставит выпустить еще десяток версий.
Предлагается, как бы, либа, вокруг которой будет строиться всё приложение и мало кому хотелось бы самому собирать все возможные грабли, а в итоге понять, что тоже самое на реакте было бы лучше, удобнее, быстрее, производительнее, понятнее, протестированнее, менее глючное, да еще и разрабов не надо переучивать.
Как верно замечено, нужен минимум Realworld, а еще лучше какая-нибудь большая админка на реакте, взять тот же react-admin. Чем больше в проекте разнообразных фич будет покрыто - тем больше кейсов выплывет, когда либу придется переписывать и патчить, порой отказываясь от неудачных решений и концепций вообще.
Сейчас, на основе этой статьи как-бы особой ценности от либы не видно вообще, кроме того, что будет чуть меньше строк кода из-за отсутствия useState да useCallback, но получив за это фактическое отсутствие реактивности. Это очень странный кейс для продвижения.
Ну право, сейчас не времена jQuery, чтобы можно было выехать только на наличии jsx синтаксиса. Нужны реальные причины, для чего разрабу брать в проект неоттестированную либу с кучей неизвестных подводных камней, о которой только известно то, что на ней покороче туду-листы с каунтерами получаются.
Именно, потому что если какие-то решения хороши для каунтера и тудушки, то это совсем не означает, что они будут хороши для чего серьезного, с кучей фич и требований.
Я бы не назвал полноценными приложениями - мелкие примеры на десяток файлов.
Еще раз - основная проблема продвижения очередного "убийцы реакта" в том, что на самом реакте люди, от которых зависит выбор стека (хотя бы для внутренних проектов компаний, на внешние никто в здравом уме не потянет кота в мешке), понаписали многие сотни тысяч и миллионы строк кода, понимают минусы-плюсы различных решений на реакте, знакомы с десятками и сотнями библиотек, знают, что при росте проекта всегда смогут найти разработчиков. Им от этих мелких примеров - ни холодно ни жарко.
Нужен действительно большой проект и в первую очередь ориентированный на всякие админки (только на подобных проектах еще возможно затянуть в прод не самое популярное решение "для опыта", если мы говорим о чем-то больше туду-листа на гитхабе). Со всякими графиками, формами, таблицами, пагинациями, правами и тд.
Все эти примеры в репе - конечно окей, но в реальности это было просто потерей времени, которое ничего не даст. Я серьезно, ищите большую админку и переписывайте на свою либу сопровождая серией статей с процессом переписывания и выводами - выводами в чем плюс выбрать именно данную либу, на фоне уже имеющихся и привычных многим решений.
Маленький пример маленького компонента - это конечно весело показывать в выгодном свете. Но если хочется именно попытаться собрать комьюнити и попробовать занять хоть немного места в нише фронта, то видится мне, что для популяризации очередного "убийцы реакта", надо не показывать очередной каунтер с кнопкой, а брать большой серьезный проект на том же гитхабе и переписывать его на своего "убийцу реакта".
И писать уже большую серию статей с конкретными примерами, в чем именно стало лучше и проще и выводами, по типу:
кодовая база сократилась на N%
размер бандла сократился на M%
скорость сборки ускорилась на L%
производительность на клиенте улучшилась на K%
время разработки теоретически могло сократиться на J человекочасов
Без серьезного подхода и серьезных выводов - на либе и через год максимум кто-то набросает очередной каталог фильмов и очередные туду-листы.
Если человек не считает легаси кодом код своего прошлого проекта - то за всё это время с того проекта он ничему не научился и ничего нового не узнал, остался стоять на месте.
Не Озон, а Авито. Впрочем, какая разница.
Добавим в ситуацию работник-работодатель еще и третье лицо - еще одного работника, работающей в команде с работником на той же должности с теми же трудовыми обязанностями, но из другой страны. И сразу ситуация заиграет другими красками, более интересными.
И получаем, что при значительном падении/росте любой из двух валют либо первый работник, либо второй работник имели бы ЗП в два раза меньше другого в пересчете в любую валюту, хотя имеют ровно те же самые должностные обязанности и делают ровно одинаковый объем работы. Несправедливо же, не?
Вот компания и выравнивает как может. Надо посмотреть где у Озона основная масса кадров, на тот рынок она и будет ровняется. Вряд-ли Озон вообще способен на 40% поднять зп основной массе разработчиков в рублевой зоне, значит остается уменьшать меньшинству в Армении.
Справедливость, она такая, у разных сторон она порой противоположна.
Безотносительно к конкретным странам, компаниям и валютам, но сходу можно придумать контр-пример:
Наоборот, валюта в стране Б значительно опустились по сравнению со страной А, из которой работодатель. Тогда джун в команде из страны А будет получать больше, чем лид из страны Б в этой же команде.
И тогда этот же человек из Б хотел бы перерасчета уже в валюте А и считал именно такой вариант самым справедливым и никакой другой.
А вообще, как уже заметили, самое действенное, что вы можете - уйти в другую компанию и желательно местную, чтобы не было привязки ни к каким курсовым разницам, ни в плюс, ни в минус. Это будет самое справедливое.
Какая-то особая расширяемость компонентов, разве только если это не какая-то библиотека общих ui элементов, в продуктовом проекте практически всегда идет по грани нарушения принципа yagni.
Если проект не мертвый на поддержке, то он активно развивается, вводятся новые фичи, удаляются неудачные фичи, зачастую возможны редизайны (в том числе серьезные, а не просто цвет да шрифт поменялись немного), версии для мобилок, таблета, десктопа могут различаться не только стилями, но и вообще поведением и логикой взаимодействия компонентов между собой. Зачастую, вместо того, чтобы городить абстракцию над абстракцией ради абстракции и пробовать строить расширяемость ради расширяемости, лучше добавить обычный параметр компоненту или вообще скопипастить общую часть, все равно потом делить по чанкам и лишнего не загрузится, если оно не нужно.
Если все постоянно покрывать тестами - то в итоге получится написание тестов ради самих тестов, которые еще и придется часто переделывать, при этом увеличивая time-to-market.
Если для каких-либо чисто утилитарных функций еще можно понять, все же это редко меняется в проекте, то для вью слоя это бесполезная трата времени.
Оправдать написание тестов на вью можно разве что если хочется дать задачу для начинающего, чтобы человек разобрался с этой темой, для общего кругозора, понимания и галочки в резюме.
Я выше уже написал про допущение, что при подборе известно, что там конкретно 4 осмысленных и безошибочных слова.
Заменяем пробелы и буквы на спецсимволы, не случайные для конкретного человека, но которые ему очень легко запомнить и готово - привет старый добрый брутфорс с миллионами лет.
Например:
"ехал грека через реку" -> "@[!k1uh@r!2x@h@p3h@r%"
Пароль легко запомнить, принцип замены также простой - пробелы заменены цифрой с инкрементом, гласные заменены спецсимволом по порядку.
Сдается мне, что в этих расчетах закралось маленькое такое допущение - злоумышленнику заранее известно, что в подбираемом пароле 4 именно осмысленных слова.
Делаем простейшую замену букв на спецсимволы по какому-нибудь легко запоминаемому конкретным человеком алгоритму (скажем в первом слове первая и последняя буква, во втором вторая и предпоследняя и тд), и все эти расчеты сразу можно выкинуть.
Можно посмотреть ченджлоги драйверов для той же нвидии. Что не версия - то список конкретных игр, под которые подпиливали драйверы. Также сами игры разрабатывают и проверяют работу на соответствующем железе.
Чтобы понять, достаточен ли рынок меньше 100 миллионов, попробуйте просто назвать парочку производителей собственных чипов для видеокарт в странах с таким населением, да еще и с продажами только на своем рынке.
nVidia, AMD, Intel - за таких производителей не считаем, они на глобальном рынке с 6 млрд человек.
Нет таких? Ну вот и ответ - достаточен ли такой рынок. Был бы достаточным - были бы десятки и сотни производителей самых разных видеокарт.
Есть понимание, что собственного рынка в 150млн человек (и даже этот рынок уже занят другими производителями) недостаточно для разработки и производства видеокарт с условием достижения окупаемости и получения прибыли (а для чего еще бизнесу этим заниматься?), а внешнего рынка для гипотетических карт нет. Для "имиджевого" проекта как-то слишком дорогое удовольствие для любого местного бизнеса.
Таким образом данное предприятие может быть только сжиганием бюджетных денег чтобы потешить геймеров "отечественной видеокартой", что так-то им и не особо надо.