Ограниченные, зависимые, тривиальные — с проблемами. Десять причин не использовать чужие библиотеки

14 комментариев
Ограниченные, зависимые, тривиальные — с проблемами. Десять причин не использовать чужие библиотеки

Игорь Шавловский, iOS-разработчик в neoviso, написал для Dev.by колонку о том, почему библиотеки не всегда полезны разработчику.

Я постоянно сталкиваюсь с тем, что нужно решать типовые задачи, которые отсутствуют в стандартных фреймворках. Одна из них встречается в 90% проектов ­­­­ — это боковое меню. У каждого разработчика есть любимый под (библиотека, включаемая в проект через CocoaPods) для решения такой задачи. Таких подов на просторах GitHub, наверное, уже больше сотни. Возникает проблема точного соответствия поведения меню и технического задания. Аспектов много: затемнение, взаимодействие с жестами главного контроллера, различное поведение на iPhone и iPad, правила открытия и скрытия меню, использование navigation controller внутри меню. Библиотека не охватит все задачи. Она может не поддерживать или, наоборот, иметь лишние неотключаемые анимации, не уметь синхронизироваться с другими операциями. 

Зачем вообще использовать библиотеку, если базовое меню писать 20 минут, а расширенное, со всеми «свистелками» ­­­­ — три часа? И в этом меню не возникнут упомянутые выше проблемы.

1. Чужой код = чужие ошибки

Любой код содержит ошибки. Но если в своём коде их легко найти и исправить, чужой код править сложнее. Если ошибка не лежит на поверхности, а является следствием неправильного подхода к архитектуре, то даже если вы исправите её в своей копии библиотеки, придётся исправлять её после каждого обновления от разработчика. Внести предложение по исправлению библиотеки — опять же не решение. Ошибкая для вас — для другого просто неправильный случай использования кода, поскольку это ваши нужды и ваше техническое задание.

2. Нет исходного кода

Часто библиотеки распространяются с исходным кодом, но не всегда. Тогда у разработчика возникают проблемы с анализом происходящего «внутри» библиотеки. Он не может предсказать поведение и возможные проблемы, убедиться, что правильно подготовил данные. А в случае, когда библиотека написана в плохом стиле или без надлежащей спецификации, невозможно понять, какой из схожих методов надо использовать и в какой последовательности.

3. Нет гарантий поддержки

Любая, в том числе самая продвинутая библиотека, в какой-то момент теряет популярность. А проекты, построенные на ней, рискуют потерять даже минимальную возможность поддержки обновлённого SDK. Часто на гитхабе можно заметить, как хорошую библиотеку, на которую забил оригинальный разработчик, забирают себе под крыло другие. Иногда из этого вырастают мощные фреймворки, которые становятся стандартами разработки.

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

4. Пределы каждой библиотеки

Часто библиотеки заточены под решение узкого круга задач и не стрессоустойчивы под большой параллельной нагрузкой или в нетипичных случаях. Простой пример ­­­­ — singleton-библиокеки, которые инициализируются единожды и не могут поменять параметры настройки в процессе выполнения. Или библиотека заточена под то, чтобы брать настройки из ресурсов приложения, а согласно вашей архитектуре настройки приходят с сервера при логине да ещё и могут меняться по какому-нибудь событию. Или библиотека запускает прекрасную анимацию, но не может начать её с середины, а вам позарез надо переложить превью на другой слой в процессе её выполнения. Этот список можно продолжать. У каждой библиотеки в Readme репозитория есть красивая гифка с примером работы и три строчки кода, рассказывающие, как легко её использовать. Но никто не ответит вам на вопрос «а что, если мне надо делать не так, а вот так?».

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

