Язык программирования для автоматизации

Язык программирования для автоматизации

Главная задача ПЛК – это выполнение прикладной программы управления технологическим процессом. Очевидно, что незапрограммированный контроллер – это всего лишь пустая железяка, не приносящая никакой пользы человечеству.

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

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

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

1. Разнообразные программные библиотеки, функциональные блоки, готовые процедуры и шаблоны. Использование предподготовленных компонентов сильно ускоряет процесс разработки программного обеспечения для ПЛК.

2. Инструменты для отладки, тестирования и симуляции прикладной программы. Последние позволяют выполнять программу ПЛК на персональном компьютере без загрузки в реальный контроллер.

3. Инструменты для автоматизированного документирования разработанной программы в соответствие с принятыми стандартами.

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

Существует международный стандарт IEC 61131, разработанный Международной Электротехнической Комиссией (МЭК, IEC) и состоящий из восьми частей. Наиболее интересной является третья часть, IEC 61131-3, описывающая языки программирования ПЛК. Первоначальной целью стандарта IEC 61131-3 была унификация языков программирования ПЛК и предоставление разработчикам ряда аппаратно-независимых языков, что, по замыслу создателей стандарта, обеспечило бы простую переносимость программ между различными аппаратными платформами и снимало бы необходимость изучения новых языков и средств программирования при переходе разработчика на новый ПЛК.

К сожалению, цели в полном объеме достигнуты не были. Каждый производитель ПЛК сопровождает свой продукт собственной средой программирования, которая, как правило, не совместима с другими, да и о кросс-платформенности программного кода можно забыть. Тем не менее, в части описания языков программирования стандарт IEC 61131 остается чрезвычайно актуальным и является ориентиром для большинства разработчиков ПЛК.

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

Язык LD

Язык LD (LAD, Ladder) является графическим языком разработки, программа на котором представляет собой аналог релейной схемы. Пример программы на данном языке приведен на рис. 1. По идеи авторов стандарта, такая форма представления программы облегчит переход инженеров из области релейной автоматики на ПЛК.

К недостаткам данного языка можно отнести то, что по мере увеличения количества «реле» в схеме она становится сложнее для интерпретации, анализа и откладки. Еще один недостаток языка LD заключается в следующем: язык, построенный по аналогии с релейными схемами, может быть эффективно использован только для описания процессов, имеющих дискретный (двоичный) характер; для обработки «непрерывных» процессов (с множеством аналоговых переменных) такой подход теряет смысл.

Рис. 1. Язык релейных диаграмм LD.

Язык FBD

Язык FBD (Functional Block Diagram, Диаграмма Функциональных Блоков) является языком графического программирования, так же, как и LD, использующий аналогию с электрической (электронной) схемой. Программа на языке FBD представляет собой совокупность функциональных блоков (functional flocks, FBs), входа и выхода которых соединены линиями связи (connections). Эти связи, соединяющие выхода одних блоков с входами других, являются по сути дела переменными программы и служат для пересылки данных между блоками. Каждый блок представляет собой математическую операцию (сложение, умножение, триггер, логическое “или” и т.д.) и может иметь, в общем случае, произвольное количество входов и выходов. Начальные значения переменных задаются с помощью специальных блоков – входов или констант, выходные цепи могут быть связаны либо с физическими выходами контроллера, либо с глобальными переменными программы. Пример фрагмента программы на языке FBD приведен на рис. 2.

Практика показывает, что FBD является наиболее распространенным языком стандарта IEC. Графическая форма представления алгоритма, простота в использовании, повторное использование функциональных диаграмм и библиотеки функциональных блоков делают язык FBD незаменимым при разработке программного обеспечения ПЛК. Вместе с тем, нельзя не заметить и некоторые недостатки FBD. Хотя FBD обеспечивает легкое представление функций обработки как «непрерывных» сигналов, в частности, функций регулирования, так и логических функций, в нем неудобным и неочевидным образом реализуются те участки программы, которые было бы удобно представить в виде конечного автомата.

Рис.2. Функциональная схема FBD.

Язык SFC

Язык последовательных функциональных схем SFC (Sequential Function Chart), использующийся совместно с другими языками (обычно с ST и IL), является графическим языком, в котором программа описывается в виде схематической последовательности шагов, объединенных переходами. Язык SFC построен по принципу, близкому к концепции конечного автомата, что делает его одним из самых мощных языков программирования стандарта IEC 61131-3. Пример программы на языке SFC приведен на рис. 3.

