Как выбирать библиотеку

Каждый раз сталкиваясь с новой задачей мы задаем себе вопрос: Стоит ли ее решать? Возможно, удастся использовать готовое решение. В этом сила программирования, для большинства задач, таких как вывод суммы прописью или реализация протокола Z39.50 давно существуют готовые решения. Но, если решений несколько, как выбрать одно из них? Или может быть отказаться от всех них и реализовать задачу самому? Для многих такой выбор оказывается черезмерно сложным и они скатываются к одной из двух крайностей: предпочитают во всех случаях готовые средства или всегда изобретают велосипеды. Однако, разумные люди предпочитают объективно оценивать ресурсы. Я определил следующий набор критериев:

• Большинство библиотек плохо работают на грани своей области применимости. Например, все известные мне попытки применить Hibernate или ActiveRecords из Ruby on Rail к сложной унаследованной базе, вдобавок денормализованной достигали цели только посредством тяжких ухищрений. Убедитесь, что вы собираетесь использовать библиотеку именно так, как это запланировано разработчиками. В противном случае, выбросьте ее сразу. Все равно она для вас не подходит.
• Срок жизни кода в среднем составляет 5-10 лет до того момента как он морально устареет и будет выброшен. Это тот срок, когда кому-то нужно будет поддерживать код. Соответственно поддержка библиотеки должна быть расчитана на тот-же срок. Будет неприятно, если через пять лет в критичной библиотеке найдется критичный баг, который невозможно исправить, поскольку разработчики библиотеки давно испарились вместе с исходниками. Для коммерческих библиотек с закрытыми исходниками это может стать серьезной проблемой. Для Open Source такой гарантией может стать поддержка большого сообщества или серьезной конторы вроде IBM, Intel или Sun
• Критичный для функционала проекта должен писаться только собственноручно хотя бы на один уровень вглубь. Например, если мы занимаемся разработкой GIS системы, мы можем взять набор классов с представлением географических координат из десятков библиотек. Но координаты расползутся по всему приложению и заменить библиотеку когда она перестанет удовлетворять будет практически невозможно. Модели предметной области, бизнес правила, уникальные для вашей предметной области элементы интерфейса должны разрабатывать только вы сами. В противном случае у вас есть все шансы при очередном изменении требований столкнуться с ограниченностью библиотеки. К сожалению разработчики библиотек этого не понимают и норовят запихнуть свои «фреймворки», «модели предметной области» и «наборы бизнес правил» во все подходящие, на их взгляд, проекты
• Любая библиотека имеет склонность врастать в продукт и изменять его вокруг себя. Выбор, например, log4* навсегда определит вашу стратегию логгирования. Хорошая библиотека, изменит продукт в лучшую сторону, плохая только ухудшит. Стоит следить, чтобы архитектурные принципы используемых библиотек были сходны с вашими, code conventions не слишком отличались, а политика релизов была ясной и прозрачной. Плохое регрессионное тестирование библиотек или нарушение обратной совместимости приведет к шаманствам с зависимостями при сборке проекта и багам при обновлении библиотек. Важно понимать, что библиотека это не просто набор интерфейсов, а живой организм со своими особенностями.

Для того чтобы руководствоваться этими принципами на практике есть простой чеклист:

• Функционал реализуемый библиотекой критичен для проекта?
• Насколько сложно написать собственный код по сравнению с использованием библиотеки?
• Является ли библиотека open source либо предоставляют ли производители какие-то осязаемые гарантии?
• Насколько велико сообщество пользователей библиотеки?
• Как часто выходят релизы и фиксятся баги?
• Насколько хорош код библиотеки?
• Насколько хороша документация?