СКРИПТЫ ЧТО ЖЕ ЭТО ТАКОЕ

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

Общее понимание скрипта

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

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

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

История появления скриптов

Для общего развития предлагаю немного окунуться в историю появления скриптов и взглянуть на то, какими они были раньше. Начали применять их под управлением семейства операционных систем Unix еще 50 лет назад. Одной из первых командных оболочек была sh, в ней использовались shell scripts, которые позволяли выполнять самые разнообразные задачи на компьютере.

Ниже вы видите небольшой код, предназначенный для конвертирования изображения из JPG в PNG:

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

Сферы использования скриптов

Скрипты часто используются на веб-сайтах. Чаще всего они пишутся на языках PHP и JavaScript. Первый используется для написания той части сайта, которую не видит посетитель, то есть бэкенда, а второй в большинстве случаев отвечает за визуал, то есть разные анимации, плавные переходы и другие действия (фронтэнд).

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

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

Если говорить о Windows, то в ней вы можете найти встроенный инструмент CMD (PowerShell), который и предназначен для запуска скриптов, хранящихся в формате BAT.

Самостоятельное написание и применение скриптов

Разберем самостоятельное написание и применение скриптов на примере Windows. Допустим, у вас стоит задача проверить стабильность соединения с конкретным сайтом без запуска браузера. Для этого есть одна полезная команда, запускаемая через Командную строку. А если нужно еще сформировать и отчет о результатах проверки, не совсем удобно будет вводить несколько разных команд по очереди, особенно в тех случаях, когда задача выполняется раз в несколько дней или чаще. Тогда создается BAT-файл с таким содержимым:

Этот скрипт анализирует доступ к сайту yandex.ru и создает отчет на рабочем столе. Попробуйте создать простой текстовый файл, внести туда этот код, поменять адрес сайта и сохранить файл с расширением .bat. Запустите его и посмотрите, что получится в итоге.

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

В любой непонятной ситуации — пиши скрипты

Время на прочтение

Скрипты — один из самых распространенных способов сделать приложение более гибким, с возможностью поправить что-то прямо на ходу. Конечно же, у этого подхода есть и недостатки, нужно всегда помнить про баланс между гибкостью и управляемостью. Но в этой статье мы не будем рассуждать “в общем” по поводу плюсов и минусов использования скриптов, мы рассмотрим практические способы реализации этого подхода, а также представим библиотеку, которая предоставляет удобную инфраструктуру для добавления скриптов в приложения, написанные на Spring Framework.

Несколько вводных слов

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

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

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

Ничего личного, только скриптинг

С JSR-233 скриптинг в Java стал очень простым. Существует достаточное количество скриптовых движков, основанных на этом API (Nashorn, JRuby, Jython и ещё некоторые), так что добавить немного скриптовой магии в код — не проблема:

Очевидно, что, если такой код будет раскидан по всему приложению, то оно превратится непонятно во что. И, безусловно, если у вас в приложении больше одного вызова скрипта, то нужно делать отдельный класс для работы с ними. Иногда можно пойти ещё дальше и сделать специальные классы, которые будут оборачивать вызовы evaluateGroovy() в обычные типизированные Java методы. В этих методах будет довольно однотипный служебный код, как в примере:

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

Прокачиваем скрипты

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

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

Все это, конечно, улучшает производительность и удобство пользования, но все-таки низкоуровневый движок остается низкоуровневым, и все равно надо читать текст скрипта, передавать параметры и вызывать API для выполнения скрипта. Так что нужно все ещё делать какие-то обертки в каждом проекте, чтобы сделать разработку ещё эффективнее.

И было бы несправедливо не упомянуть GraalVM — экспериментальный движок, который умеет выполнять программы на разных языках (JVM и не-JVM) и позволяет вставлять в Java приложения модули на этих языках. Я надеюсь, что Nashorn рано или поздно уйдет в историю, и у нас будет возможность писать части кода на разных языках в одном исходнике. Но это пока только мечты.

Предложение, от которого сложно отказаться?

В Spring есть встроенная поддержка исполнения скриптов, построенная на базе API JDK. В пакете org.springframework.scripting.* можно найти много полезных классов — все, чтобы можно было удобно использовать низкоуровневый API для скриптинга в своем приложении.

Кроме этого, есть более высокоуровневая поддержка, она подробно описана в документации. Вкратце — нужно сделать класс на скриптовом языке (например, Groovy) и опубликовать его как бин через XML описание:

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