Наиболее простым и естественным образом на языке SFC описываются технологические процессы, состоящие из последовательно выполняемых шагов, с возможностью описания нескольких параллельно выполняющихся процессов, для чего в языке имеются специальные символы разветвления и слияния потоков (дивергенции и конвергенции, в терминах стандарта IEC 61131-3).

Шаги последовательности располагаются вертикально сверху вниз. На каждом шаге выполняется определенный перечень действий (операций). При этом для описания самой операции используются другие языки программирования, такие как IL или ST.

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

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

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

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

Рис. 3. Язык последовательных функциональных схем SFC.

Язык ST

Язык ST (Structured Text, Структурированный Текст) представляет собой язык высокого уровня, имеющий черты языков Pascal и Basic. Данный язык имеет те же недостатки, что и IL, однако они выражены в меньшей степени. Пример программы на языке ST приведен на рис. 4.

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

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

Рис. 4. Язык структурированного текста ST.

Язык IL

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

Читайте также:  Как изменить голос через программу

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

Язык IL имеет все недостатки, которые присущи другим низкоуровневым языкам программирования: сложность и высокую трудоемкость программирования, трудность модификации написанных на нем программ, малую степень «видимого» соответствия исходного текста программы и решаемой задачи.

Пример программы на языке IL приведен на рис. 5.

Рис. 5. Язык инструкций IL.

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

Язык CFC

Язык CFC (Continuous Flow Chart) – еще один высокоуровневый язык визуального программирования. По сути, CFC – это дальнейшее развития языка FBD. Этот язык был специально создан для проектирования систем управления непрерывными технологическими процессами.

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

Рис. 6. Среда проектирования на языке CFC системы Simatic PCS7.

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

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

Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и HR-ов, которые ввиду отсутствия каких-либо общепринятых критериев, как правило, понятия не имеют кто есть QA Automation Engineer и в большинстве случаев принимают решение на основании «хороший человек».

Бывает ещё хуже – руководитель/PM/etc… приходят к своим мануальным тестировщикам и говорят: «слушай, а может мы автоматизируем наше тестирование – это сэкономит нам кучу времени и денег. Скажи, какие книги тебе нужны и какие курсы».

0. Начнём с ошибок, которые не надо допускать:

  • Дайте мне книгу умную, которая всё за меня сделает
  • Дайте мне курсы платные, которые всему меня научат
  • Дайте мне форумы специализированные, которые ответят мне на все интересующие вопросы
  • Дайте мне сертификацию полезную, с которой меня везде примут

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

1. В первую очередь надо выбрать язык программирования
Не тулзу, не TestComplete, не тыкалки по экрану макросоподобные. А объектно-ориентированный язык программирования. Я в своё время поработал немного с C#, затем выбрал Java – и до сих пор не пожалел о сделанном выборе. Но настаивать не стану. Скажу только, что ещё не сталкивался ни с одной нерешаемой на Java проблемой – даже Delphi приложение через WinAPI тестируется (но лучше для таких задач использовать дэльфийские DUnit и прочее).

Итак, мы узнаём, что такое примитивы, классы, объекты, полиморфизм, инкапсуляция, интерфейсы, абстрактные классы, статические поля, циклы, массивы, листы, мапы, потоки и так далее… Это изучение будет продолжаться в целом всё время, даже когда вы уже автоматизируете тестирование. Но на базовом уровне – Junior Java Developer – вы должны (если выбрали Java) быть знакомы с языком и иметь соответствующие навыки, потому как первичная локализация возникшей проблемы лежит на ваших плечах. Забудьте про «а вот у меня сценарий, ошибка наигрывается непонятно как и непонятно почему» — ваша задача, чтобы разработчик знал, что тут вот рядом человек может найти баги даже не запуская приложение. Не поверите, как вдруг качество продукта возрастает, когда есть человек, который не просто слышит запах плохо пахнущего кода, но и может предложить решения по улучшению.

Мы плавно перешли к

