Как вы решаете, следует ли использовать библиотеку или написать собственную реализацию

Вдохновленный этот вопрос, который начался невинно, но превращается в крупную пламенную войну.

Скажем, вам нужен утилитный метод - достаточно простой, но не однострочный. Цитированный вопрос заключался в том, как повторять строку X раз. Как вы решаете, использовать ли стороннюю реализацию или написать свой собственный?

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

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

Итак, какие критерии вы используете, чтобы решить, когда писать свой собственный код?

Ответ 1

Общее решение

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

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

Если после всех аспектов, описанных ниже, я не могу найти подходящую библиотеку или исходный код, и я искал (и спросил на подходящих форумах), тогда я разработаю свою собственную реализацию.

Сложность

Если задача относительно простая (например, класс MultiValueMap), то:

Найдите существующую реализацию с открытым исходным кодом.
Интегрируйте код.
Перепишите его или обрезайте, если он чрезмерен.

Если задача сложна (например, гибкая объектно-ориентированная библиотека графического отображения), то:

Найдите реализацию с открытым исходным кодом, которая компилирует (из коробки).
Выполните его "Привет, мир!". эквивалент.
Выполнять любые другие оценки по мере необходимости.
Определите его пригодность на основе критериев проблемной области.

Speed 

Если библиотека слишком медленная, то:

Профайл.
Оптимизируйте его.
Внести результаты обратно в сообщество.

Если код слишком сложный для оптимизации, а скорость является фактором, обсудите его с сообществом и предоставите данные профилирования. В противном случае, найдите эквивалентную, но более быструю (возможно, менее богатую функциями) библиотеку.

API

Если API не прост, то:

Напишите фасад и внесите свой вклад в сообщество.
Или найдите более простой API.

Размер

Если скомпилированная библиотека слишком велика, то:

Скомпилируйте только необходимые исходные файлы.
Или найдите меньшую библиотеку.

Ошибки

Если библиотека не компилируется из коробки, найдите альтернативы.

Зависимости

Если библиотека зависит от множества внешних библиотек, найдите альтернативы.

Documentation

Если документации недостаточно (например, руководств пользователя, руководств по установке, примеров, комментариев исходного кода), найдите альтернативы.

Ограничения времени

Если есть достаточно времени, чтобы найти оптимальное решение, сделайте это. Часто не хватает времени писать с нуля. И, как правило, существует множество подобных библиотек для оценки. Имейте в виду, что благодаря тщательной развязке вы всегда можете обменять одну библиотеку на другую. Найдите то, что работает, изначально, и если это позже станет обузой, замените его.

Среда разработки

Если библиотека привязана к определенной среде разработки, найдите альтернативы.

Лицензия

Открытый исходный код.

Ответ 2

10 вопросов...

+++ (использовать библиотеку)... --- (написать собственную библиотеку)

Является ли библиотека именно тем, что мне нужно? Настраивается в несколько шагов? +++
Предоставляет ли он почти все функции? Легко расширяемый? +++
Нет времени? +++
Это хорошо для половины и хорошо играет с другими? ++
Трудно расширить, но отличную документацию? ++
Трудно расширить, но большая часть функциональности? +
Функциональность нормально, но устарела? -
Функциональность ok,.. но странная (сумасшедший интерфейс, не прочный,...)? -
Библиотека работает, но человек, который должен решить, находится в состоянии гибрида? ---
Работа с библиотекой, управляемый размер кода, обновление портфолио? ---

Некоторые мысли...

Если это то, что мало, но полезно, вероятно, для других тоже, то зачем писать библиотеку и помещать ее в Интернет. Стоимость публикации таких небольших библиотек уменьшилась, а также препятствие для других настроиться (см. bitbucket или github). Итак, каковы критерии?

Возможно, он не должен точно копировать существующую уже известную библиотеку. Если он реплицирует что-то существующее, он должен подходить к проблеме с нового ракурса или, лучше, должен обеспечивать более короткое или более сжатое * решение.

* <суб > /веселосуб >

Ответ 3

Если это тривиальная функция, не стоит тянуть всю библиотеку.

Если это нетривиальная функция, то она может стоить того.

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

Ответ 4

Для меня это был бы довольно простой ответ.

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

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

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

Ответ 5

Если функциональность - это лишь небольшая часть приложения, или если ваши потребности такие же, как у всех остальных, то, вероятно, это путь к библиотеке. Если вам нужно потреблять и выводить JSON, например, вы, вероятно, можете сбить что-то вместе за пять минут, чтобы справиться с вашими непосредственными потребностями. Но потом вы начинаете добавлять к нему понемногу. В конце концов, у вас есть все функциональные возможности, которые вы найдете в любой библиотеке, но 1) вы должны были написать ее самостоятельно, а 2) это не надежный и нужный документ, как то, что вы найдете в библиотеке.

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

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

Ответ 6

Сохраняйте баланс

Вы должны сохранять несколько критериев в балансе. Я бы рассмотрел несколько тем и задал несколько вопросов.

Время выполнения времени обслуживания VS

Могу ли я разработать то, что мне нужно, через несколько часов? Если да, зачем мне нужна библиотека? Если я получу lib, я уверен, что это не вызовет часы, потраченные на отладку и чтение документации? Ответ: если мне нужно что-то очевидное и простое, мне не нужна дополнительная гибкая библиотека.

Простота VS гибкость

Если мне нужна только обертка ошибок, мне нужна библиотека с гибкими типами, трассировкой стека и цветными отпечатками и... Нет! Использование даже красиво разработанных, но гибких и многоцелевых библиотек может замедлить ваш код. Если вы планируете использовать 2% функциональности, вам это не понадобится.

Задача Dig задачи VS маленькая задача

Я столкнулся с огромной задачей, и мне нужен внешний код для ее решения? Определенно AMQP или SQL-операции - слишком большие задачи для разработки с нуля, но крошечные записи могут быть решены на месте. Не используйте внешние библиотеки для решения небольших задач.

Мои собственные VS VS внешние библиотеки

Иногда лучше выращивать свою собственную библиотеку, потому что она используется на 100%, для 100% соответствует вашим целям, вы знаете, что это лучше всего, она всегда соответствует вашим приложениям. Не создавайте собственную либу, чтобы быть крутой, и имейте в виду, что большое количество библиотек в вашем каталоге поставщиков разработано "просто чтобы быть круто".