?

Log in

No account? Create an account

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
Ну, за независимость!
усы2
tonsky
Управлять зависимостями трудно. Сам факт того, что такое понятие существует, уже намекает, что там есть с чем повозиться (простите мне чересчур мягкую формулировку, я сдерживаюсь изо всех сил). Поэтому один из важных принципов разработки — не тащить зависимости. В институте учат, что переиспользование кода — главная благодетель (и эта мантра наделала ужас сколько вреда). Так вот, переиспользование кода из сторонней библиотеки — тот случай, когда копипаста лучше переиспользования. Бывают библиотеки, большие и сложные, дающие бонус только целиком. Зато он существенный, и без него никак. Тяжелая алгоритмика. Новые качества. Тогда — конечно. А всякие утилитки, функции на десять строчек, удобные оберточки над платформой — задумайтесь, выдохните, и не тащите. Скопируйте одну функцию, если правда удобно. Я уж не говорю про случаи, когда быстрее сделать, чем искать, какая библиотека это уже делает (может это форма социализации такая, использовать чужой код, даже тривиальный? Или неуверенность в себе?). Особо остро выделяются свалки, где много разного, а раз много, значит каждый релиз что-то да сломают. Вообще, жалко, что так мало у нас ценят законченные вещи. Доделанные до конца, с фиксированым скоупом, а значит стабильные, не меняющиеся.

Есть еще конфликты версий, но с этим проще. Следуйте принципу: в своем приложении творите что душе угодно, тащите сколько угодно хлама, если времени не жалко потом его обновлять. Но если делаете библиотеку — у нее не должно быть зависимостей. От слова совсем. Полностью самодостаточный код, зависит только от платформы. Да, несправедливо по отношению к авторам библиотек — не вкусить им плодов прогресса и удобства опенсорсных АПИ (гг). Но эта жертва сэкономит непропорционально много времени всем остальным. Если подумать не о себе, а о потенциальных заинтересованных в библиотеке коллегах, понятно, что у них в приложении организационные вопросы уже как-то решены — логирование, коммуникация, хранение стейта, управление подсистемами, event loop. Если автор библиотеки пытается что-то из этого заиспользовать в библиотеке (упростить жизнь себе? помочь пользователям?), очевидно, он будет только мешать. Крепитесь, это не так уж страшно.


(Анонимно)
Стоит помнить, что браузер и всякие рантаймы типа JRE/.NET - тоже зависимости. Если немножко подумать, любой другой написанный кем-то кусок кода, с которым приходится взаимодействовать - тоже зависимость.

Да, копипастить нужный код вместо того, чтобы тащить за хвост всего слона — дельная мысль. Насчёт остального не уверен. Move fast and break things.

Зависит от...

Пять-десять строчек можно и скопипастить, чтобы не тащить зависимость.
А иногда лучше таки тащить -- чтобы баги в либе были таки проблемами либы, а не своего кода

> копипаста лучше переиспользования.

Баги править тоже копипастой?

Мне кажется, иногда вопрос чаще все же в том, можно ли баг исправить своими силами или обойти, или быстренько задействовать человека, который поломку устранит. Когда проект настолько велик, что над ним работают 10 или больше человек, все приложение - одна большая зависимость, если на то пошло.
Я с очень большим трудом верю, что в приемлемые сроки можно сделать проект, не использующий внешних зависимостей. Даже если нет там такой уж сложной алгоритмики.
Ну, то есть, у любой палки больше одного конца )

Зависимости у проекта — это нормально, а вот у библиотеки — нет. Библиотека по определению требует гораздо более взвешенного и аккуратного отношения, потому что ее другие люди предполагается что тащить к себе будут.

Точка зрения на конфликты версий понятна, но обусловлена какими-то древними понятиями. В идеальном мире дублирования кода не должно быть никогда, особенно в библиотеках. Одни библиотеки переиспользуют другие и все версии и АПИ доступны в глобальном реестре (мавен, ага).

