Иногда, когда вы программируете, вы натыкаетесь на функцию, с которой лучше всего справиться, имея целый модуль, который делает это. Например, предположим, что вы хотите прочитать CSV или внедрить поддержку HTTP на стороне сервера.
Для таких вещей уже есть библиотеки, и вы были бы безумны, если бы не использовали их. На одном конце спектра сложности у нас есть такие задачи, как чтение CSV — библиотеки для этого просты, требуют для интеграции чуть больше нескольких строк кода и хорошо справляются с одной задачей. С другой стороны, реализовать HTTP на стороне сервера сложно. Очень трудно. И, к счастью, есть много замечательных библиотек, которые сделают это за вас, так что вам не придется этого делать.
Однако где-то посередине есть функциональность, которая немного сложнее, чем «хорошее выполнение одной задачи» (где использование другой библиотеки является само собой разумеющимся), и гораздо менее сложная, чем «что-то чрезмерно сложное» (где использование другой библиотеки необходимо).
Нужна как:
- Преобразование одного пользовательского формата данных в другой
- Обеспечить интерфейс RESTful CRUD для вашей системы
- Сопоставьте свои объекты в памяти с вашим хранилищем данных
- Обработка согласования веб-контента
Вы можете сразу сказать: «Эй, я знаю библиотеку, которая может это сделать», и я уверен, что вы знаете. Дело в том, что для каждого из этих примеров потребуется вспомогательная библиотека, которая была бы умеренно сложной, достаточно хорошо адаптированной к специфике этих проблем и способной поддерживать ваш контекст. Интеграция не будет состоять из одной или двух строк — это будет значительная часть работы, которая может включать выполнение вещей так, как библиотека говорит вам в вашем проекте.
Вы найдете множество проблем в программировании, подпадающих под эту категорию.
Столкнувшись с такой проблемой, программисту всегда приходится решать вопрос: должны ли они найти и принять уже существующую библиотеку (при условии, что у них еще нет под рукой знакомой библиотеки) или они должны написать свою собственную библиотеку. . Есть плюсы и минусы, конечно. Для принятия существующей библиотеки:
Плюсы:
- Увеличение шансов на отсутствие ошибок, хорошо используемое и принятое решение (при условии, что такая библиотека существует)
- Почти нулевые затраты на техническое обслуживание в долгосрочной перспективе
Минусы:
- Добавление внешней зависимости в ваш проект — это риск
- Изучение библиотеки сопряжено с первоначальными затратами, и нет никакой гарантии, что она действительно делает именно то, что вам нужно в вашем контексте. Возможно, вам придется изучить и отбросить несколько вариантов, прежде чем найти правильный.
Для написания собственной библиотеки:
Плюсы:
- Полный контроль, позволяющий адаптировать код к вашему варианту использования
- Возможность узнать о деталях решаемой проблемы
Минусы:
- Накладные расходы на долгосрочное обслуживание
- Предварительные усилия по разработке со всем необходимым тестированием и исправлением ошибок
Единого универсально приемлемого ответа не существует, и вместо этого я бы предположил, что ответ зависит от ряда факторов:
- Каковы сроки вашего проекта? Если у вас мало времени, возможно, будет быстрее запустить собственное решение специально и только для вашего варианта использования, чем изучать и оценивать несколько вариантов, выбирать один и интегрировать его.
- Насколько сложна ваша проблема и насколько сложны доступные библиотеки? Некоторые проблемы обычно сложны, но ваш пример может быть простым.
- Вам нужно детально разобраться в предметной области? Если это так, написание собственного решения — идеальный способ сделать это. Если у вас есть время, возможно, стоит сначала написать собственное решение, а затем отказаться от него в пользу принятой библиотеки, как только вы полностью ее поймете.
- Какой долгосрочный контроль над решением вам нужен? Если их нет, можно использовать существующее решение, если их много, то вам нужно либо написать свое собственное, либо создать форк существующего, либо принять участие в работе с существующей библиотекой. сообщество.
Какой бы путь вы ни выбрали, просто помните, что вы приняли решение в контексте вашего проекта, что всегда правильно. Вы встретите разработчиков, которые думают, что всегда правильно найти и внедрить внешнюю зависимость — они обычно упускают из виду риск и отсутствие контроля. Вы также встретите разработчиков, которые всегда внедряют готовые решения — обычно они не уделяют должного внимания долгосрочному сопровождению.
Решение проблем в программном обеспечении — это всегда вопрос баланса.
Ричард является основателем и старшим партнером Cottage Labs, консалтинговой компании по разработке программного обеспечения, специализирующейся на всех аспектах жизненного цикла данных. Иногда он появляется в Твиттере по адресу @richard_d_jones
