Часто можно услышать фразу: «Зачем писать свой велосипед? Возьми готовую либу и пользуйся! За тебя уже все написали». Особенно часто подобные выражения слышат начинающие разработчики. При решении любой задачи они начинают смотреть готовые либы и бездумно тянуть их в свой проект. В этой статье Вы узнаете к каким последствиям может привести бездумное внедрение сторонних библиотек.
Я всячески рекомендую избегать добавления внешних библиотек в свой проект. Однако это не значит, что использовать библиотеки — зло, а Ваш Gradle файл вовсе должен быть очищен от любых внешних зависимостей! Я хочу донести мысль, что перед добавлением новой библиотеки нужно провести очень серьёзный анализ. Чтобы понять, как анализировать библиотеки, давайте рассмотрим с какими потенциальными проблемами Вы можете столкнуться при добавлении новой библиотеки в Ваш проект.
Большинство библиотек не сильно увеличивают размер Вашего приложения. Но существуют такие либы, после добавления которых Ваше приложение увеличится в разы! Например, библиотека Realm может увеличить размер APK с 4MB до 12MB. В среднем приложение весит 100MB-200MB и лишние 8MB могут быть не заметны. Но не забывайте, что Realm не единственная библиотека, которая негативно влияет на размер APK. А можно ли уменьшить размер APK, используя эту зависимость? Да, можно сделать split apk по архитектурам процессора. Но это приводит к следующей проблеме (пункт 2).
Проекты разрастаются, покрываются все большей логикой и разобраться порой в них становится все сложнее. Чтобы спустя нескольких лет развития проекта любой новый разработчик мог легко освоиться в проекте нужна четкая архитектура проекта. Однако некоторые библиотеки могут свести поддерживаемость проекта к нулю. Например, некорректная работа с EventBus может сильно запутать логику Вашего приложения. Тут важно четко разграничить: где и в каких кейсах Вы используете эту либу. А также быть уверенным, что никто и никогда не будет отклоняться от этих правил. Но что происходит на практике? Почти каждый разработчик, начиная работать с EventBus, использует его повсюду. В итоге проект становится абсолютно нечитаемым.
При добавлении новой библиотеки необходимо изучить как с ней взаимодействовать. Существуют библиотеки, которые могут очень негативно повлиять на скорость разработки в будущем.
Например, PagingLibrary от Google требует немалых усилий, чтобы понять как с ней взаимодействовать. Чтобы разобраться с этой библиотекой каждому новому разработчику потребуется от 12 до 20 часов. Вы теряете почти 3 дня! Как раз за эти 3 дня Вы можете запилить свою пагинацию и быть независимым от сторонних решений.
Скорость сборки современных приложений оставляет желать лучшего. Однако, если Вы хотите ещё больше увеличить время сборки — используйте Dagger! Не знаю почему библиотекой до сих пор активно пользуются после появления Kotlin. В большинстве случаев Dagger содержит все 4 проблемы, которые были описаны выше.
На своем опыте в одном лишь проекте я выпиливал 5 библиотек из-за наличия в них багов. Помните, что в библиотеках почти всегда есть баги. Например:
Значит ли это, что библиотеки не стоит использовать? Нет, библиотеки использовать можно и нужно, но важно как минимум убедиться, что в списке issue нет критических багов для Вашего проекта.
Знаете как проще всего взломать сразу несколько приложений, изучив лишь одни исходники? Нужно найти баг в крупной библиотеке, которая используется многими разработчиками. И через уязвимости этой либы получить доступ к данным вашего приложения. Если Вы не разрабатываете приложение, требующее повышенное внимание к безопасности пользователя, то можно на этот пункт закрыть глаза. В противном случае поищете issue, направленные на потенциальные уязвимости.
Если библиотека не обновлялась уже год — задайте вопрос, стоит ли её использовать. Дело в том, что в библиотеках регулярно находятся баги. Если эти баги не исправляются, то стоит ли использовать эту библиотеку? Вполне возможно, что в ближайшем будущем вы наткнетесь на баг библиотеки и вам придется искать альтернативные пути реализации фичи. Есть некоторые библиотеки, которые должны адаптироваться под возможности текущей версии Android API. Например, если появился новый элемент в Android, то нужно добавить его поддержку. К таким библиотекам можно отнести Anko, который больше не поддерживается. Теперь использовать эту библиотеку в крупных проектах нет смысла.
Такие библиотеки как RxJava или PagingLibrary заставляют разработчика использовать их API на каждом слое приложения. Если вы уверены, что библиотека всегда будет в проекте, то проблем нет. Но если вам по каким-то причинам придется выпиливать библиотеку, то вы затратите колоссальные усилия! Вам придется переписывать полпроекта.
Каждая либа предоставляет API, который ограничен как наличием открытыми методами, так и внутренней реализацией. Убедитесь, что возможностей библиотеки вам полностью хватает. Например, популярная библиотека Android Navigation Component очень сильно связывает руки разработчика. Она не предоставляет методы show, hide, add (которые есть в FragmentTransaction). Помимо этого библиотека усложняет работу с BottomNavigationView при необходимости хранить историю табов.
Когда я прихожу на новый проект, я первым делом смотрю зависимости в Gradle файл. Он даёт понять, что умеет делать приложение и как решаются те или иные задачи. Но вот было моё удивление, когда увидел, что для работы с сетью используются и OkHttp, и Retrofit, и Volley (форк). И это только работа с сетью. Сам Gradle файл состоит из огромного числа библиотек, поддержка которых уже давно закончилась. Когда разработчик один, он может держать весь проект в голове, но когда приходят новые разработчики разобраться в таком проекте становится крайне сложно.
Очень интересно услышать, на что ещё можно обратить при выборе библиотеки. Жду комментарии, отзывы и вопросы!
Потенциальные проблемы
Я всячески рекомендую избегать добавления внешних библиотек в свой проект. Однако это не значит, что использовать библиотеки — зло, а Ваш Gradle файл вовсе должен быть очищен от любых внешних зависимостей! Я хочу донести мысль, что перед добавлением новой библиотеки нужно провести очень серьёзный анализ. Чтобы понять, как анализировать библиотеки, давайте рассмотрим с какими потенциальными проблемами Вы можете столкнуться при добавлении новой библиотеки в Ваш проект.
Размер приложения
Большинство библиотек не сильно увеличивают размер Вашего приложения. Но существуют такие либы, после добавления которых Ваше приложение увеличится в разы! Например, библиотека Realm может увеличить размер APK с 4MB до 12MB. В среднем приложение весит 100MB-200MB и лишние 8MB могут быть не заметны. Но не забывайте, что Realm не единственная библиотека, которая негативно влияет на размер APK. А можно ли уменьшить размер APK, используя эту зависимость? Да, можно сделать split apk по архитектурам процессора. Но это приводит к следующей проблеме (пункт 2).
Поддерживаемость кода
Проекты разрастаются, покрываются все большей логикой и разобраться порой в них становится все сложнее. Чтобы спустя нескольких лет развития проекта любой новый разработчик мог легко освоиться в проекте нужна четкая архитектура проекта. Однако некоторые библиотеки могут свести поддерживаемость проекта к нулю. Например, некорректная работа с EventBus может сильно запутать логику Вашего приложения. Тут важно четко разграничить: где и в каких кейсах Вы используете эту либу. А также быть уверенным, что никто и никогда не будет отклоняться от этих правил. Но что происходит на практике? Почти каждый разработчик, начиная работать с EventBus, использует его повсюду. В итоге проект становится абсолютно нечитаемым.
Время на изучение библиотеки
При добавлении новой библиотеки необходимо изучить как с ней взаимодействовать. Существуют библиотеки, которые могут очень негативно повлиять на скорость разработки в будущем.
Например, PagingLibrary от Google требует немалых усилий, чтобы понять как с ней взаимодействовать. Чтобы разобраться с этой библиотекой каждому новому разработчику потребуется от 12 до 20 часов. Вы теряете почти 3 дня! Как раз за эти 3 дня Вы можете запилить свою пагинацию и быть независимым от сторонних решений.
Скорость сборки
Скорость сборки современных приложений оставляет желать лучшего. Однако, если Вы хотите ещё больше увеличить время сборки — используйте Dagger! Не знаю почему библиотекой до сих пор активно пользуются после появления Kotlin. В большинстве случаев Dagger содержит все 4 проблемы, которые были описаны выше.
Баги, баги, баги…
На своем опыте в одном лишь проекте я выпиливал 5 библиотек из-за наличия в них багов. Помните, что в библиотеках почти всегда есть баги. Например:
- AndroidPdfViewer оставляет утечки памяти, некорректно обрабатывает некоторые кейсы с null, из-за чего вылетает NullPointerException
- Android Navigation Component некорректно работает с анимациями Shared Element'ов в некоторых кейсах
- Cicerone иногда крашит приложение из-за
executePendingTransactions()
Значит ли это, что библиотеки не стоит использовать? Нет, библиотеки использовать можно и нужно, но важно как минимум убедиться, что в списке issue нет критических багов для Вашего проекта.
Наличие уязвимостей в библиотеке
Знаете как проще всего взломать сразу несколько приложений, изучив лишь одни исходники? Нужно найти баг в крупной библиотеке, которая используется многими разработчиками. И через уязвимости этой либы получить доступ к данным вашего приложения. Если Вы не разрабатываете приложение, требующее повышенное внимание к безопасности пользователя, то можно на этот пункт закрыть глаза. В противном случае поищете issue, направленные на потенциальные уязвимости.
Поддержка библиотеки
Если библиотека не обновлялась уже год — задайте вопрос, стоит ли её использовать. Дело в том, что в библиотеках регулярно находятся баги. Если эти баги не исправляются, то стоит ли использовать эту библиотеку? Вполне возможно, что в ближайшем будущем вы наткнетесь на баг библиотеки и вам придется искать альтернативные пути реализации фичи. Есть некоторые библиотеки, которые должны адаптироваться под возможности текущей версии Android API. Например, если появился новый элемент в Android, то нужно добавить его поддержку. К таким библиотекам можно отнести Anko, который больше не поддерживается. Теперь использовать эту библиотеку в крупных проектах нет смысла.
Библиотека присутствует во всех слоях проекта
Такие библиотеки как RxJava или PagingLibrary заставляют разработчика использовать их API на каждом слое приложения. Если вы уверены, что библиотека всегда будет в проекте, то проблем нет. Но если вам по каким-то причинам придется выпиливать библиотеку, то вы затратите колоссальные усилия! Вам придется переписывать полпроекта.
Ограничения библиотеки
Каждая либа предоставляет API, который ограничен как наличием открытыми методами, так и внутренней реализацией. Убедитесь, что возможностей библиотеки вам полностью хватает. Например, популярная библиотека Android Navigation Component очень сильно связывает руки разработчика. Она не предоставляет методы show, hide, add (которые есть в FragmentTransaction). Помимо этого библиотека усложняет работу с BottomNavigationView при необходимости хранить историю табов.
Огромный Gradle файл с зависимостями
Когда я прихожу на новый проект, я первым делом смотрю зависимости в Gradle файл. Он даёт понять, что умеет делать приложение и как решаются те или иные задачи. Но вот было моё удивление, когда увидел, что для работы с сетью используются и OkHttp, и Retrofit, и Volley (форк). И это только работа с сетью. Сам Gradle файл состоит из огромного числа библиотек, поддержка которых уже давно закончилась. Когда разработчик один, он может держать весь проект в голове, но когда приходят новые разработчики разобраться в таком проекте становится крайне сложно.
Чек-лист вопросов перед внедрением библиотеки
- Какие issue есть у данной библиотеки? Критичны ли они для моего проекта?
- На сколько эта библиотека/технология протестирована сообществом разработчиков? Сколько у нее звездочек на GitHub?
- Как часто разработчик отвечает на issue?
- Как часто разработчик обновляет библиотеку?
- Сколько времени потратят новые разработчики на изучение используемой технологии?
- Как библиотека повлияет на размеры приложения?
- Как библиотека повлияет скорость работы приложения?
- Как библиотека повлияет на скорость сборки? Помогает ли она сэкономить время разработки?
- Есть ли у библиотеки уязвимости?
- Будет ли библиотека присутствовать на каждом слое проекта? На сколько это критично?
- Каким образом библиотека ограничивает возможности разработчика (она почти всегда ограничивает). Хорошо это или плохо?
- Смогу ли я сам написать решение, которое будет заточено под мой проект за допустимые сроки?
Очень интересно услышать, на что ещё можно обратить при выборе библиотеки. Жду комментарии, отзывы и вопросы!