Даже если бы maven был удобным пакетным менеджером библиотек, всё равно при некоторой сложности зависимостей начинаются проблемы, неразрешимые пакетным менеджером. Например, необходимость прилинковать в программу три версии одной библиотеки из-за diamond problem и невозможности сохранить 100% совместимость даже при минорных исправлениях. Так же количество кода начинает переходить в качество - долго скачивается, долго обновляется, тормозит IDE, тормозит build, сложно разобраться в 3 гигабайтах кода, невозможно починить все security-баги своего проекта, так у тебя в проекте - все баги всех используемых библиотек, и тд.

Edited at 2015-11-21 21:40 (UTC)

То, что зависимости это зло, и то что ни в коем случае нельзя считать reuse однозначным благом - обозначено верно.

Но предложенное решение "копипастить" - это тоже зло, и невозможно считать однозначно верным решением.

Решение - к сожалению не руках автора новой библиотеки, а в руках авторов используемой библиотеки (чтобы была возможность взять её кусочек, а не целиком),
языка/платформы (чтобы в стандартной библиотеке было побольше всего, чтобы не писать свое конвертирование числа в строку, свой UTF-8, и тд),
инфраструктуры платформы (пакетной системы библиотек).



Копипаста - не панацея. В идеале должен быть компромисс в виде не просто копирования, а подключения зависимостей с возможностью полного контроля над подключенными к библиотеке зависимостями. Верным шагом в этом направлении являются git submodules.

> зависимостей с возможностью полного контроля над подключенными к библиотеке зависимостями

Это и есть copy-paste.

вам не кажется, что ломание совместимости и создание багов это качество вашей платформы и среды? я вот со своей башни такое вижу очень редко. хотя даже это не отменяет того, что использовать надо тоько проверенные версии библиотек.

исключительно зависит от размера пользовательской базы.
от сообщества.
оно большое - проблем не будет, всё будет починено, собрано, и как в руби. хотя все неймспейсы общие, и всё плотно утрамбовывается чуть ли не в один-единственный класс через коллбеки.
мало людей - будет всегда полусырое, безумные неофициальные 0.10.0-SNAPSHOT месяцами, или как в хаскеле - когда всё не очень хорошо вообще собирается.
чего поделать. но в большом сообществе явно лучше тащить зависимость, чем не тащить.

Edited at 2015-11-21 22:35 (UTC)

Библиотека от Гугла — достаточно солидно? Java сообщество достаточно большое?

Да-да. Сколько одна только Guava нам проблем принесла -- можно только гадать. При том, что во многих проектах из неё используется шиш, да маленько.

А ещё бывает, когда приходит человек и говорит: "смотри, тут и тут ажно 15-с-половиной строк кода инициализации логгера похожи, а давай библиотеку утилит логгирования сделаем, чтоб все её в компании использовали!".

Удивительно, сколько людей заучили мантру "копипастить -- плохо" и не понимают, что в итоге имеет значение только TCO, и банальная копипаста часто может иметь меньший, а главное, более предсказуемый TCO.

Альтернатива -- все в компании передают друг другу тайные знания инициализации логгера, (или еще какой херни). Только постигшим веру местного гуру к ним приобщают.

Я не знаю, как в эрланге правильно не использовать тот же lager или lhttpc в библиотеке.

навскидку XPath/html парсер, Protobuff - тоже своё велосипедить?!

В приложении пожалуйста. Но нафига они в библиотеке?

Согласен. Нам нужен другой уровень абстракции - нежели неряшливая библиотека с зависимостями - репозиторий функций, которые инлайняться к тебе в проект ( с возможностью обновления средствами source control и анализа кода). Ребята из haskell обсуждали подобную идею.

Репозиторий функций — это имеется в виду internet of code?

Finish Your Project

If there is one principle that should be added to the UNIX philosophy, it is:

"Finish your project."

http://250bpm.com/blog:50

Re: Finish Your Project

охуенно, второй час читаю.

Очень однобоко сказано, но многим действительно стоило бы хотя бы задуматься.