Чем больше библиотека, которую вы используете, тем больше шанс, что ей самой будут нужны поддерживающие её библиотеки. Здесь кроются одновременно две проблемы. Первая заключается в том, что сама библиотека страдает от описанных проблем. Вторая — зависимости могут пересекаться. Ваша программа и библиотека (или просто две библиотеки) могут использовать одну и ту же третью библиотеку, и только при счастливом стечении обстоятельств все они будут публично включать одну и ту же версию. В противном случае вы получите бесконечные ошибки линковки.

6. Утяжеление приложений

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

7. Тривиальность, необоснованная сложность, ограниченность

Конкретную библиотеку используют часто не потому что задача сложная, а потому, что разработчик ленив. Однажды мне попалась задача асинхронной обработки изображений на графическом процессоре. Я нашел отличную библиотеки, которая делала в точности то, что мне требовалось, но было несколько нюансов: она работала только в главном потоке, вызывалась с уровня view, а не model, имела сотни исходных файлов, в которых надо было отслеживать цикл работы. Вместо того, чтобы неделю перекраивать работающий код под свои нужды, я за день написал оболочку для чистого OpenGL и решил задачу двумя сотнями строчек кода. Притом код можно было использовать в любой момент работы программы примерно так же, как используют асинхронный сетевой запрос. На следующий день решение обросло кэшем и повторным использованием текстур для оптимизации более сложных операций — и вуаля! Я переписал библиотеку из многих тысяч строк кода и сделал её универсальной, расширяемой, читаемой и  быстрой. На это у меня ушло меньше времени, чем я потратил изначально на запуск сторонней библиотеки. Хороший урок.

8. Дичь в рантайме

Библиотеки имеют такой же доступ ко всем возможностям SDK, как и разработчик, и используют по полной, никакой песочницы. А что если разработчик не хочет этого? Больше всего в «гадить там, где выполняешься» преуспели библиотеки аналитики. Если раньше разработчик передавал им все необходимые события, сейчас они берут их сами. В iOS это делается через механизм method swizzling: библиотека просто подменяет родные методы SDK своими собственными, перекраивая все механизмы в вашем приложении так, чтобы потоки данных проходили через неё.

Однажды я заметил, что простая пересортировка «вьюх» стала выполняться слишком долго. Я остановил программу в момент одного из таких подвисаний и увидел, что моя библиотека аналитики буквально залезла внутрь UIKit и при каждом изменении иерархии «вьюх» проводит кучу ненужных мне вычислений, пытаясь найти компоненты, которые она бы умела трекать автоматически. Не удивился, когда увидел, что это невозможно отключить настройками библиотеки. Пришлось лезть в исходный код, чтобы со всем разобраться. Если учесть, что современная версия библиотеки поставляется без исходного кода, я навсегда застрял с просроченной «либой», где костылём подпёр дверь, за которой находится монстр метод-свизлинга. И это не единственная проблема с данной библиотекой.

9. Они меняют интерфейсы

Со временем библиотека эволюционирует, разработчик правит имена методов, улучшает код, делает рефактор. Это полезно для его кода, но не для вашего. Ваш код ведь работает! Захотите получить свежую фичу или исправление старой ошибки, а библиотека полностью поменяла свои интерфейсы, и теперь вам придётся рефакторить свой код вслед за ней. Более того, отдельные методы могут пропасть. Выше упомянутая библиотека аналитики потеряла событие окончания отправки данных на сервер, в результате этого я не мог отправлять аналитику до начала работы программы, чтобы быть уверенным, что startup crash не помешает этому.

10. Они не посылают события

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

Но невзирая на все «не», в той или иной степени, использование библиотек и фреймворков в нашей работе неизбежно. Во-первых, SDK и библиотек, включённых в стандарт разработки. Во-вторых, тех, что помогают решать сложные и/или трудоёмкие задачи: AR, построение графиков, реализация стандартов обработки данных, к примеру, парсеры, сетевые протоколы, базы данных.

