Используем очень активно веб-компоненты уже года четыре. Оркестатор микрофронтендов, но т.к. много легаси, то завёрнуто всё в вебкомпоненты для совместимости.
Основные проблемы, которые мешают:
1) Е2Е автотесты. Е2Е фреймворки либо вообще не умеют работать нормально с shadowRoot, либо заявляют что умеют, а по факту нет. В итоге куча самопальных костылей, которые с обновлением фреймворка могут требовать подпила.
2) Всякие внешние аналитики/репортеры/трейсеры а ля гуглоаналитика или сентри. Они не видят компоненты. Для гуглоаналитики в хитмапах это просто белая секция на экране. И приходится опять же писать костыли, чтобы клики и т.п. нормально прокидывалось в родительский скоуп.
3) devtools, например, Vue devtools. Если у вас есть vue внутри веб-компонента и приложение вокруг компонента - до информации в веб-компоненте вы не долезете. Опять, костыли, обновления, вот это всё.
В общем, поэтому, примерно, решение и не популярно. Нет поддержки со стороны сообщества, все инструменты допиливать надо самостоятельно.
Столкнулся с SAFe, впечатления по итогам полутора лет - отвратные. Тот же вотерфолл, только обвешанный модными блёстками. Пришло новое руководство, им стукнуло в башню, что все работают неправильно, и надо срочно всем внедрять SAFe. Почему, зачем, неважно - SAFe - это модно!
1) 3-х месячные итерации(PI), на которые надо подписываться кровью. Изменений в скоупе в течение трёх месяцев быть не может никаких, пришли новые требования/пообщались с клиентом - нет, всё, уже закоммитились, теперь только выполняем. Гибкость потерялась вся. Спринты проходят по 2 недели, но т.к. скоуп поменять нельзя, то смысла в них особо нет.
2) Исследовательские задачи никто не хочет брать, т.к. хрен знает, во что это выльется - а нужны 100% гарантии выполнения 3х месячного плана. И одновременно 100% загрузка ресурсов при планировании. В итоге любая внештатная бага/тикет/архитектурная проблема по итогам дизайна - и люди начинают кроить нужные задачи в попытках выгадать какое-то время чтобы успеть в 3 месяца. Задачи на выход начали выходить подозрительного качества. Техдолг менеджить стало в разы сложнее.
3) Все 20 департаментов по 50-100 человек должны естественно выполнять ритуалы связанные с релиз трейном. Это значит - посещать митинги на сотни человек (по 2-3 представителя от департамента), и что-то там слушать, показывать презентации и отчитываться. Толку от этого - примерно ноль, до этих PI за 6 лет работы в компании я даже не представлял, что большая часть этих людей существует. И с нашей работой они не пересекаются вообще никак. Но все сидят часами на этих планнингах, митингах, занимаемся рисовкой отчётов, рисовкой презентаций на выброс и прочей хренотой.
4) Релизы должны быть синхронизированы! Чтобы все показывали глобальное демо после 3х месяцев (опять на сотни рандомных человек) и чувствовали как движутся вперёд! С учётом пункта (2), при загрузке 100% и требовании 100% выполнение плана - времени релизить нет. Релизы стали выпускаться вместо каждого месяца - раз в три месяца, чисто чтобы под демо успеть. Зачем делать релиз если фидбек с него никак не будет использоваться ещё минимум 2 месяца до следующего планирования?
В итоге имеем падение качества продукта, падение частоты релизов, уменьшение гибкости (по 3 месяца ничего в требованиях менять нельзя), падение качества требований (т.к. надо с заказчиком/РнД/QA/Delivery всё обсудить и утрясти ровно перед планнингом, по актуальной информации, а на такой огромный скоуп это невозможно). В общем, выстрел себе в ногу удался.
Как страшно жить! Понимаешь, не выбрасывают функции! Всё легаси! Раздутый функционал!
А вот не так однозначно. Обратная совместимость у Windows за счёт этого сильно лучше. Не, если поставить голый Центось и с него отдавать статику в инет - спору нет, Центось будет в сотни раз стабильнее. Но вот на реальной домашней системе с кучей разностороннего железа и софта... Обновил Винду с 10 до 11-ой - что отломалось? Ничего. ВСЁ работает.
Обновил Убунту с 20.хх до 22.хх. ОпенВПН перестал работать? Почему? Похерили обратную совместимость - зайди в репозиторий, поправь пару строчек, пересобери либу. Внешняя аудиокарта в Сонаре перестала нормально выводить звук, появился лаг. Почему? Потому. Зайди, скачай, поправь пару строчек, пересобери дрова. Миди клава? Домашний кинотеатр 7.1 через HDMI и + 2 доп. вывода звука? Циско? Шаринг видео в Тимс? Ну вы поняли. Зайди, найди проблему, скачай исходники, поправь, пересобери. А ещё есть и минорные обновления ОС почаще...
Спасибо, я потерплю кучу "ненужного" легаси. Понимаю, немного холиварно, но я несколько раз в своей жизни на домашнем компе пытался избавиться от Винды, довольно долго жил в мультибуте, но, блин, я так не могу. Пока мне для решения моих повседневных задач нужного кодить день вместо того чтобы два раза кликнуть на ярлык - я не готов тратить на это время. Пусть даже этот ярлык запустится не за секунду, а за полторы или две.
Сейчас в компании наблюдаю похожий процесс. Только тут нет выделенных аналитиков, вместо них в данном процессе выступает тимлид или делегированный на фичу разработчик. У них достаточно экспертизы, чтобы сказать "это вот надо делать не так, а иначе". В итоге процесс выглядит так:
Дизайнер с владедьцем продукта рисуют прототипы. Просто на основе блоков, без точных pixel perfect мокапов. Перебирают вариации на чём-то соглашаются.
Потом к этому процессу подключают тимлида. Он смотрит, вместе обсуждают, что можно сделать, что дорого и стоит заменить на другое решение. Договариваются, дизайнер уходит на рисование мокапов.
В конце собираются ещё раз опять, уже с точными мокапами, вносят минорные правки, если ещё есть и мокапы уходят в работу.
Многое, что делали с языком после С#6-7 - это порча хорошего и стройного языка и превращение его в джаваскрипт. Жабаскрипт такой только по историческим причинам, а тут сознательно портят язык.
Для верхнеуровневых языков скорость разработки зависит не от количества синтаксического сахара или того, пишешь ты конструктор за 30 символов или за 40, а от простоты и наглядности кода, возможностей выражать понятия доменной модели в коде наиболее близким способом, не увеличения, а лимитирования способов сделать одно и то же, ограничения возможностей "писать, что попало" и структурирование всего кода в определённые рамки, близость к натуральным языкам ддя простоты понятия и оперирования...
Основной тех. долг, который несёт косты для бизнеса это ошибки в проектировании доменной модели, макаронный код, проблемы времени жизни объектов и т.п., а не лишняя строка для определения пропсы.
А как вы распределённую транзакцию будете проверять без общесистемной регрессии? Или типа, сделали её распределённой - ну и бог бы с ней, больше не тестируем? Проблема-то никуда не ушла, тестировать надо.
Жизнь без распределённых транзакций проще и лучше. И это достижимо во многих кейсах, даже если вдруг одна БД вам претит - чуть более тщательный анализ доменной области скорее всего сожет позволить пилить микросервисы, чтобы одной семантически значимой сущностью владел один микросервис, а не несколько. Тогда весь этот гемморой резко пропадает.
И это класс. Если мне надо поставить одну аватарку, я не хочу чтобы приложение имело доступ ко всему архиву home video и пересланных в переписках файлов.
Лучше, но на сервере можно себе позволить загрузить две либы разных версий в память. А вот на фронте - это уже совсем другие расходы - сеть, объём кэша, cpu на парсинг - всё это сильно дороже. Оттуда и вылез этот ужасный формат семантической версионности с кучей проблем совместимости - из попыток не грузить одинаковые подзависимости.
Очередной "визионер" вида "все кругом тупые, всё общество заблуждается, а вот я сейчас расскажу как правильно". Вот прям все миллионы сидят, работают годами в области, развиваются, учатся и не понимают очевидной вещи, их очень надо просветить.
Последнего такого известного визионера месяцок назад раздавило на глубине 3км, тоже очень хотел откинуть нелепые стандарты, наработанные решения и сделать всё просто, на контроллерах от ХБокс и железной бочки. В принципе, это примерно показывает к чему это приведёт.
Первый же проект, написанный по указанному подходу, у которого жизненный цикл не "2 месяца написал и сдал", а лет 10 - будет вынуждено выкинут на помойку приемником после ТС вместе с миллионами денег потраченными на переработку и миграцию, потому что косты поддержки (за счёт неявных ошибок, когнитивной сложности кода, нестандартого подхода на который не найдёшь людей, невозможности масштабировать и прочего) будут ещё больше.
Почему фреймворки весят мегабайты и гигабайты, не задумывались? Потому что это не то, что надо экономить. Всем пофиг, жрёт ли фреймворк 10кб на машине разработчика или 10гб. Аналогично, с текущим каналом в большинстве своём на массовых задачах всем примерно пофиг, весит web-CRM (вы как раз упоминали веб приложения) 10кб или 100кб. А то, что является проблемой - это когнитивная сложность поддержки, стабильность и скорость внедрения фичей. И вот эту проблему решают фреймворки. По вашему подходу вы можете набрать команду из сплошных Principal Engineer-s и она прекрасно будет его держать. Остальные повалятся. А на проект на фреймворке можно посадить кучу мидлов и одного принципала и они будут в 3 раза дешевле, в 20 раз проще в найме и менеджменте и делать то же самое со скоростью 80%. И потом пересадить на соседний проект на том же фреймворке и они продолжат с такой же скоростью, без необходимости онбординга в полгода. И да, у каждого будет SSD на терабайт под фреймворки, это всё равно дешевле.
Вы гугол или нанимаете джунов? Где тот эльдорадо, откуда берутся 15 крепких профи в день на рядовую должность?
Не понял логической цепочки. Открыли вакансию, собираем всех по рынку доступных недели 2-3, нанимаем, закрыли вакансию. Поток резюме 5-15 штук в день это вполне норма, рынок международный. Не все резюме проходят до интервью.
По итогу на следующем этапе имеем как минимум двух человек, округляющих глаза друг на друга
Терпеть не могу хайринг на аутсорсе. Было такое на прошлой неделе, кстати. Я обычно первые 7-8 минут трачу, чтобы рассказать о проекте, чтобы человек понимал, почему дальше будут те или иные вопросы. Рассказываю, вижу чем дальше, тем больше недоумения в глазах. Спрашиваю - что не так? Выясняется, что человек ищет вакансию только под Ангуляр и ничего больше не рассматривает, а у нас Ангуляр ни на одном из 150 проектов не используется и в описании вакансии не упоминается. Извинился, разошлись. HR объяснить мне, где у него голова, так и не смог. Видимо её нет.
Зачем задавать вопрос «что такое цикл» человеку с десяткой лет профильного опыта?
Вы как-то исходите из предположения, что все люди в мире адекватны.
Отвечая на вопрос "заяем задавать базовые вопросы?". Потому что у кандидата 10 лет может быть в смежном стеке, а написать в cv он забыл. Потому что, может быть он занимался однотипными задачами и знает только один фреймворк, а на любой вопрос про базовое строение языка плывёт. Потому что он 10 лет сидел и занимался одним и тем же или просто его работа в компании не была никому интересна и он не развивался. Потому что резюме может быть в конце-концов чужим (было и такое в практике). Поэтому базовые навыки проверяются всегда. Знаешь - молодец, потратили на это 5 минут, пошли дальше. Опять же, случай из недавних, у человека 11 лет опыта, причём по резюме выглядит солидно. Но ответы на вопросы про процессы или архитектуру - ноль (ответы вида "я не знаю") и при попытке посмотреть навыки кодинга человек не может написать нормально перебор коллекции. Неожиданно, но бывает и такое.
Но если типовую задачку для оценки навыка кодинга нельзя заменить парой актуальных и живых репозиториев из github кандидата – это опять звоночек про гибкость процессов.
Во-первых, мы опять же не знаем историю появления этого репозитория - чужой он, свой, написан самим человеком или с помощью, всё равно придётся по нему разговаривать. Поэтому оффлайн это не заменит. Во-вторых, оффлайн задача это проверка умения работать самостоятельно - вот тебе гугл, вот задача, которой нет в гугле в прямом виде, составь из всех производных нужное решение. Если человек в оффлайн не способен решить базовые задачи - нагуглить и синтезировать - то как он будет дальше работать? В-третьих, это экономия времени нанимающего (да, извините, это так). Чтобы просто открыть репо- нужно 5 минут, да. За них вы успеет увидеть кодстайл конкретного одного проекта и всё. А вот чтобы сделать выводы о качестве решения, нужно будет перешерстить несколько репо (обычно шлют ещё и несколько ссылок), найти более-менее сложный, разобраться в задаче, которую решает это приложение, понять архитектурные решение, прикинуть узкие места, пройтись по коду, найти эти узкие места, понять как человек это решил, наметить вопросы... Полчаса на репо. А у тебя 15 таких резюме в день, и в каждом n репосов. Сорри, но нереально.
А тестовая задача готовится один раз, решения все её уже известны нанимающему, как и потенциальные вопросы вокруг. Да, перекладывание затрат на кандидата, поэтому стараемся использовать по минимуму и ставим её необязательной. Но, кстати, когда пишем, что задача не обязательная - почти 100% всё равно присылают решение.
Не хватает в конце вывода - самое главное, а зачем это сделано-то? Типа круто, придумали, нарисовали, продавили, всех заняли. А что в итоге с конверсией и временем чекаута, выхлоп-то есть, сколько? Иначе же этим всем заниматься и не стоило, если аналитика не показала новых показателей, то все "закоренелые бюрократы" были правы.
Мне одному Composition Api кажется порочной технологией?
Всю жизнь программисты борятся со сложностью кода. Реактивное программирование уже даёт определённый скачок сложности, по сравнению, скажем, с процедурным, т.к. много вещей происходит "неявно", обеспечивается фреймворком, и это надо держать в голове и учитывать. Чтобы бороться с этой сложностью люди придумал всякие Flux паттерны, натянули мввм на компоненты, выстраивают жёсткую архитектуру и задают ограничения контекстов - используя иерархическую структуру компонентов и модулей, микрофронты, гексагоналку и т.п.
И тут вылезает технология, которая позволяет связать реактивно что угодно с чем угодно. И ты вот такой меняешь одно поле в классе и у тебя может поменяться в приложении всё что угодно и где угодно, причём это неявный вызов, отследить это возможностей крайне мало. Т.е. очень легко неправильно заиспользовать и вероятность получить тяжело поддерживаемый код с высокой связностью крайне высока. Так надо ли оно?
Обычно когда возникают вопросы с тем, что "сложно реиспользовать код" - это вопрос к тому, что кто-то либо наговнокодил, либо просто накопился тех.долг и текущие компоненты и модули надо либо делить на несколько, либо объединять в общий, и после рефакторинга оказывается что никакие такие дополнительные горизонтальные связи не нужны.
Собственно да. По сути это тот же монолит, но гораздо легче масштабируется и решает большую часть проблем. Интересно, увидим ли в "микросервисном" подходе кучу квадратов 200*200 разделённых железкой, что является вторым типичным масштабируемым решением.
Важный пункт - поддерживает раздельное туннелирование по белому листу. Т.е. вы можете включить впн только для определённых программ, а для игр, например, трафик пойдёт по обычному пути. Таким образом можно вообще его не выключать, включить только для заблоченных приложений и оставить висеть в фоне.
Wcf очень многословен, использует как базу по умолчанию тяжёлый и медленный xml. И вас не смущает, что его развитие по сути было остановлено 12 лет назад? По сути можно ещё предложить сейчас писать веб приложения на вебформс. Ушло уже время, ушло, это медленные, неудобные, неподдерживаемые технологии, которые не построены на современных принципах.
Мне кажется одна из больших "болей" в микросервисах - это версионирование, жаль, что в статье это не затронули. По rest уже есть некие стандартные приёмы, библиотеки, типа делаешь /v2/ и дальше двухшаговая миграция. А как это работает с gRPC и protobuf? Есть какой-то стандарт, что делать с контрактом при необходимости сделать несовместимые изменения? Просто генерим второй контракт и дублируем все затронутые классы? Есть ли набор ошибок передающих статус deprecated?
Используем очень активно веб-компоненты уже года четыре. Оркестатор микрофронтендов, но т.к. много легаси, то завёрнуто всё в вебкомпоненты для совместимости.
Основные проблемы, которые мешают:
1) Е2Е автотесты. Е2Е фреймворки либо вообще не умеют работать нормально с shadowRoot, либо заявляют что умеют, а по факту нет. В итоге куча самопальных костылей, которые с обновлением фреймворка могут требовать подпила.
2) Всякие внешние аналитики/репортеры/трейсеры а ля гуглоаналитика или сентри. Они не видят компоненты. Для гуглоаналитики в хитмапах это просто белая секция на экране. И приходится опять же писать костыли, чтобы клики и т.п. нормально прокидывалось в родительский скоуп.
3) devtools, например, Vue devtools. Если у вас есть vue внутри веб-компонента и приложение вокруг компонента - до информации в веб-компоненте вы не долезете. Опять, костыли, обновления, вот это всё.
В общем, поэтому, примерно, решение и не популярно. Нет поддержки со стороны сообщества, все инструменты допиливать надо самостоятельно.
Забыли один пункт посередине "откройте мой скрипт в безопасном окружении и прочитайте, что он делает". :)
Запускать рандомные скрипты из интернета не глядя - ванлав.
Столкнулся с SAFe, впечатления по итогам полутора лет - отвратные. Тот же вотерфолл, только обвешанный модными блёстками. Пришло новое руководство, им стукнуло в башню, что все работают неправильно, и надо срочно всем внедрять SAFe. Почему, зачем, неважно - SAFe - это модно!
1) 3-х месячные итерации(PI), на которые надо подписываться кровью. Изменений в скоупе в течение трёх месяцев быть не может никаких, пришли новые требования/пообщались с клиентом - нет, всё, уже закоммитились, теперь только выполняем. Гибкость потерялась вся. Спринты проходят по 2 недели, но т.к. скоуп поменять нельзя, то смысла в них особо нет.
2) Исследовательские задачи никто не хочет брать, т.к. хрен знает, во что это выльется - а нужны 100% гарантии выполнения 3х месячного плана. И одновременно 100% загрузка ресурсов при планировании. В итоге любая внештатная бага/тикет/архитектурная проблема по итогам дизайна - и люди начинают кроить нужные задачи в попытках выгадать какое-то время чтобы успеть в 3 месяца. Задачи на выход начали выходить подозрительного качества. Техдолг менеджить стало в разы сложнее.
3) Все 20 департаментов по 50-100 человек должны естественно выполнять ритуалы связанные с релиз трейном. Это значит - посещать митинги на сотни человек (по 2-3 представителя от департамента), и что-то там слушать, показывать презентации и отчитываться. Толку от этого - примерно ноль, до этих PI за 6 лет работы в компании я даже не представлял, что большая часть этих людей существует. И с нашей работой они не пересекаются вообще никак. Но все сидят часами на этих планнингах, митингах, занимаемся рисовкой отчётов, рисовкой презентаций на выброс и прочей хренотой.
4) Релизы должны быть синхронизированы! Чтобы все показывали глобальное демо после 3х месяцев (опять на сотни рандомных человек) и чувствовали как движутся вперёд! С учётом пункта (2), при загрузке 100% и требовании 100% выполнение плана - времени релизить нет. Релизы стали выпускаться вместо каждого месяца - раз в три месяца, чисто чтобы под демо успеть. Зачем делать релиз если фидбек с него никак не будет использоваться ещё минимум 2 месяца до следующего планирования?
В итоге имеем падение качества продукта, падение частоты релизов, уменьшение гибкости (по 3 месяца ничего в требованиях менять нельзя), падение качества требований (т.к. надо с заказчиком/РнД/QA/Delivery всё обсудить и утрясти ровно перед планнингом, по актуальной информации, а на такой огромный скоуп это невозможно). В общем, выстрел себе в ногу удался.
Хотел вспомнить еще про либы uppercase/lowercase, но там вроде здравомыслие победило и повесили deprecated ворнинги.
https://www.npmjs.com/package/upper-case-first
Хотя 7 месяцев назад там ещё кто-то выпустил версию 3.0!
Как страшно жить! Понимаешь, не выбрасывают функции! Всё легаси! Раздутый функционал!
А вот не так однозначно. Обратная совместимость у Windows за счёт этого сильно лучше. Не, если поставить голый Центось и с него отдавать статику в инет - спору нет, Центось будет в сотни раз стабильнее. Но вот на реальной домашней системе с кучей разностороннего железа и софта... Обновил Винду с 10 до 11-ой - что отломалось? Ничего. ВСЁ работает.
Обновил Убунту с 20.хх до 22.хх. ОпенВПН перестал работать? Почему? Похерили обратную совместимость - зайди в репозиторий, поправь пару строчек, пересобери либу. Внешняя аудиокарта в Сонаре перестала нормально выводить звук, появился лаг. Почему? Потому. Зайди, скачай, поправь пару строчек, пересобери дрова. Миди клава? Домашний кинотеатр 7.1 через HDMI и + 2 доп. вывода звука? Циско? Шаринг видео в Тимс? Ну вы поняли. Зайди, найди проблему, скачай исходники, поправь, пересобери. А ещё есть и минорные обновления ОС почаще...
Спасибо, я потерплю кучу "ненужного" легаси. Понимаю, немного холиварно, но я несколько раз в своей жизни на домашнем компе пытался избавиться от Винды, довольно долго жил в мультибуте, но, блин, я так не могу. Пока мне для решения моих повседневных задач нужного кодить день вместо того чтобы два раза кликнуть на ярлык - я не готов тратить на это время. Пусть даже этот ярлык запустится не за секунду, а за полторы или две.
Сейчас в компании наблюдаю похожий процесс. Только тут нет выделенных аналитиков, вместо них в данном процессе выступает тимлид или делегированный на фичу разработчик. У них достаточно экспертизы, чтобы сказать "это вот надо делать не так, а иначе". В итоге процесс выглядит так:
Дизайнер с владедьцем продукта рисуют прототипы. Просто на основе блоков, без точных pixel perfect мокапов. Перебирают вариации на чём-то соглашаются.
Потом к этому процессу подключают тимлида. Он смотрит, вместе обсуждают, что можно сделать, что дорого и стоит заменить на другое решение. Договариваются, дизайнер уходит на рисование мокапов.
В конце собираются ещё раз опять, уже с точными мокапами, вносят минорные правки, если ещё есть и мокапы уходят в работу.
Многое, что делали с языком после С#6-7 - это порча хорошего и стройного языка и превращение его в джаваскрипт. Жабаскрипт такой только по историческим причинам, а тут сознательно портят язык.
Для верхнеуровневых языков скорость разработки зависит не от количества синтаксического сахара или того, пишешь ты конструктор за 30 символов или за 40, а от простоты и наглядности кода, возможностей выражать понятия доменной модели в коде наиболее близким способом, не увеличения, а лимитирования способов сделать одно и то же, ограничения возможностей "писать, что попало" и структурирование всего кода в определённые рамки, близость к натуральным языкам ддя простоты понятия и оперирования...
Основной тех. долг, который несёт косты для бизнеса это ошибки в проектировании доменной модели, макаронный код, проблемы времени жизни объектов и т.п., а не лишняя строка для определения пропсы.
А как вы распределённую транзакцию будете проверять без общесистемной регрессии? Или типа, сделали её распределённой - ну и бог бы с ней, больше не тестируем? Проблема-то никуда не ушла, тестировать надо.
Жизнь без распределённых транзакций проще и лучше. И это достижимо во многих кейсах, даже если вдруг одна БД вам претит - чуть более тщательный анализ доменной области скорее всего сожет позволить пилить микросервисы, чтобы одной семантически значимой сущностью владел один микросервис, а не несколько. Тогда весь этот гемморой резко пропадает.
И это класс. Если мне надо поставить одну аватарку, я не хочу чтобы приложение имело доступ ко всему архиву home video и пересланных в переписках файлов.
Лучше, но на сервере можно себе позволить загрузить две либы разных версий в память. А вот на фронте - это уже совсем другие расходы - сеть, объём кэша, cpu на парсинг - всё это сильно дороже. Оттуда и вылез этот ужасный формат семантической версионности с кучей проблем совместимости - из попыток не грузить одинаковые подзависимости.
Очередной "визионер" вида "все кругом тупые, всё общество заблуждается, а вот я сейчас расскажу как правильно". Вот прям все миллионы сидят, работают годами в области, развиваются, учатся и не понимают очевидной вещи, их очень надо просветить.
Последнего такого известного визионера месяцок назад раздавило на глубине 3км, тоже очень хотел откинуть нелепые стандарты, наработанные решения и сделать всё просто, на контроллерах от ХБокс и железной бочки. В принципе, это примерно показывает к чему это приведёт.
Первый же проект, написанный по указанному подходу, у которого жизненный цикл не "2 месяца написал и сдал", а лет 10 - будет вынуждено выкинут на помойку приемником после ТС вместе с миллионами денег потраченными на переработку и миграцию, потому что косты поддержки (за счёт неявных ошибок, когнитивной сложности кода, нестандартого подхода на который не найдёшь людей, невозможности масштабировать и прочего) будут ещё больше.
Почему фреймворки весят мегабайты и гигабайты, не задумывались? Потому что это не то, что надо экономить. Всем пофиг, жрёт ли фреймворк 10кб на машине разработчика или 10гб. Аналогично, с текущим каналом в большинстве своём на массовых задачах всем примерно пофиг, весит web-CRM (вы как раз упоминали веб приложения) 10кб или 100кб. А то, что является проблемой - это когнитивная сложность поддержки, стабильность и скорость внедрения фичей. И вот эту проблему решают фреймворки. По вашему подходу вы можете набрать команду из сплошных Principal Engineer-s и она прекрасно будет его держать. Остальные повалятся. А на проект на фреймворке можно посадить кучу мидлов и одного принципала и они будут в 3 раза дешевле, в 20 раз проще в найме и менеджменте и делать то же самое со скоростью 80%. И потом пересадить на соседний проект на том же фреймворке и они продолжат с такой же скоростью, без необходимости онбординга в полгода. И да, у каждого будет SSD на терабайт под фреймворки, это всё равно дешевле.
Не понял логической цепочки. Открыли вакансию, собираем всех по рынку доступных недели 2-3, нанимаем, закрыли вакансию. Поток резюме 5-15 штук в день это вполне норма, рынок международный. Не все резюме проходят до интервью.
По итогу на следующем этапе имеем как минимум двух человек, округляющих глаза друг на другаТерпеть не могу хайринг на аутсорсе. Было такое на прошлой неделе, кстати. Я обычно первые 7-8 минут трачу, чтобы рассказать о проекте, чтобы человек понимал, почему дальше будут те или иные вопросы. Рассказываю, вижу чем дальше, тем больше недоумения в глазах. Спрашиваю - что не так? Выясняется, что человек ищет вакансию только под Ангуляр и ничего больше не рассматривает, а у нас Ангуляр ни на одном из 150 проектов не используется и в описании вакансии не упоминается. Извинился, разошлись. HR объяснить мне, где у него голова, так и не смог. Видимо её нет.
Зачем задавать вопрос «что такое цикл» человеку с десяткой лет профильного опыта?Вы как-то исходите из предположения, что все люди в мире адекватны.
Отвечая на вопрос "заяем задавать базовые вопросы?". Потому что у кандидата 10 лет может быть в смежном стеке, а написать в cv он забыл. Потому что, может быть он занимался однотипными задачами и знает только один фреймворк, а на любой вопрос про базовое строение языка плывёт. Потому что он 10 лет сидел и занимался одним и тем же или просто его работа в компании не была никому интересна и он не развивался. Потому что резюме может быть в конце-концов чужим (было и такое в практике). Поэтому базовые навыки проверяются всегда. Знаешь - молодец, потратили на это 5 минут, пошли дальше. Опять же, случай из недавних, у человека 11 лет опыта, причём по резюме выглядит солидно. Но ответы на вопросы про процессы или архитектуру - ноль (ответы вида "я не знаю") и при попытке посмотреть навыки кодинга человек не может написать нормально перебор коллекции. Неожиданно, но бывает и такое.
Но если типовую задачку для оценки навыка кодинга нельзя заменить парой актуальных и живых репозиториев из github кандидата – это опять звоночек про гибкость процессов.Во-первых, мы опять же не знаем историю появления этого репозитория - чужой он, свой, написан самим человеком или с помощью, всё равно придётся по нему разговаривать. Поэтому оффлайн это не заменит. Во-вторых, оффлайн задача это проверка умения работать самостоятельно - вот тебе гугл, вот задача, которой нет в гугле в прямом виде, составь из всех производных нужное решение. Если человек в оффлайн не способен решить базовые задачи - нагуглить и синтезировать - то как он будет дальше работать? В-третьих, это экономия времени нанимающего (да, извините, это так). Чтобы просто открыть репо- нужно 5 минут, да. За них вы успеет увидеть кодстайл конкретного одного проекта и всё. А вот чтобы сделать выводы о качестве решения, нужно будет перешерстить несколько репо (обычно шлют ещё и несколько ссылок), найти более-менее сложный, разобраться в задаче, которую решает это приложение, понять архитектурные решение, прикинуть узкие места, пройтись по коду, найти эти узкие места, понять как человек это решил, наметить вопросы... Полчаса на репо. А у тебя 15 таких резюме в день, и в каждом n репосов. Сорри, но нереально.
А тестовая задача готовится один раз, решения все её уже известны нанимающему, как и потенциальные вопросы вокруг. Да, перекладывание затрат на кандидата, поэтому стараемся использовать по минимуму и ставим её необязательной. Но, кстати, когда пишем, что задача не обязательная - почти 100% всё равно присылают решение.
Не хватает в конце вывода - самое главное, а зачем это сделано-то? Типа круто, придумали, нарисовали, продавили, всех заняли. А что в итоге с конверсией и временем чекаута, выхлоп-то есть, сколько? Иначе же этим всем заниматься и не стоило, если аналитика не показала новых показателей, то все "закоренелые бюрократы" были правы.
Мне одному Composition Api кажется порочной технологией?
Всю жизнь программисты борятся со сложностью кода. Реактивное программирование уже даёт определённый скачок сложности, по сравнению, скажем, с процедурным, т.к. много вещей происходит "неявно", обеспечивается фреймворком, и это надо держать в голове и учитывать. Чтобы бороться с этой сложностью люди придумал всякие Flux паттерны, натянули мввм на компоненты, выстраивают жёсткую архитектуру и задают ограничения контекстов - используя иерархическую структуру компонентов и модулей, микрофронты, гексагоналку и т.п.
И тут вылезает технология, которая позволяет связать реактивно что угодно с чем угодно. И ты вот такой меняешь одно поле в классе и у тебя может поменяться в приложении всё что угодно и где угодно, причём это неявный вызов, отследить это возможностей крайне мало. Т.е. очень легко неправильно заиспользовать и вероятность получить тяжело поддерживаемый код с высокой связностью крайне высока. Так надо ли оно?
Обычно когда возникают вопросы с тем, что "сложно реиспользовать код" - это вопрос к тому, что кто-то либо наговнокодил, либо просто накопился тех.долг и текущие компоненты и модули надо либо делить на несколько, либо объединять в общий, и после рефакторинга оказывается что никакие такие дополнительные горизонтальные связи не нужны.
Собственно да. По сути это тот же монолит, но гораздо легче масштабируется и решает большую часть проблем. Интересно, увидим ли в "микросервисном" подходе кучу квадратов 200*200 разделённых железкой, что является вторым типичным масштабируемым решением.
Важный пункт - поддерживает раздельное туннелирование по белому листу. Т.е. вы можете включить впн только для определённых программ, а для игр, например, трафик пойдёт по обычному пути. Таким образом можно вообще его не выключать, включить только для заблоченных приложений и оставить висеть в фоне.
Остальные так сейчас и делают, никаких проблем.
Wcf очень многословен, использует как базу по умолчанию тяжёлый и медленный xml. И вас не смущает, что его развитие по сути было остановлено 12 лет назад? По сути можно ещё предложить сейчас писать веб приложения на вебформс. Ушло уже время, ушло, это медленные, неудобные, неподдерживаемые технологии, которые не построены на современных принципах.
Мне кажется одна из больших "болей" в микросервисах - это версионирование, жаль, что в статье это не затронули. По rest уже есть некие стандартные приёмы, библиотеки, типа делаешь /v2/ и дальше двухшаговая миграция. А как это работает с gRPC и protobuf? Есть какой-то стандарт, что делать с контрактом при необходимости сделать несовместимые изменения? Просто генерим второй контракт и дублируем все затронутые классы? Есть ли набор ошибок передающих статус deprecated?