Как вы решаете, использовать ли библиотеку или написать собственную реализацию - PullRequest
17 голосов
/ 06 августа 2009

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

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

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

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

Итак, по каким критериям вы решаете, когда писать собственный код?

Ответы [ 7 ]

18 голосов
/ 06 августа 2009

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

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

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

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

Сложность

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

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

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

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

Скорость

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

  1. Профиль.
  2. Оптимизация.
  3. Внесите результаты в сообщество.

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

API

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

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

размер

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

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

Bugs

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

* 1084 зависимости *

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

Документация

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

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

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

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

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

Лицензия

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

6 голосов
/ 06 августа 2009

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

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

  1. Библиотека именно то, что мне нужно? Настраивается за несколько шагов? +++
  2. Обеспечивает ли он практически всю функциональность? Легко расширяемый? +++
  3. Нет времени? +++
  4. Это хорошо для одной половины и хорошо играет с другой? ++
  5. Трудно расширить, но отличная документация? ++
  6. Трудно расширить, но большую часть функциональности? +
  7. Функциональность в порядке, но устарела? -
  8. Функциональность в порядке ... но странно (сумасшедший интерфейс, не надежный, ...)? -
  9. Библиотека работает, но человек, который должен решить, находится в состоянии гибриса? ---
  10. Библиотека работает, управляемый размер кода, портфель нуждается в обновлении? ---

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

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

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

* / весело

4 голосов
/ 06 августа 2009

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

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

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

2 голосов
/ 14 июля 2017

Держите это в балансе

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

Время разработки VS время обслуживания

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

Простота против гибкости

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

Копать задание VS маленькое задание

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

Мои собственные библиотеки против внешних библиотек

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

1 голос
/ 06 августа 2009

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

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

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

1 голос
/ 06 августа 2009

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

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

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

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

0 голосов
/ 10 апреля 2019

Еще одним соображением является безопасность.

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

Другое соображение - безопасность языка. Язык C может быть очень быстрым. Но с точки зрения безопасности это вызывает проблемы. Если вы переопределите библиотеку на каком-либо языке сценариев, шансы на эксплойты выполнения произвольного кода невелики (если вы знаете возможные векторы атаки, такие как сериализация или ошибки).

...