Я, к сожалению, так и не уловил профита. Сперва рассказывается о тяжеловесности контроллеров - фильтрах, атрибутах и т.п. А потом берётся minimal API и... И из него делаются те же самые контроллеры, только всю обвязку надо повторно написать руками вместо готовой предоставленной Майкрософтом. А профит-то где? Пара процентов перформанса? Я лучше буду иметь меньше самописного кода и большую структурированность, это в костах больше сэкономит.
С одной стороны - да. С другой стороны это провоцирует ошибки. Расположил кнопку рядом с другим контентом? Оп, outline внезапно "обрезается" и пропадает под фоном соседней колонки.
Увеличил z-index? Ой, оно полезло поверх модалок.
В общем, поскольку outline отрисовывается поверх других элементов - вызывает дополнительные усилия по z выравниванию всего, особенно при использовании сторонних либ с уже заданным позиционированием.
Не очень понял посыл с облаками. Мне кажется, это как раз проблемное. Сегодня ты юзаешь яндекс.облако, завтра ты не можешь долезть до него с забугорного айпи. Сегодня ты юзаешь майкрософт, а завтра тебя за русский паспорт забанили. Вон, myheritage все русские аккаунты снесла неделю назад. Поэтому имхо локальные решения лучше. Бекапы по ночам на валяюшийся hdd на 8 Тб. Чуть-что, кинул hdd в сумку - и всё, поехал куда надо. На въезде в другую страну только в ~10 странах будут лезть в ваш hdd, Россия, США, Израиль, С.Корея... Просто туда не ездить, остальным 230+ странам пофигу на содержание вашего компа.
Мне кажется игры, которые как сейчас называют бумеры были "настоящие игры" - действительно развивали память, ориентацию на местности, логическое мышление и т.п. Я помню лет в 7 проходил descent 2... и вот там, если у тебя нет памяти и пространственного воображения - то дальше второго уровня ты не пройдёшь. Потому что надо в сложном неструктурированном 3д запомнить по мельчайшим деталям место и потом смочь туда вернуться.
И я почти уверен, что благодаря этому и другим схожим играм у меня нет топографического кретинизма. Потому что я если прохожу где-то один раз - у меня моментально в голове рисуется карта и дальше я могу без проблем ориентироваться.
Вопрос горизонта планирования. Преждевременное закладывание ситуаций, которых даже на горизонте нет в требованиях - оверинжиниринг. Возможно, эти заложенные на будущее куски никогда и не пригодятся и будут только утежелять систему.
А с точки зрения сотрудника — HR не нужны. Это должность, придуманная бизнесом как замена профсоюзам, якобы «будет заботиться о сотрудниках и помогать им», чтобы люди сами не боролись за свои права и окружение. Найм им впихнули в дополнение, People Management же — ну вот и менеджите всё, может сократит время которое требуется остальным тратить на найм.
Вот только одна проблема — HR получает зарплату от владельца, а не от сотрудников. Поэтому понятно, чьи интересы HR на самом деле соблюдает. Владельцу‑то оно понятно зачем нужно. Профессионально обманывать сотрудников, чтобы не возбухали и не координировались. Организовывать бурную деятельность с праздниками, ДР и прочей билибердой отвлекая от насущных проблем. «Мы же заботимся о вас, мы семья» и т. п. Манипулировать понятиями и цифрами, занижая ЗП и сокращая косты для бизнеса. Вот задача HR.
Эксперимент странный. Удалять последние n лет релевантного опыта - зачем? А остальной опыт - может он вообще нерелевантен сейчас на вакансию?
Что за выводы по верхней границе вилки? Я и сейчас вам и всем своим сотрудникам скажу - у них у всех поголовно зп меньше верхней границы вилки, математика, оказывается, так работает - верхняя граница всегда больше значений внутри отрезка.
Сама-то мысль здравая, но попытка её подтвердить - это какое-то натягивание совы на глобус.
А вообще по практике лучше всего если поиском занимается нанимающий менеджер. Если это программисты, то обычно это тимлид. У него не больше 4-7ми людей, т.е. поиском ему заниматься не приходится часто, поэтому не жрёт много времени. Фильтры в линкедин или хх он закинуть справится лучше hr. Ну и его мотивация получается самой полной - а) надо нанять человека быстрее, ибо задачи нужно делать, от которых зависчт его кпи. б) нанять человека надо подходящего, чтобы он улучшил перформанс команды. в) нужно чтобы человек не уволился, потому что опять же пострадают задачи, кпи и надо будет снова поиском заниматься.
Если есть типы с кучей Omit, Pick, Partial и т.п. - скорее всего, стоит на проекте стоит навести порядок в архитектуре. Независимо от размера проекта.
У меня есть проект в полсотни микросервисов с микрофронтами, легаси и оркестратором использование всех этих модификаторов скорее всего не превышает 20 штук в корнер кейсах. Всегда есть внешние модели - ДТО с АПИ или внешних либ и внутренние сущности, которые реально отображаются и отражают семантику конкретного экрана, и слой маппинга между ними. Омитам при таком варианте взяться неоткуда, всегда есть только один понятный тип, без обрезков.
Омит-ы это наследие попыток писать на ts так же как на js. И вот от этого как раз ts и спасает. В легаси js регулярно сталкиваюсь с тем, что функция принимает объект, модифицирует его и возвращает другой объект. "Ну там всего одно поле добавить/удалить надо было, не менять же весь объект из-за этого". В итоге, объект, пройдя пару таких функций становится неузнаваемым, так что понять, с чем же ты работаешь можно только про-реверс-инжинирив весь код через который этот объект может проходить - а это может быть от дня работы просто выкинутых. TS же дисциплинирует. Никаких случайных мутаций, сказано - верни 3 поля - значит верни 3 поля или расширяй интферейс и учитывай все нужные кейсы, никаких "костылей".
Используем очень активно веб-компоненты уже года четыре. Оркестатор микрофронтендов, но т.к. много легаси, то завёрнуто всё в вебкомпоненты для совместимости.
Основные проблемы, которые мешают:
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 на терабайт под фреймворки, это всё равно дешевле.
Я, к сожалению, так и не уловил профита. Сперва рассказывается о тяжеловесности контроллеров - фильтрах, атрибутах и т.п. А потом берётся minimal API и... И из него делаются те же самые контроллеры, только всю обвязку надо повторно написать руками вместо готовой предоставленной Майкрософтом. А профит-то где? Пара процентов перформанса? Я лучше буду иметь меньше самописного кода и большую структурированность, это в костах больше сэкономит.
С одной стороны - да. С другой стороны это провоцирует ошибки. Расположил кнопку рядом с другим контентом? Оп, outline внезапно "обрезается" и пропадает под фоном соседней колонки.
Увеличил z-index? Ой, оно полезло поверх модалок.
В общем, поскольку outline отрисовывается поверх других элементов - вызывает дополнительные усилия по z выравниванию всего, особенно при использовании сторонних либ с уже заданным позиционированием.
Не очень понял посыл с облаками. Мне кажется, это как раз проблемное. Сегодня ты юзаешь яндекс.облако, завтра ты не можешь долезть до него с забугорного айпи. Сегодня ты юзаешь майкрософт, а завтра тебя за русский паспорт забанили. Вон, myheritage все русские аккаунты снесла неделю назад. Поэтому имхо локальные решения лучше. Бекапы по ночам на валяюшийся hdd на 8 Тб. Чуть-что, кинул hdd в сумку - и всё, поехал куда надо. На въезде в другую страну только в ~10 странах будут лезть в ваш hdd, Россия, США, Израиль, С.Корея... Просто туда не ездить, остальным 230+ странам пофигу на содержание вашего компа.
Я справлялся клавиатурой и мышью. Но да, игра 96го года и двумя джойстиками, наверное, было бы удобно. :)
Мне кажется игры, которые как сейчас называют бумеры были "настоящие игры" - действительно развивали память, ориентацию на местности, логическое мышление и т.п. Я помню лет в 7 проходил descent 2... и вот там, если у тебя нет памяти и пространственного воображения - то дальше второго уровня ты не пройдёшь. Потому что надо в сложном неструктурированном 3д запомнить по мельчайшим деталям место и потом смочь туда вернуться.
И я почти уверен, что благодаря этому и другим схожим играм у меня нет топографического кретинизма. Потому что я если прохожу где-то один раз - у меня моментально в голове рисуется карта и дальше я могу без проблем ориентироваться.
Вопрос горизонта планирования. Преждевременное закладывание ситуаций, которых даже на горизонте нет в требованиях - оверинжиниринг. Возможно, эти заложенные на будущее куски никогда и не пригодятся и будут только утежелять систему.
В общем, как всегда, нужно думать по месту.
А с точки зрения сотрудника — HR не нужны. Это должность, придуманная бизнесом как замена профсоюзам, якобы «будет заботиться о сотрудниках и помогать им», чтобы люди сами не боролись за свои права и окружение. Найм им впихнули в дополнение, People Management же — ну вот и менеджите всё, может сократит время которое требуется остальным тратить на найм.
Вот только одна проблема — HR получает зарплату от владельца, а не от сотрудников. Поэтому понятно, чьи интересы HR на самом деле соблюдает. Владельцу‑то оно понятно зачем нужно. Профессионально обманывать сотрудников, чтобы не возбухали и не координировались. Организовывать бурную деятельность с праздниками, ДР и прочей билибердой отвлекая от насущных проблем. «Мы же заботимся о вас, мы семья» и т. п. Манипулировать понятиями и цифрами, занижая ЗП и сокращая косты для бизнеса. Вот задача HR.
Эксперимент странный. Удалять последние n лет релевантного опыта - зачем? А остальной опыт - может он вообще нерелевантен сейчас на вакансию?
Что за выводы по верхней границе вилки? Я и сейчас вам и всем своим сотрудникам скажу - у них у всех поголовно зп меньше верхней границы вилки, математика, оказывается, так работает - верхняя граница всегда больше значений внутри отрезка.
Сама-то мысль здравая, но попытка её подтвердить - это какое-то натягивание совы на глобус.
А вообще по практике лучше всего если поиском занимается нанимающий менеджер. Если это программисты, то обычно это тимлид. У него не больше 4-7ми людей, т.е. поиском ему заниматься не приходится часто, поэтому не жрёт много времени. Фильтры в линкедин или хх он закинуть справится лучше hr. Ну и его мотивация получается самой полной - а) надо нанять человека быстрее, ибо задачи нужно делать, от которых зависчт его кпи. б) нанять человека надо подходящего, чтобы он улучшил перформанс команды. в) нужно чтобы человек не уволился, потому что опять же пострадают задачи, кпи и надо будет снова поиском заниматься.
Если есть типы с кучей Omit, Pick, Partial и т.п. - скорее всего, стоит на проекте стоит навести порядок в архитектуре. Независимо от размера проекта.
У меня есть проект в полсотни микросервисов с микрофронтами, легаси и оркестратором использование всех этих модификаторов скорее всего не превышает 20 штук в корнер кейсах. Всегда есть внешние модели - ДТО с АПИ или внешних либ и внутренние сущности, которые реально отображаются и отражают семантику конкретного экрана, и слой маппинга между ними. Омитам при таком варианте взяться неоткуда, всегда есть только один понятный тип, без обрезков.
Омит-ы это наследие попыток писать на ts так же как на js. И вот от этого как раз ts и спасает. В легаси js регулярно сталкиваюсь с тем, что функция принимает объект, модифицирует его и возвращает другой объект. "Ну там всего одно поле добавить/удалить надо было, не менять же весь объект из-за этого". В итоге, объект, пройдя пару таких функций становится неузнаваемым, так что понять, с чем же ты работаешь можно только про-реверс-инжинирив весь код через который этот объект может проходить - а это может быть от дня работы просто выкинутых. TS же дисциплинирует. Никаких случайных мутаций, сказано - верни 3 поля - значит верни 3 поля или расширяй интферейс и учитывай все нужные кейсы, никаких "костылей".
Используем очень активно веб-компоненты уже года четыре. Оркестатор микрофронтендов, но т.к. много легаси, то завёрнуто всё в вебкомпоненты для совместимости.
Основные проблемы, которые мешают:
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 на терабайт под фреймворки, это всё равно дешевле.