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

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

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

О чем подумать

1. Каков срок жизни нашего проекта?

Учитывая долговечность зависимости, будет ли зависимость оставаться активной и поддерживаться на протяжении всего жизненного цикла проекта?

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

2. Сколько времени нам потребуется, чтобы реализовать функциональность самостоятельно?

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

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

3. Есть ли у нашего проекта хорошее тестовое покрытие?

При использовании сторонней зависимости наш проект должен иметь хорошее тестовое покрытие; в противном случае, если зависимость будет обновлена, мы будем уверены, что все будет продолжать работать только после сбоя в производстве.

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

4. Насколько широко распространена зависимость?

Никто не хочет использовать то, что скоро забудется и без обновлений.

5. Кто стоит за зависимостью, которую мы хотим использовать?

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

6. Каков цикл обновления между версиями?

Определите, активно ли поддерживается зависимость. Есть ли частые обновления и исправления ошибок?

7. Какую совместимость мы хотим предложить?

Убедитесь, что эти зависимости совместимы с разрабатываемым вами программным обеспечением и не создают проблем совместимости.

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

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

8. Как часто в проект вносятся критические изменения?

Использование зависимости, которая постоянно меняет свой API, — плохая идея, потому что это заставит нас обновлять весь код, который ее использует. Некоторые зависимости следуют этой философии, и если вы не обновите их, вы можете столкнуться с серьезными проблемами безопасности.
Обычно зависимость, за разработкой и использованием которой стоит множество людей, является гарантией. Может наступить время, когда проект разветвится, но старая зависимость, вероятно, продолжит поддерживаться, хотя бы для добавления мелких улучшений или исправления проблем с безопасностью. Хороший пример — Angular JS и Angular.

9. Что произойдет, если мы не обновим зависимость?

Вы можете подвергнуть свое приложение уязвимостям безопасности и проблемам совместимости, если не обновите зависимость.

Здесь лучше всего регулярно обновлять их, прежде чем изменений станет так много, что их станет трудно обновлять.

10. Кто будет выполнять обновление?

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

Здесь важно всегда иметь хотя бы одного «владельца» зависимости и той части кода, которая ее использует. Этот человек будет отвечать за его обновление.

11. Насколько сложным будет обновление?

Сложность обновления сторонней зависимости зависит от сложности самой зависимости и объема обновления. Это может быть просто, если зависимость относительно проста, а обновление минимально. Однако если зависимость сложная, а обновление требует значительных изменений, это может оказаться сложным и потенциально длительным процессом.

12. Каково влияние любого изменения зависимости?

В скольких проектах он используется?

Будем ли мы обновлять все проекты или будем поддерживать разные версии?
Требуется ли изменение кода или нет?

Кто собирается внести изменения? Те же люди, которые разрабатывали проект, или другие?

Есть ли руководство по выполнению обновления? Например, существующие для обновления между разными версиями Spring.

13. Какая лицензия имеет зависимость?

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

Убедитесь, что используемая вами библиотека не нарушает никаких директив в вашей стране.

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

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

15. Обеспечивает ли библиотека необходимую нам производительность?

Убедитесь, что сторонние зависимости не влияют отрицательно на производительность вашего продукта. Он может хорошо работать на вашем компьютере, но плохо масштабироваться.

16. Есть ли в библиотеке хорошая документация?

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

17. Каков размер зависимости?

Является ли зависимость легкой и не слишком раздутой?

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

Я надеюсь, что вы найдете полезными эти моменты, которые вы наверняка уже принимаете во внимание в своих проектах; если вы хотите внести что-то еще, не стесняйтесь делать это. Спасибо!