2. Использование шаблонов проектирования для разработки тестового фреймворка.
ДА-ДА. Вы открыли, например, Selenium, — всякие примеры, скопировали бездумно, написали на получившемся «фрэймворке» 1000 тестов. Приходит заказчик к бизнесу, говорит «мне тут нужно кое-что переделать», бизнес приходит к разработчику — «нам тут нужно немного подстроиться под рынок», разработчик всё прекрасным образом запиливает, — 90% тестов падают. Приходят к автоматизатору «мы тут немного поменяли, надо привести тесты в порядок», а автоматизатор в ответ «тут работы на месяц»… Упс…
Архитектура фрэймворка, который вы пишите, должна не просто быть гибкой, а должна постоянно стремиться минимизировать время рефакторинга имеющихся тестов и написания новых. В идеале, если разработчик и автоматизатор одновременно садятся исправлять что-либо, то автоматизатор должен сделать всё быстрее и предоставить разработчику некую форму TDD.

В создании такой чудо-архитектуры нам помогают паттерны проектирования и их грамотное использование… Builder, Facade, Factory, Null Object, Singleton, Adapter и многие другие паттерны активно помогают в решении подобных задач. Грамотная архитектура тестового фреймворка – это счастье для вас, для разработчиков, для бизнеса…и в конечном счёте для пользователя. Помните, что экспоненциальный рост ресурсов поддержки тестов при линейном росте/изменении функционала свидетельствует о том, что вам пора дорабатывать архитектуру движка. С наиболее полным списком паттернов с примерами на Java можете ознакомиться здесь. Отдельно отмечу Page Object Pattern, но лучше, сначала познакомиться с классическими.

3. Использование библиотек
То, что плавно вливается в любые задачи, — внешние API, библиотеки, драйверы и прочие прелести. Selenium — тестируем Web, Robotium/Espresso — тестируем Android, Fest/Jemmy — тестируем Java Swing, JemmyFX — тестируем JavaFX, замечательные Apache HttpComponents — делаем запросы и тестируем множество API, GSON — помогает приводить json к объектной модели и обратно и так до бесконечности… Библиотек прекрасных много написано почти под любую задачу — про некоторые из них можно почитать здесь. Не стоит бояться того, что их много — вы уже достаточно знаете, чтобы выбрать то, что вам подходит/нравится/вписывается в архитектуру. Например, под тестирование Java Swing приложений я использую JUnit, Fest, Mockito и широкие возможности java.lang.reflect — этого набора мне более чем хватает.

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

4. Планирование тестов/написание тестов
В рамках этой статьи я не рассказываю про то, что губительна для любого проекта идея о 100% покрытии, о расписывании сценариев и т.д. Вообще классические подходы к тестированию губительны в автоматизированном тестировании — , например, изолированные входные данные для тестов. В общем тут уже играют роль ваши навыки, умение аналитически мыслить, умение сомневаться в том, в чём стоит сомневаться и не искать проблему там, где её не может быть. Хорошие сценарии тестов — это как хороший интерфейс… идеальными быть не могут. Мой опыт даёт такую статистику: 5% всех сценариев обеспечивает 95% покрытие функционала. На текущем проекте у нас 180 полноценных функциональных тестов за почти 2 года работы, которые обеспечивают нам эти 95% — 99%, шесть успешных внедрений — на выходе немного low замечаний, которые совершенно не отразились на основном функционале и на лояльности клиентов, и были быстро поправлены. Но ради них городить ещё 2000 тестов невыгодно чисто по деньгам — это я обращаюсь в сторону руководителей и бизнеса, которые мечтают о 100% покрытии. Поверьте мне, оно вам не нужно. Тут оговорюсь, если речь идёт не об автоматическом тестировании безопасности или биллинга — тут риски должны быть не минимизированы, а, по возможности, сведены к нулю. Но это отдельная история…

Читайте также:  Nuvoton communication port что это

5***. Написание утилит и собственных библиотек
Тут звёздочки… У вас уже всё замечательно на проекте, регресс покрыт, тесты гоняются, разработчики спокойны и могут спокойно рефакторить архитектуру, не боясь сломать имеющийся функционал. Но, например, для того, чтобы что-то сэмулировать руками, разработчику приходится проделывать из месяца в месяц одно и то же действие руками. Напишите для него утилиту, оптимизирующую эти процессы, включите туда всякие невалидные сценарии, разрекламируйте на уровне компании, — пусть все начнут пользоваться… Это ускорит работу и, как ни странно, уменьшит количество багов, так как у разработчика появится больше времени на то, чтобы проверить побольше сценариев, прежде чем коммитить измненения в ветку. Оглядитесь по сторонам и вы увидите так много процессов, которые можно автоматизировать, что не будете знать, за что взяться.
Пишите достаточно абстрактные библиотеки, могущие быть использованными на разных проектах в вашей компании, да и просто в вашей работе в будущем.

Вы, конечно, можете про себя подумать «жеееесть», но…

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

P.S.
К бизнесу, руководителям, специалистам по подбору персонала:

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

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

Но если копнуть глубже, возникнут вопросы. О каких именно программистах речь? О тех, кто проектирует ПО? О тех, кто разрабатывает алгоритмы? О ведущих разработчиках или простых «кодерах»? В любом случае, одного мнения здесь быть не может.

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

Точка отсчета

В самом начале у компьютеров не было даже клавиатуры! То есть всё было очень плохо — у них не было ни клавиатуры, ни экрана, были перфокарты (это такие штучечки с дырочками или с отсутствием дырочек).

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

Например, ассемблер (Assembler), который уже несколько облегчал жизнь. Ну, как он облегчал жизнь? Вместо запоминания того, что там какой-то «волшебный» код у команды, использовались всякие слова, похожие на «человеческий» английский язык — какие-нибудь add или mov — ну и затем перечислялись регистры или области памяти, переменные, с которыми нужно эти операции производить. Но понятное дело, что это в общем-то тоже требовало достаточно большого напряжения ума, чтобы держать у себя в голове, в каком регистре у нас что лежит, где какие переменные и что вообще происходит. Почему так происходило? Потому что компьютеры были «глупые» и ничего более «умного» понять не могли.


Изображение с сайта devdelphi.ru

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

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

Уровень выше — порог ниже

С появлением языков программирования высокого уровня жизнь программистов становилась легче, а производительность – выше. Программы не нужно было переписывать для каждой машины. Появились компиляторы, среды разработки. Fortran, Algol, а позже BASIC, PASCAL, C действительно были больше похожи на «человеческий» язык.

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

С появлением объектно-ориентированного программирования (С++, Object Pascal и так далее) тенденция повторного использования кода усилилась. Кроме того, со временем среды разработки становились более дружественными, и желающих освоить азы программирования становилось больше.

Программирование — в массы

Постепенно программирование перестало быть прерогативой хардкорных инженеров и математиков. Число проектов стремительно росло, программное обеспечение проникало в разнообразные сферы производства. Этому также способствовало и развитие систем управления базами данных. Появились даже такие специализации как «оператор СУБД».

Постепенно понятие «инженер-программист» стало многогранным: кто-то занимался алгоритмами, кто-то проектировал интерфейсы, кто-то просто занимался кодированием – то есть реализовывал в коде готовые алгоритмы своих коллег. Само программирование стали делить на две крупные группы – системное и прикладное: кто-то разрабатывал операционные системы и драйверы, а кто-то писал приложения для автоматизации бизнес-процессов на овощной базе.

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

