Здравствуйте, Sheridan, Вы писали:

S>>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
CC>>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.
S>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов.

Снова у Шеридана программисты некомпетентные. Может это ты разработку не понимаешь?

Надо вспомнить, что стоимость труда разработчиков выросла до небес, а стоимость стораджа упала ниже плинтуса, при этом сложность софта растет непрерывно.

> Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.

Актуализация либ это процесс крайне трудозатратный. Настолько трудозатратный, что большинство проектов просто отказываются и делают это только когда секюрити баг найден или что навроде. В самых популярных либах такое конечно протекает легко. Штука в том,что далеко не все сводится к тем самым хорошим и правильным либам, коих в общей массе единицы.

Например — обновил ты либу, упали тесты А. Фиксанул. Обновил другую — упали тесты Б. Фиксанул — снова упали А. Фиксанул — упали тесты Б. Обычно здесь надо засаживаться за глубокую отладку, что бы выяснить, почему либы несовместимы, писать тикеты, искать версии, которые хоть как то совместимы, или гуглить до посинения, пока кто нибудь не подскажет тебе комбинацию.
Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат.
И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.

За деньги, которые этот разработчик потратит на миграцию, можно проплатить хостинг-деплоймент-клауд на год. Отсюда ясно, что постоянно заниматься миграциями никто в своём уме не будет.

Поэтому обычно используются другие подходы, например — zero dependency, или all-in-one, или доккер, или lambda, или итд.

Здравствуйте, Sheridan, Вы писали:

S>>>Более того, предпочту нормальные бинари, не приносящие всё-внутри-себя-с-собой и страдающие от этого ожирением.
CC>>Дада, лучше те бинари, что требуют поставить для них пачку frameworks, да ещё и конкретных версий, которые ещё с другими такими же конфликтанут.
S>Это проблемы не бинарей, а раздрая в команде и некомпетентности программистов.

Снова у Шеридана программисты некомпетентные. Может это ты разработку не понимаешь?

Надо вспомнить, что стоимость труда разработчиков выросла до небес, а стоимость стораджа упала ниже плинтуса, при этом сложность софта растет непрерывно.

> Я удивляюсь как вообще можно не понимать что используемые либы надо актуализировать при их релизе сразу во всех проектах команды. Не получается при релизе либ — так хотя бы раз в квартал актуализировать.

Актуализация либ это процесс крайне трудозатратный. Настолько трудозатратный, что большинство проектов просто отказываются и делают это только когда секюрити баг найден или что навроде. В самых популярных либах такое конечно протекает легко. Штука в том,что далеко не все сводится к тем самым хорошим и правильным либам, коих в общей массе единицы.

Больше всего проблем доставляют шаред и транзитивные зависимости. Например — обновил ты либу, упали тесты А. Фиксанул. Обновил другую — упали тесты Б. Фиксанул — снова упали А. Фиксанул — упали тесты Б. Обычно здесь надо засаживаться за глубокую отладку что не всегда возможно, писать тикеты и ждать фиксов, искать версии, которые хоть как то совместимы, или гуглить до посинения, пока кто нибудь не подскажет тебе комбинацию.
Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат, и часто абсолютно непредсказуемо по продолжительности.
И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.

За деньги, которые этот разработчик потратит на миграцию, можно проплатить хостинг-деплоймент-клауд на год. Отсюда ясно, что постоянно заниматься миграциями никто в своём уме не будет.

Поэтому обычно используются другие подходы, например — zero dependency, или all-in-one, или доккер, или lambda, или итд.