Выглядит неплохо, но нужно делать “настоящие” классы для того, чтобы их опубликовать, обычную функцию в скрипте не напишешь. Кроме того, скрипты можно хранить только в файловой системе, для использования БД придется лезть внутрь Spring. Да и XML конфигурацию многие считают устаревшей, особенно если в приложении уже все на аннотациях. Это, конечно, вкусовщина, но с ней зачастую приходится считаться.

Трудности и идеи

Итак, у каждого решения есть своя цена, и, если говорить о скриптах в Java приложениях, то при внедрении этой технологии можно столкнуться с некоторыми трудностями:

Похоже, что обертывание вызовов скриптов в Java методы поможет решить большинство вышеуказанных задач. Совсем хорошо, если такие классы можно будет публиковать в IoC контейнере и вызывать методы с нормальными, значащими именами в своих сервисах, вместо вызова eval(“disc_10_cl.groovy”) из какого-нибудь утилитного класса. Ещё один плюс — код становится самодокументируемым, разработчику не надо ломать голову, какой конкретно алгоритм скрывается за названием файла.

Вдобавок ко всему, если каждый скрипт будет связан только с одним методом, можно быстро найти все точки вызова в приложении при помощи меню “Find Usages” из IDE и понять место скрипта в каждом конкретном алгоритме бизнес-логики.

Упрощается тестирование — оно превращается в “обычное” тестирование классов, с использованием привычных фреймворков, mock’ами и прочим.

Все вышеописанное очень созвучно с идеей, упомянутой в начале статьи — “специальные” классы для методов, которые реализуются скриптами. А что, если сделать ещё один шаг и скрыть весь служебный однотипный код для вызовов скриптовых движков от разработчика, чтобы он про это даже не думал (ну, почти)?

Репозитории скриптов — концепт

Задумка довольно проста и должна быть знакома тем, кто хоть раз работал со Spring, особенно со Spring JPA. Что нужно — сделать Java интерфейс и при вызове его методов вызывать скрипт. В JPA, кстати, используется идентичный подход — вызов CrudRepository перехватывается, на основе имени метода и параметров создается запрос, который потом выполняется движком БД.

Что нужно, чтобы реализовать концепт?

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

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

Полезным дополнением будет возможность использовать методы с реализацией в интерфейсе (a.k.a. default) — этот код будет работать, пока бизнес-аналитик не выведает более полную версию алгоритма, а разработчик не сделает скрипт на основе
этой информации. Или пусть аналитик скрипт пишет, а разработчик потом просто скопирует его на сервер. Вариантов много 🙂

Итак, предположим, что для интернет-магазина нужно сделать сервис для вычисления скидок на основе профиля пользователя. Прямо сейчас непонятно, как это делать, но бизнес-аналитик клянется, что всем зарегистрированным пользователям полагается скидка 10%, остальное он выяснит в течение недели у заказчика. Сервис нужен прямо завтра — сезон все-таки. Как может выглядеть код для такого случая?

А потом подоспеет и сам алгоритм, написанный, например, на groovy, там скидки будут немного отличаться:

Цель всего этого — дать разработчику возможность написать только код интерфейса и код скрипта, а не возиться со всеми этими вызовами getEngine, eval и прочими. Библиотека для работы со скриптами должна делать всю магию — перехватывать вызов метода интерфейса, получать текст скрипта, подставлять значения параметров, получать нужный скриптовый движок, выполнять скрипт (или вызывать default метод, если текста скрипта нет) и возвращать значение. В идеале, помимо кода, который уже написан, в программе должно быть что-то вроде этого:

Вызов читаемый, понятный, и, чтобы его сделать, не надо обладать никакими особыми навыками.

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

Как это работает

Общее устройство библиотеки показано на диаграмме. Синим выделены компоненты, которые нужно разработать, белым — которые уже есть в библиотеке. Значком Spring помечены компоненты, которые доступны в контексте Spring.

Когда вызывается метод интерфейса (по факту — прокси-объекта), запускается обработчик вызова, который в контексте приложения ищет два бина: провайдера, который будет искать текст скрипта, и исполнителя, который, собственно, найденный текст будет выполнять. Потом обработчик возвращает результат вызвавшему методу.