В их использовании нет ничего плохого, но в следующий раз, начиная новый проект, задумайтесь, насколько вам нужен тот же jQuery, AFNetworking или что-то ещё. Возможно, будет полезней вместо слепого включения в проект изучить исходный код, подходы, которые использует та или иная библиотека, и написать свой код. Удобный, быстрый, универсальный, отказоустойчивый. Создавайте собственные готовые решения, собирайте качественный код и пишите свои библиотеки. Вероятно, когда-нибудь именно они войдут в чей-то стандарт разработки.

По теме
Все материалы по теме

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

«Умные окна» разработали учёные БГУ
«Умные окна» разработали учёные БГУ

«Умные окна» разработали учёные БГУ

Белорусский партнёр YouTube запустил на Product Hunt стартап для брендов
Белорусский партнёр YouTube запустил на Product Hunt стартап для брендов

Белорусский партнёр YouTube запустил на Product Hunt стартап для брендов

Разработчик с офисом в Минске запустил сервис видеозвонков для бизнеса
Разработчик с офисом в Минске запустил сервис видеозвонков для бизнеса

Разработчик с офисом в Минске запустил сервис видеозвонков для бизнеса

EnCata создала «антивирусные» дезинфицирующие рамки
EnCata создала «антивирусные» дезинфицирующие рамки

EnCata создала «антивирусные» дезинфицирующие рамки

Обсуждение

saz
saz
4

Если кратко - велосипеды, наше всё? :)

Ясное дело, что если кода на 3 часа (да даже на пару дней), то тащить для этого 3rdparty не нужно. Но совсем другое, когда велосипеды начинаются там, где не нужно.
Очень хорошо помню один проект, который мне пришлось поддерживать, где один "разработчик" реализовал свой бинарный протокол поверх TCP. Хотя задача сводилась к простому веб сервису. И помню те долгие часы отладки, когда из-за плохой реализации и кривого дизайна случались трудновоспроизвозимые сбои.

-1

Скорее тут про выбор между своими и чужими велосипедами :)

2

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

owl
owl
0

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

1

Оперативность - это тоже полезная вещь. 3 часа тут, 2 дня там и конкурент уже захватил рынок.

Anonymous
Anonymous
4

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

0

>Вы же инженеры б***ь, а строите из себя акул бизнеса.
Однозначно плюсую, золотые слова

0

акулы бизнеса дают заказ инженеру
в чем диссонанс?

Anonymous
Anonymous iOS Developer в ООО "Энвижен" (neoviso™)
0

Если читать статью внимательнее, то там сказано, что реализацию сетевых протоколов лучше взять готовую. Но в моей практике были случаи, когда тот же HTTP-клиент не реализовывал все фичи, описанные в RFC, и велосипед всё же пришлось изобретать. Баланс между покупкой и изобретением велосипедов - это как раз и суть статьи

-3

//Зачем вообще использовать библиотеку, если базовое меню писать 20 минут, а расширенное, со всеми «свистелками» ­­­­ — три часа? И в этом меню не возникнут упомянутые выше проблемы.
АХАХАХ. Вот только в 99% случаев ситуация прямо противоположная - на подключение сторонней библиотеки 20 минут, на свое решение - 3 часа. Наблюдаю это со всеми компонентами - от UI до in-apps.
Может автор статьи просто junior, но не напишет об этом, чтобы не испортить о себе впечатление?)

Anonymous
Anonymous
1

Вот вы зачем-то применили аргумент к личности. Какое отношение субъект (автор) имеет к объекту разговора? Какая разница кто автор, какое это иммет значение? Да и вообще, вы какой-то токсичный и эмоциональный. Фу.

Anonymous
Anonymous iOS Developer в ООО "Энвижен" (neoviso™)
0

Воу-воу-воу. 3 часа работы - это причина использовать чужой непроверенный код вместо своего? И это я junior?

0

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

Anonymous
Anonymous iOS Developer в ООО "Энвижен" (neoviso™)
0

Универсальнось и отказоустойчивость в этом случае контролирует сам разработчик, а не доверяет третьим лицам

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже