5 советов по выбору правильного открытого исходного кода

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

Поиск правильного кода обычно означает обращение к богам Google или других поисковых систем, добавление запроса и скрещивание пальцев для быстрой победы. Простые функциональные запросы, такие как «Javascript has own property», вероятно, приведут к разным форумам и сообщениям в блогах, в то время как описания более высокого уровня («React component x») часто попадут в GitHub или NPM.

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

№1. Читается ли код?

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

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

№2. Активно ли поддерживается код?

Мы хотим, чтобы выбранный нами код был «живым». Это означает, что мы хотим знать, что ошибки, проблемы и обновления обрабатываются, и этот код будет активно поддерживаться разработчиками, которые его написали. Хорошим примером индикатора активности могут быть открытые проблемы GitHub, запросы на вытягивание и индикатор Pulse. Менеджеры пакетов предоставляют информацию, имеющую отношение к обслуживанию, такую ​​как количество зависимостей и зависимых проектов, но, тем не менее, им сложно представить достоверную метрику в этой области.

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

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

№3. Хорошо ли протестирован код?

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

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

При поиске пакета на самом деле нет надежного способа узнать, какой пакет тестируется и прошли ли тесты с пользой. Это большая проблема, когда дело доходит до обнаружения пакетов. Компоненты Reusable Bit могут быть протестированы, если такие тесты добавлены разработчиком. Bit Scope запускает тест, чтобы зеленые индикаторы и описание тестов могли отображаться в Интернете перед выбором компонента из концентратора сообщества Bit (или через интерфейс командной строки при распределенном использовании на локальном компьютере).

№4. Используется ли код другими?

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

На форумах по программированию мы можем использовать различные обозначения, такие как буква «V», обозначающая правильные ответы, количество набранных голосов и высказанных мнений пользователей. Это отличные и обнадеживающие функции, повышающие вероятность того, что код работает нормально. Когда дело доходит до GitHub, мы можем полагаться на звезды, соавторов и другие социальные показатели, чтобы получить чувство доверия. При поиске пакетов хорошим индикатором будет количество загрузок для этого пакета.

Компоненты Bit, найденные в центре сообщества Bit, представляют количество загрузок, участников (на уровне объема), простых «лайков» и т. Д. (Как показано в этой области компонентов React). В любом случае, имейте в виду, что социальные показатели - это хороший показатель, но бот - абсолютная правда относительно качества кода. Люди часто ошибаются, и общественное мнение может измениться быстрее, чем мы думаем.

№5. Хорошо ли задокументирован код?

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

Для репозиториев и пакетов GitHub все немного сложнее. Обычно файлы readme и docs, представленные на GitHub или NPM, дают общее представление о качестве документации. Документация для Bit-компонентов анализируется внутри самого кода, поэтому она показывает фактическое описание атомарного компонента, а также может включать примеры использования и указанную подпись, включая аргументы и возвращаемые значения для различных функций и поведения для компонентов React и других. В любом случае, по возможности, выбор документированного кода - хорошее решение.

Для репозиториев и пакетов GitHub все немного сложнее. Обычно файлы readme и docs, представленные на GitHub или NPM, дают общее представление о качестве документации. Документация для Bit-компонентов анализируется внутри самого кода, поэтому она показывает фактическое описание атомарного компонента, а также может включать примеры использования и указанную подпись, включая аргументы и возвращаемые значения для различных функций и поведения для компонентов React и других. В любом случае, по возможности, выбор документированного кода - хорошее решение.

Принятие решения

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

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