По умолчанию, в библиотеке есть провайдеры для чтения .groovy и .js файлов с диска и соответствующие исполнители, которые представляют из себя обертки над стандартным JSR-233 API. Можно создавать собственные бины для разных источников скриптов и для разных движков, для этого нужно имплементировать соответствующие интерфейсы: ScriptProvider и SpringEvaluator. Первый интерфейс использует org.springframework.scripting. ScriptSource а второй — это org.springframework.scripting. ScriptEvaluator. A PI Spring использовалось для того, чтобы можно было использовать готовые классы, если они уже есть в приложении.
Поиск провайдера и исполнителя производится по имени для большей гибкости — можно заменить в своем приложении стандартные бины из библиотеки, назвав свои компоненты такими же именами.

Тестирование и версионирование

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

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

Мы в С++-программе делаем какие-либо функции, «регистрируем» их под каким-нибудь именем в скрипте и вызываем в скрипте. То есть если мы зарегистрировали функцию SetPos(x,y) для определения позиции игрока в С++-программе, то, встретив эту функцию в скрипте, «интерпретатор» из библиотеки скриптового языка вызывает эту функцию в С++-программе, естественно, с передачей всех методов.

Теория правильных скриптов

Чем различается скрипт и программа? Вовсе не используемым языком или наличием интерфейса.

Скрипт же, в строго обратном смысле: он предназначен для решения конкретной проблемы «здесь и сейчас». Никто не ожидает от скрипта, который отсылает статистику, способности делать это одновременно на solaris’е, freeBSD и windows embedded standard с cygwin’ом на борту.

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

Разница между скриптом и программой — административная.

Практически любая программа имеет в себе ТРИ важные составляющие:

1) Алгоритм. У любой программы есть во-первых некая идея (что, собственно, делает программа), во-вторых — обвязка. Чтение конфигов, вывод в сислог, оповещение по почте и ещё тысяча не связанных с основной задачей операций. Но программу используют не ради чтения конфигов и записи в лог, а ради того, что она ДЕЛАЕТ. Соответственно, обычно идея заключается в выполнении каких-то действий по какому-то алгоритму. Нетривиальная идея. В фактическом коде это может быть меньше, чем чтение xml-конфига, но при этом именно рабочий алгоритм — суть программы. Он может быть или «обрабатывающим данные» (вроде SQL’я), или математическим (вроде md5sum), или работающим с конкретными особенностями конкретной железки (формата файла) — но он всегда требует высокой квалификации в предметной области для адекватного понимания принципов работы. Понятно, что код OpenSSL может читать любой программист. Понятно, что алгоритм работы OpenSSL может понять только хороший математик.

Но мы пишем не о программах — о скриптах. Так вот, скрипт не должен реализовывать нетривиальные алгоритмы. Если вы у себя в скрипте пишите аналог base64 — это плохой скрипт. Если вы у себя в скрипте пишите отправку сообщений по smtp методом «открыли сокет, записали» — это омерзительный скрипт. Если вы у себя в скрипте ловите данные с ком-порта и пишите туда ответ (для управления УПСом) — это писец какой-то, а не скрипт.

Скрипт НЕ ДОЛЖЕН содержать в себе алгоритма в терминах «предметной области». У скрипта нет предметной области, скрипт — обвязка вокруг программ, которые уже работают с предметными областями. В некоторых случаях скриптовый язык может предоставлять весь инструментарий:

if md5.md5sum (open.($check).read() ) != url.openurl($control).read():
smtp.sendmail($from, $to, «data check failed», «md5sum of $check does not match control sum form $contol.»).

Это скрипт. Просто скрипт. Не смотря на то, что он реализует офигенный объём работы. А вот если у вас md5 — класс, объявленный в скрипте 5 строчками выше с имплементацией md5 (или url, или open, или smtp, etc) — это уже потуга на программу. Но программа — это много сложнее, чем алгоритм, её составляющий — и подобное не должно реализовываться в скриптах. Н ИКОГДА.

2) Любая программа должна обладать известным поведением. Математики предлагают описывать поведение программы в всеобъемлющих терминах; практика же говорит, что обычно кроме алгоритма программа ещё содержит баги и фичи, которые влияют на её поведение, к которым надо адаптироваться. Адаптироваться к ним куда проще, когда есть некоторая практика использования программы.

«KDC has been valid once but invalid now» — если это сообщение от скрипта — всё, хоронить. Прямо тут, на месте. У программы это вполне разумное сообщение по которому можно гуглить и выяснять, что именно не так. Это прямое следствие наличия в программе некой предметной логики, специфичной и требующей от пользователей не изучать её насквозь, а принять бехивиористически. То бишь как набор утверждений о поведении программы. « Данная версия программы не понимает файлы больше 2Гб в размере». Это не укладывается в алгоритм (а если уложится — будет занимать этак с том дискретной математики) — но это нужно знать в практическом смысле. « Данная программа плохо себя ведёт в условиях симметричной нагрузки на аплоад/даунлоад, лучше запустить две копии, каждая из которых будет работать в свою сторону симметрично» — понимание _ПОЧЕМУ_ потребует титанических усилий, проще принять это как данность. Чем сложнее алгоритм, тем больше жизни нужно потратить на его исследование, адаптацию и глубокое изучение. На всё жизни не хватит, значит, проще принять как данное и сконцентрироваться на важном.

3) Скрипт решает задачу _ЗДЕСЬ_И_СЕЙЧАС_. Программа решает задачу _ТАМ_И_ВСЕГДА_ (с поправкой на опыт эксплуатации из п.2). Когда вы пишите скрипт, вы делаете так, чтобы оно работало в вашей системе. Оно не годится для свободного использования в других системах (хотя может быть ЛЕГКО (см п.1) адаптировано). Программа должна быть адаптируема к куче вариантов применения, реализация этой адаптации в скрипте приводит к потере его простоты и превращению его, собственно, в программу. Кроме того (увы и ах), но знание КАК ПРАВИЛЬНО писать программу не эквивалентно написанию правильного алгоритма. Вы можете написать потрясающую библиотеку, но если вы не сможете запустить её на машине, у которой понедельник первый день недели (или второй — кому как повезёт), то грош цена вашей библиотеке. Необходимость думать об этом — это уже написание программ — скрипту такое допустимо (хотя и не желательно).

Ну и ещё важное отличие между скриптами и программами. Программы (в форме библиотек) могут «наслаиваться» друг на друга. Этой программе нужен libYYY, которая использует libZZZ и libAAA, при этом libAAA использует libZZZ и libc. Это нормально.

Скрипты же НЕ ДОЛЖНЫ ЗАВИСЕТЬ ДРУГ ОТ ДРУГА. Ситуация, когда скрипт зависит от сервисов другого скрипта, который зависит от третьего — ненормальная.

Заметим, речь идёт о зависимости. Вполне можно представить себе скрипт, который вызывает другие скрипты и выдаёт обобщённый результат по ним, но это уже грань. Чуть сложнее (например, «запустить скрипт А если скрипт Б не отработал») — уже за гранью фола. Нехорошо. А если скрипт А не отработал но не сообщил об этом? Или чуть-чуть отработал, но потом отвалился так, что скрипту Б не получится доделать (а мы, как авторы скрипта А, и подумать не могли о подобном)?

Что же вообще должен делать хороший скрипт? Сращивать несколько программ в конкретную систему. Можете считать программы за детали конструктора. А сам конструктор — за скрипт. Вам НЕ СЛЕДУЕТ нарезать винтовую нарезку на шпинделе — возьмите шпиндель с нарезкой. Вам не следует делать эллиптический валик из этой резинки — оно всё равно будет плохо работать. Если у вас в конструкторе нет квадратной пластинки с дырками по краям, то это проблема нехватки деталек. Вы можете попытаться сделать квадратную пластину из пары прямоугольных, но не следует делать её и сотни длинных полосок.

Бывает так, что скрипты перерождаются в программы. Внезапно в скрипте появляется некая логика (алгоритм), которая становится нетривиальна (и полезна). В этот момент нужно поймать это — и не полениться потратить в три раза больше времени, но сделать её программой. Обеспечить её «мясом», которое отличает программу от скрипта. Добавить сотню проверок условий, заменить все константы на конфигурируемые переменные, приготовить её для работы в «непривычных» условиях. Желательно сделать её публичной (тогда может наработаться практика использования).

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

Грань, в которой заканчивается скрипт найти сложно. Скажем так, цикл — ещё терпимо. Проверка условия — нормально. Но вот проверка условия в цикле (больше, чем выход из цикла) — это уже плохо. Если же у вас цикл, в котором по проверке условия запускается цикл — это 100% программа. Если у неё нет всего того, что должно быть у программы, значит это просто очень плохая программа. Но никак не скрипт.

Применение подобных скриптов — признак крайней куцести рабочей среды. Я одно время пробовал с ними ужиться, но пришёл к выводу, что это ошибка. Куда правильнее иметь набор тулкитов (т.е. полноценных программ, реализующих конкретные вещи полностью и хорошо), чем набор аналогичных скриптов (повторю ещё раз — программа может быть написана на том же скриптовом языке — разница между скриптом и программой в непрограммерской обвязке: документации и приспособленности к жизни в широком спектре систем).

Применение копипастнутых скриптов — подобие ранне-досового копирования на дискетках полезных программулин. Работает — радуемся, не работает — пофигу, сломало всё — злимся. В условиях выбора между копипастнутым скриптом и программой (и минимальной обвязкой) следует выбирать программы. Даже если внедрение программы потребует дополнительных усилий по изучению, налаживанию и т.д. Наладив программу, вы получите программу. Отладив скрипт вы получите лишь костыль, прочность и долговечностью которого не знает даже автор.

Каждый раз, когда возникает подобная ситуация: делать скрипт или искать программу, следует начать с поиска программы. Потому что программирование увлекает (да нафига нам nagios, мы и сами напишем пачку скриптов мониторинга), а изучение чужого — утомляет (ну хрена она работает не так как я ожидаю?). Но последствия «недопрограммирования» — отсутствие документации к тому «дымоходу», который вы сделали. А последствие внедрённого решения — система, которая умеет работать сама по себе.

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

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

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

Где применяются скрипты

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

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

Кто работает со скриптами

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

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

Что такое скриптовые языки программирования

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

Примеры скриптовых языков

Самый популярный скриптовый язык сегодня — JavaScript. Его понимают все современные браузеры, поэтому JavaScript активно используют в вебе, при разработке интернет-сайтов. На втором месте по популярности — Python. Его применяют более широко, в том числе в машинном обучении и анализе данных. Еще есть PHP — на нем пишут скрипты для «серверной» стороны сайта.

Существуют специализированные внутренние скриптовые языки, которые работают в какой-то большой системе. Например, свой язык есть у AutoCAD: на нем можно отдавать команды программе. Или у MATLAB: на нем пишутся скрипты для решения сложных математических задач. А в Microsoft Office встроен Visual Basic: на нем можно писать скрипты для работы с документами, таблицами и презентациями. Такие сценарии называются макросами.

Никуда не делись и изначальные скрипты — те, которые выполняются внутри операционных систем. Тут тоже есть свои языки. Для Unix и Linux это Bash и Shell, а для Windows — PowerShell. Эти языки работают внутри ОС, писать на них команды можно в консоли, а можно создавать отдельные файлы со скриптами и запускать их.

Какие задачи выполняют скрипты

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

Действия пользователя на сайте. Во фронтенде — отрасли разработки, которая занимается «передней», видимой пользователю частью сайта, — без скриптов никуда. Почти все интерактивные, динамические действия на сайте, которые вам доступны, выполняются за счет скриптов. Вы выполняете какое-то действие — скрипт запускается.

Сайт может работать и без скриптов: такие действия, как отправка формы или переход по ссылке, возможны без их использования. Но всплывающие окна, автокоррекция формата даты, подсказки в поиске и многое другое — это всё скрипты.

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

Динамические элементы дизайна. Скрипты можно использовать для украшения. Так, с их помощью работают интерактивные элементы дизайна. Например, когда пользователь вводит во всплывающем окне некорректные данные, оно «трясется» — проигрывает анимацию. Она запускается по скрипту. Или на сайте есть элемент, который анимируется, если на него нажать, — это тоже скрипт. Еще более распространенный пример — динамическое меню: оно появляется, если пользователь кликнет на иконку или наведет на нее курсор.

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

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

Скрипты и плагины

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

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

Готовые и самописные скрипты

Но пользоваться библиотеками не всегда оправданно. Они весят больше, чем один скрипт, созданный вручную, могут «тянуть» за собой разные зависимости, а написанный там код не всегда удобно адаптировать под конкретную задачу. Поэтому скрипты обычно пишут самостоятельно, если задача не совсем шаблонная. А библиотеки используются как вспомогательные инструменты.

Преимущества скриптов

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

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

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

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

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

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

Александр

Здравствуйте, меня зовут Александр, уже более 10 лет я занимаюсь ремонтом компьютером, этот сайт я создал чтобы делиться полезной и практической информацией с вами! Буду благодарен, если вы опишите свой опыт или мнение в комментарии, надеюсь, что данная информация принесёт только пользу

Оцените автора
WindowsComp.ru
Добавить комментарий