Сторонние фреймворки и библиотеки являются (и, вероятно, останутся) темой горячих споров. Некоторые разработчики тратят больше времени на исследование и оценку потенциального фреймворка, чем на разработку с его помощью, некоторые разработчики обращаются к новым библиотекам, как только сталкиваются с проблемой. В этой статье рассматриваются некоторые плюсы и минусы использования сторонних библиотек и фреймворков.
Фреймворк против библиотеки
Прежде всего, давайте начнем с нескольких слов о том, что представляет собой фреймворк или библиотека. Интернет полон различных определений, некоторые из них утверждают, что применение принципа инверсии управления является основным различием между ними, в то время как некоторые утверждают, что библиотека - это набор методов, специфичных для задачи, а фреймворк - это широкий, неточно определенный термин, который может быть равен библиотеке, быть собранием библиотек или чем-то гораздо более сложным. В этой статье мы должны согласиться только с тем, что и библиотека, и фреймворк представляют собой наборы методов, предназначенные для ускорения разработки и абстрагирования общих или сложных вычислений.
Плюсы
Давайте начнем с того, что посмотрим, какие преимущества может принести фреймворк / библиотека нашему проекту при правильном использовании.
Прототипирование
Если вы проводите быстрое подтверждение концепции и хотите показать, что ваша идея осуществима, а не создавать приложение производственного уровня, фреймворк может помочь вам быстрее приступить к работе. чем если бы вы написали весь код самостоятельно. Если вам удастся привлечь других и обеспечить финансирование для вывода идеи на рынок, вы можете решить, хотите ли вы сохранить зависимость или хотите разработать собственное индивидуальное решение.
Более быстрая разработка
Фреймворк может пригодиться, если приложение требует огромного объема работы, просто чтобы заложить невидимый фундамент для чего-то осязаемого. Допустим, вы разрабатываете приложение, которое отображает множество разных данных с помощью графиков. Разработчикам может потребоваться некоторое время, чтобы разработать код, отображающий различные графики, поэтому вы можете использовать стороннюю структуру, чтобы сократить время, необходимое для отображения чего-либо вообще.
Это может быть компетенция и / или также требуются финансовые ресурсы. При реализации службы, которая использует карты для отображения информации для пользователей, вероятно, имеет гораздо больше смысла использовать установленный SDK карт, чем нанимать целый отдел для создания ваших собственных карт.
Протестированный и доработанный код
Это верно только в идеальном мире, потому что правда заключается в том, что далеко не все доступные библиотеки и фреймворки своевременно обновляются / повторяются / поддерживаются. . Если у библиотеки есть постоянная база пользователей и она существует уже некоторое время, есть вероятность, что она пару раз улучшалась. Об ошибках будут сообщаться, и мы надеемся, что многие из них были исправлены в последних версиях. В конечном итоге это суждение, и к нему не следует относиться легкомысленно при выборе того, следует ли использовать фреймворк.
Минусы
Минусы использования любых фреймворков или библиотек можно в значительной степени описать одним словом: риск.
Все внешние зависимости возникают за счет риска, и это следует тщательно рассмотреть, прежде чем выбирать, следует ли пойти с фреймворком для приложения производственного уровня.
Отсутствие поддержки
Мы вкратце коснулись этого раздела о преимуществах, но с точки зрения использования проверенного и зрелого кода. На другом конце спектра мы находим фреймворки и библиотеки, от которых отказались их авторы, и поэтому они не получают надлежащих обновлений, когда языки развиваются и обнаруживаются слабые места. В конечном итоге вы можете создать свое приложение на основе фреймворка, который в конечном итоге помешает вам правильно поддерживать его, и это может стоить вам тонны часов, чтобы заменить его в более позднее время.
Основные изменения API
Поскольку вы не контролируете фреймворк, вы также не контролируете изменения, вносимые в API. Вы можете оказаться в ситуации, когда вам потребуется перейти на более новую языковую версию (особенно это актуально в мире Swift, где я живу большую часть времени). Авторы фреймворка могут подумать, что точка останова между двумя языковыми версиями - идеальное время для внесения более серьезных критических изменений в API, и вам в конечном итоге придется восстанавливать взаимодействие с фреймворком поверх миграции. Не смешно!
Размер приложения
Каждый раз, когда вы используете фреймворк, ваше приложение будет увеличивать размер этой зависимости, даже если вы можете использовать только часть функциональности. Это еще более важно для разработчиков, которые склонны обращаться к библиотекам и фреймворкам всякий раз, когда они немного ленивы или не хотят тратить немного времени на размышления о том, как решить проблему.
Итак, действительно ли вам нужна эта структура?
В конечном счете, это суждение (конечно), и оно варьируется в зависимости от ситуации.
Однако я лично чувствую, что многие разработчики слишком быстро тянутся к библиотекам, прежде чем они действительно задумаются о том, действительно ли они им нужны.
Для меня лучший способ принять решение - начать с лагеря «Мне не нужна эта зависимость» и попытаться убедить себя, что в конце концов оно того стоит. Это можно сделать, указав на экономию времени и / или затрат или на тот факт, что у меня может не быть компетенции для создания и / или поддержания функциональности.
Обратите внимание, что «может не обладать компетенцией» не следует рассматривать как простой выход, говоря: «Я не могу придумать, как это сделать прямо сейчас, я буду использовать эту структуру». Есть разница между навыками, которые я могу получить с помощью нескольких поисковых запросов в Google, и навыками, требующими глубокого знания темы, знаниями, на приобретение которых уходят месяцы или годы обучения. Не позволяйте лени принимать эти решения за вас.
На этот раз все! Не стесняйтесь комментировать, если у вас есть вопросы, и подписывайтесь, чтобы получать уведомления о будущих статьях.
Чтобы узнать больше о разработке программного обеспечения, ознакомьтесь с моими предыдущими статьями:
