Comments 24
Копипастить — это лучший метод защиты от зависимостей. Скопипастил и доволен. Они там баги у себя фиксят, CVE постят, а у нас всё хорошо. 0 CVE, ноль фиксов за 5 лет как скопипастили openssl в свои исходники.
/сарказм.
/сарказм.
Конечно, ведь лучше каждые 1-3 строки выделять в отдельный npm пакет
/сарказм, чисто в противовес.
А что, у вас в практике был пример подобной жести?
/сарказм, чисто в противовес.
А что, у вас в практике был пример подобной жести?
Обычно зависимость имеет строго определенную версию, которая не меняется годами, следуя принципу “Работает – не трогай!”. Если спустя много лет бага таки находится, то часто проще поправить ее самому, скопипастив исходный код, поскольку есть большой шанс, что за это время библиотека потеряла обратную совместимость или вообще была заброшена.
Феномен ПО с открытыми исходниками, которые распространяются бесплатно через интернет, во многом вытеснил старые практики закупки ПО. Когда повторное использование было ещё трудным, мало проектов внедрило такие зависимости. Хотя их лицензии обычно отказывались от каких-либо «гарантий коммерческой ценности и пригодности для конкретной цели»
Вот только при чем тут Open Source?
Отказ от гарантий, это стандартная практика практически для всех вариантов коммерческих поставок проприетарного ПО. Максимум, за что они отвечают финансово, это не больше стоимости оплаченной лицензии.
То есть, реальных гарантий применимости и ответственности нет ни у проприетарных, ни у свободных компонентов, но в первом случае ты не только платишь за это деньги, но у тебя даже нет возможности что-либо изучить и/или исправить, т.к. исходников тоже нет.
А проблема действительно очень серьезная, и как её решать непонятно.
Старая добрая мечта собирать программы из кубиков. Потихоньку реализуется, но за это приходится платить. Иногда страшную цену.
Есть пара аспектов, которые хочется акцентировать отдельно.
Проблема ответственности. Мы в ответе за тех, кого наплодили. Если я выпускаю софтинку, то я, только я, и никто кроме меня не отвечает за то, как она себя ведёт. Заказчику не объяснишь, что он не сдаст годовую отчётность и влетит на крупный штраф потому, что некий чел из Интернета с неразборчивым ником добавил дополнительный обязательный параметр в своё API. Исполнитель — я, и никто кроме меня не несёт ответственности за выполнение работ. Завязываясь на чужой код, мы надеемся переложить часть ответственности на авторов библиотек и владельцев сервисов, и нам невдомёк, что это вообще невозможно сделать. Ответственность — только на непосредственном Исполнителе, и ни капли ответственности ни на кого переложено быть не может. Такова суровая реальность, с которой ничего поделать нельзя.
Если кроме ответственности за свою работу мне приходится нести ответственность за то, что никто из тысяч незнакомых мне людей не набухается, не скурвится и не сойдёт с ума, то ну нафиг такое счастье.
Проблема сложности. Решение конкретной прикладной задачи всегда проще решения всех задач этого класса «в общем виде». Бывает так, что полноценный самодельный «велосипед» — пара тысяч строк весьма примитивного кода, но можно сделать «по-правильному», без велосипедов. Будет всего полтысячи (уникальная логика никуда не денется) строк, склеивающих добываемые извне кубики, внутри которых отдельные куски задачи реализованы «в общем виде». А раз «в общем виде», то, значит, сложно и с массой доп. расходов. Фактически пара тысяч строк превратилась не в полтысячи, а в сотни тысяч строк кода. Почему оно всё стало таким огромным и дико тормозит? А потому.
Программа подсчёта калорий не становится лучше от того, что в неё «паровозиком» влились никогда ею не используемые численные методы, функции комплексных переменных, поддержка полного комплекта сетевых протоколов и адаптеры под 40 различных СУБД. «Сложнее значит лучше» — целиком порочный предрассудок.
Есть пара аспектов, которые хочется акцентировать отдельно.
Проблема ответственности. Мы в ответе за тех, кого наплодили. Если я выпускаю софтинку, то я, только я, и никто кроме меня не отвечает за то, как она себя ведёт. Заказчику не объяснишь, что он не сдаст годовую отчётность и влетит на крупный штраф потому, что некий чел из Интернета с неразборчивым ником добавил дополнительный обязательный параметр в своё API. Исполнитель — я, и никто кроме меня не несёт ответственности за выполнение работ. Завязываясь на чужой код, мы надеемся переложить часть ответственности на авторов библиотек и владельцев сервисов, и нам невдомёк, что это вообще невозможно сделать. Ответственность — только на непосредственном Исполнителе, и ни капли ответственности ни на кого переложено быть не может. Такова суровая реальность, с которой ничего поделать нельзя.
Если кроме ответственности за свою работу мне приходится нести ответственность за то, что никто из тысяч незнакомых мне людей не набухается, не скурвится и не сойдёт с ума, то ну нафиг такое счастье.
Проблема сложности. Решение конкретной прикладной задачи всегда проще решения всех задач этого класса «в общем виде». Бывает так, что полноценный самодельный «велосипед» — пара тысяч строк весьма примитивного кода, но можно сделать «по-правильному», без велосипедов. Будет всего полтысячи (уникальная логика никуда не денется) строк, склеивающих добываемые извне кубики, внутри которых отдельные куски задачи реализованы «в общем виде». А раз «в общем виде», то, значит, сложно и с массой доп. расходов. Фактически пара тысяч строк превратилась не в полтысячи, а в сотни тысяч строк кода. Почему оно всё стало таким огромным и дико тормозит? А потому.
Программа подсчёта калорий не становится лучше от того, что в неё «паровозиком» влились никогда ею не используемые численные методы, функции комплексных переменных, поддержка полного комплекта сетевых протоколов и адаптеры под 40 различных СУБД. «Сложнее значит лучше» — целиком порочный предрассудок.
Так нету никакой ответственности. Вот не сдал ваш заказчик годовую отчётность и влетел на крупный штраф «потому, что некий чел из Интернета с неразборчивым ником добавил дополнительный обязательный параметр в своё API» и что вы сделаете? Сепуку? Навряд ли. Максимум скажете «ну извини, чувак». И это ответственность?
Но это же объективно свинство! Да, можно себе подложить соломку, вписав в договор мелким шрифтом что-то вроде «THE SOFTWARE IS PROVIDED „AS IS“, WITHOUT WARRANTY OF ANY KIND...», но от этого факт обмана доверившегося никуда не девается, разве нет?
Конкретный разработчик сепуку, естественно, не сделает, но в договоре между компанией и большим корпоративным заказчиком вполне может быть прописан уровень сервиса и санкции за его невыполнение.
Понятно, что все будет в пределах ответственности компании, но банкротится из-за сторонней либы не особо приятно. Плюс репутация страдает даже из-за небольших косяков.
Вы отдали новую сборку приложения заказчику не протестировав её. Глупо обвинят кого-то ещё.
Ах, если бы всё было так просто…
На самом деле всё просто. Просто всё упирается в количество денег, которое нужно потратить, что бы обеспечить требуемое качество.
А ещё упирается в то, что есть обстоятельства, которые мы контролируем, а есть обстоятельства, которые не контролируем. Создавая свой продукт, вполне нормально стремиться свести к минимуму объём неконтролируемых обстоятельств.
Всякое такое «да нормально всё будет», «да все так делают», «сто раз проскакивали и сейчас проскочим» — самонадеянная глупость. На сто первый раз оказывается, что для задействования очень-очень важного сервиса нужна новая версия библиотеки, которая напрочь несовместима с образовавшейся за долгие годы горой зависимостей на дремучее легаси.
Всякое такое «да нормально всё будет», «да все так делают», «сто раз проскакивали и сейчас проскочим» — самонадеянная глупость. На сто первый раз оказывается, что для задействования очень-очень важного сервиса нужна новая версия библиотеки, которая напрочь несовместима с образовавшейся за долгие годы горой зависимостей на дремучее легаси.
> Проблема сложности.
Готовыми ОС, компиляторами и прочим тоже лучше не пользоваться, чтобы всё не было таким огромным? Извините за сарказм, просто эти наезды на зависимости мне кажутся ужасно недальновидными.
Мы уже давно строим пирамидки из кубиков. Пирамидки растут, но на самой вершине у них всегда были маленькие, убогие и кривые недокубики. Когда-то и компиляторы были убогими, а на ассемблере можно было сделать лучше. Со временем опыт накапливается, шишки набиваются и нижние слои зависимостей крепнут и улучшаются. А без этого мы так и останемся на одной и той же ступени развития. Очень хочется взглянуть на программы людей, критикующих современные фреймворки и нагромождения зависимостей. И сказать им о том, что их софт дерьмо. Потому что сегодня абсолютно весь софт дерьмо. Но если игнорировать всё кроме производительности, потребления памяти и занимаемого места на диске то, конечно, можно гордиться своими поделками без зависимостей.
Проблема есть. Она очень серьёзная. Но даже намёки на бегство, вместо решения проблемы, считаю приступными.)
Готовыми ОС, компиляторами и прочим тоже лучше не пользоваться, чтобы всё не было таким огромным? Извините за сарказм, просто эти наезды на зависимости мне кажутся ужасно недальновидными.
Мы уже давно строим пирамидки из кубиков. Пирамидки растут, но на самой вершине у них всегда были маленькие, убогие и кривые недокубики. Когда-то и компиляторы были убогими, а на ассемблере можно было сделать лучше. Со временем опыт накапливается, шишки набиваются и нижние слои зависимостей крепнут и улучшаются. А без этого мы так и останемся на одной и той же ступени развития. Очень хочется взглянуть на программы людей, критикующих современные фреймворки и нагромождения зависимостей. И сказать им о том, что их софт дерьмо. Потому что сегодня абсолютно весь софт дерьмо. Но если игнорировать всё кроме производительности, потребления памяти и занимаемого места на диске то, конечно, можно гордиться своими поделками без зависимостей.
Проблема есть. Она очень серьёзная. Но даже намёки на бегство, вместо решения проблемы, считаю приступными.)
Представляю, каково будет отлаживать/поддерживать поделия на NodeJS через 10-20 лет. Репозитории поддерживаться бесконечно не будут (вместе со всеми версиями этих тривиальных пакетов). И вот кому-то будет задача как-то разбираться в этой каше из 5,000 зависимостей для helloworld, искать где их скачать, и что они делали вообще.
Как поётся в одной хорошей песенке,
So why complain, I feel no shame, I've used my skill
And the next generation has to pay the bill
Кто действительно будет заниматься поддержкой — сольет все нужное в корпоративный репо, естественно, и будет спокойно поддерживать.
А кто на 10-20 лет бросит код, а потом вдруг «ой а сейчас тут подправить надо» — тот сам себе злобный буратино.
Можно подумать, с поддержкой того же брошенного кода на С++ 20-летней давности сильно легче.
А кто на 10-20 лет бросит код, а потом вдруг «ой а сейчас тут подправить надо» — тот сам себе злобный буратино.
Можно подумать, с поддержкой того же брошенного кода на С++ 20-летней давности сильно легче.
Как то я запутался: нужно ли в переводе указывать автора оригинального текста и ссылку на него?
UFO just landed and posted this here
Статья называется «Наша проблема…», а автор из Гугла.
В гугле нет проблемы конфликта версий. В общем репозитории одна версия. А про обновления в статье есть: нужно соблюдать баланс, т.к. обновлять слишком редко — затраты на само обновление (стремятся к затратам на добавление новой зависимости) и риск не получить обновление безопасности, а обновлять слишком часто — относительно мелкие, но частые затраты на review приехавших изменений. Можно поэкспериментировать с новыми версиями, и обновить, если оно того сто́ит.
Sign up to leave a comment.
Наша проблема c зависимостями