Появление языков (Java, C#) и соответствующих фреймворков еще больше способствовало этому снижению, а также дифференциации специалистов по направлениям и уровням подготовки.

В результате у программистов закрепилась градация наподобие [Junior-разработчик, Senior/Middle, Team Lead, Software Architect]. С одной стороны, продвинутый инструментарий разработки позволял менее квалифицированным программистам успешно справляться с относительно простыми задачами, не имея глубоких знаний и серьезных навыков. С другой стороны, с каждой последующей ступенью карьерной лестницы порог вхождения также становился выше.


Изображение с сайта

Но если специалист задерживался в статусе начинающего, он мог заметить одну особенность: бурно развивающиеся технологии разработки ПО еще сильнее снижали порог вхождения, и среднестатистический Junior урожая N-го года знал и умел еще меньше, чем его старший товарищ — Junior (N — k)-го года.

Веб-разработка методом «тяп-ляп»

С развитием веб-разработки программистам потребовалось встать на другие рельсы (ассоциация с Ruby On Rails здесь тоже уместна), чтобы освоить новые языки и стек интернет-технологий разработки в целом.

После того как веб-разработка, начавшая набирать обороты только в 90-х годах, совершила огромный скачок в развитии, Михаил Густокашин может свободно пускаться в подобные рассуждения:

Допустим, вы хотите написать новый Facebook (социальную сеть). На чем вы будете это писать? HTML, CSS — это дизайн, а мы хотим, чтобы там можно было фотографии добавлять, друзей, комментарии оставлять.

Для скриптовой части — то есть то, что будет происходит на стороне клиента, — это JavaScript.

На удивление, он написан на PHP — и Facebook, и многие другие большие проекты. Пришлось, конечно, написать свои какие-то вещи, чтобы это всё-таки работало нормально, а не так как «тяп-ляп» было сделано, но они справились.

Читайте также:  Сумаил дота 2 биография

Здесь и сейчас, понятное дело, с нуля уже для веба никто ничего не пишет. Все ищут какой-нибудь фреймворк или ещё чего-то. Интернет-магазин? Скачали фреймворк для интернет-магазина — ну и всё, написали интернет-магазин.

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

На волне автоматизации

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

Все потому, что в чьи-то светлые головы пришла идея автоматизировать процесс веб-разработки. Хотя, на самом деле, идея не нова, так как она уже частично была реализована во многих инструментах разработки ПО под Desktop-платформы в виде автогенерации форм и целых слоев приложения – например, генерация классов по структуре базы данных.

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

Мы выяснили, что по этому поводу думают эксперты, представители ИТ-индустрии:


Алексей Бычко, старший релиз-менеджер (Percona), разработчик проектов Percona Server for MySQL, Percona XtraDB Cluster, Percona XtraBackup, Percona Server for MongoDB, PQuery, преподаватель курса «Системное администрирование» в ИТ- Академии Алексея Сухорукова:

Появляется всё больше и больше сред для автоматизации рутинных вещей – это помогает лишний раз не писать что-то вручную, не изобретать велосипедов. Многое уже предусмотрено в интегрированных средах разработки, из которых можно вызывать нужные библиотеки и так решать стандартные задачи. Для тех, кто умеет и привык думать, это хорошо – можно сконцентрироваться на основном, на логике приложения. (Это люди «старой школы», которым для написания качественного кода хватит и простейшего текстового редактора).

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

По сути, это два подхода, которые выросли из факта наличия проективных Unix-подобных систем и процедурных Windows-подобных. Огромной корпорации, где всё разбито на мельчайшие подзадачки, важна воспроизводимость результата, а не оптимальное решение – если оператор ушёл, нужно, чтобы новый по инструкции делал то же самое и не хуже.

Но если у нас есть задача, которая конкретной процедурной системой, библиотекой или средой решается плохо или не решается вовсе (коллеги постарше помнят, что бывает, когда в написанный в C++ Builder или Delphi текстовый редактор попадает большой файл – ничего не листается и всё тормозит, и это никак не поправить), то нам нужно взять «чистую» систему, которая даёт больше свободы, и позвать программиста, который согласен не просто гуглить, а писать адекватное решение самостоятельно с нуля.

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

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

Конечно, речь идёт не о создании лендингов, а о разработке мало-мальски серьёзного проекта.


Макс Лапшин, создатель ErlyVideo, создатель Flussonic, разработчик многих известных решений в области стриминга видео.

Первый раз сообщения о том, что всё, что надо было написать, уже в целом написали, и теперь программисты просто будут собирать кубики из готовых компонент, и вообще, наверное, программировать мышкой, я услышал году примерно в 1995. Как несложно догадаться, с 1995 года по сегодня было написано безумное количество адского хардкорного системного кода, и возникло и умерло немало больших бизнес-платформ, на которых даже что-то было напрогано «мышкой».

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

Всё дело в том, что индустрия идет вперед. Да, на компьютерах больше не 640 КБ памяти, и программисту под Windows больше можно не волноваться о памяти вообще. Но на замену большим компьютерам пришли маленькие, и их много.

Сегодня всё равно приходится думать, как записать на прошивку IP-камеры софт, упихнувшись в 200 КБ на диске. Приходится думать, как упихнуть код в маленький IOT-сенсор, который должен на своей крохотной батареечке прожить год с радиообменом.

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


Александр Лямин, основатель и CEO компании Qrator Labs, одного из ведущих мировых поставщиков в области защиты от DDoS-атак.

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

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

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

То есть человек-«кодер» решает лишь часть проблем, стоящих перед разработкой.

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

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

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

Поэтому вряд ли когда-нибудь кому-нибудь удастся превратить программиста в оператора ЭВМ окончательно.

Ссылка на основную публикацию
Adblock detector