Опасность зависимости от сторонних кодов

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

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

Каждый раз, когда вы видите небольшую ссылку внизу веб-страницы с надписью «Powered by So-And-So», вы являетесь свидетелем этого эффекта сотрудничества в действии.

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

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

1. Потенциальные риски безопасности

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

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

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

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

2. Вы не являетесь его владельцем

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

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

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

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

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

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

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

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

4. Несколько уровней зависимости от третьей стороны могут привести к реальным проблемам

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

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

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

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

Основная причина заключалась в том, что большинство людей, использовавших Left-Pad, понятия не имели, что они его используют, что он делает и как решить проблему. Как указано в пункте 2, если вы им не владеете, вы не обязательно его понимаете.

Left-Pad — очень простая функция, которая просто добавляет несколько пробелов к левой стороне строки, чтобы убедиться, что строка имеет правильную длину. Проблема в том, что любой компетентный программист может легко воспроизвести эту функциональность.

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

Суть в том, что если вы можете построить это самостоятельно, то, вероятно, должны!

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

Чтобы упростить процесс принятия решения, вероятно, помогут следующие условия тестирования.

Если любой из этих факторов верен:

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

Затем вы должны построить его самостоятельно,

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

Богдан Рэнца

Богдан является одним из основателей Inspired Mag, накопив за этот период почти 6-летний опыт. В свободное время он любит изучать классическую музыку и изучать изобразительное искусство. Он тоже одержим исправлениями. У него уже есть 5.

Комментарии Ответы 0

Оставьте комментарий

Ваш электронный адрес не будет опубликован. Обязательные поля помечены * *

Рейтинг *

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