Польза использования библиотек

#android

Толком не освоив I/O в Java я использую библиотеку SimpleStorage. Также сетевые запросы
реализую с помощью Retrofit. Вместо SQL юзаю ОРМ, картинки гружу через Picasso, а не
руками. Скажите, что меня ждет в будущем? Стоит ли бросать библиотеки? Возможно ли
что скоро на собеседованиях не будут спрашивать основы, а вместо них будут проверять
на знание библиотек? Ведь это уже стало модно :)
    

Ответы

Ответ 1

Скажите, что меня ждет в будущем? Стоит ли бросать библиотеки?


Нет, библиотеки бросать не стоит, но (имхо) нужно как минимум примерно представлять,
как работают используемые Вами библиотеки (не прям всегда, но все же). Иначе, в противном
случае – шаг влево, шаг вправо и все...

В приличных крупных компаниях собеседования (на джуниора, а может и на мидла) с Вами
начнут не с вопросов по платформе, и даже не с вопросов по языку, а с вопросов по алгоритмам
(например, те же сортировки, их вычислительная сложность и все такое) и структурам данных.

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


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


Ну, проверять только лишь знание библиотек – это вряд ли.

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

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


Ответ 2

По опыту знаю, что многое зависит от библиотеки и от проекта. Я сам работал в компаниях,
где либо используют "модные" библиотеки, либо не используют почти никаких. И везде
есть свои плюсы и минусы.

Далее мое личное мнение:


Грань между "стоит залезть под капот" и "не стоит писать велосипед". Тут могу только
на примерах:


Лезть в Retrofit, не понимая, как создавать различные HTTP запросы (да и в принципе
без достаточно хорошего понимания того, как это работает), - не стоит. Лучше сначала
поработать с HttpUrlConnection, потом с OkHttp. Разберетесь в тонкостях, а также поразмышляете
над тем, как грамотно оборачивать запросы в асинхронку.
Picasso/Glide/etc. Если Вы понимаете, как происходит передача файлов по сети, то
мучиться над созданием грамотного image loader-a на мой взгляд не стоит (конечно, если
у Вас нет академического интереса). Инструменты написаны, работают грамотно.
ORM. Если Вы знакомы с SQL, почувствовали хотя бы чутка процесс создания хелперов
руками, то смело используйте ORM. Избавит Вас от написания примитивной кучи кода и
освободит время, которое бы Вы тратили на обдумывания, как архитектурно эту кучу кода
представить.
I/O освоить надо. Тут я думаю просто все согласятся. Просто. Надо.
RxJava. Вот тут холивар. Мне кажется, что если подключать Rx, то использовать реактивный
подход по максимуму в модели. Подключать такую не малую библиотеку ради маппинга в
нескольких экранах или просто ради асинхронных блоков - не гуд.

Грань между велосипедом и подтягиванием библиотекой с кучей кода, которая немного
упрощает разработку и утяжеляет проект. Выше я писал про Rx - к этому пункту тоже касается.
Я видел много проектов, где подключаются новомодные библиотеки, типа Dagger 2, RxJava,
Mosby/Moxy и т.д., а применяются всего в паре мест: даггером инжектят всего 2-3 зависимости
в 4-5 местах максимум, RxJava используют ради асинхронки, ну а Mosby/Moxy на 4-5 экранах...
Результат такой, что приложение из 5 экранов, отображающее простые списки с данными
и имеющее небольшой функционал, весит 20+ Мб. В продакшене размер apk имеет значение.


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

Самые интересные вопросы были из рода: как бы вы решили такую-то задачу средствами
Android SDK или Java -> с какими бы трудностями могли столкнуться -> какую бы библиотеку
применили в качестве альтернативы -> какие трудности могут появиться в таком решении.

Библиотеки могут быть сколь угодно модными, но на работу же принимают разработчика,
а не тупо кодера. А разработчик должен уметь думать и разбираться во внутренностях.