Чего мы можем ожидать в сфере разработки ПО — и что уходит в прошлое? Портал Enterprisers Project приводит мнения экспертов о контейнерах, Low-code, Java и многом другом.
Сегодня поговорка «каждая компания — софтверная» верна как никогда, поскольку организации продолжают свои усилия по цифровой трансформации, чтобы соответствовать запросам клиентов и конкурировать за самые талантливые кадры.
Что может быть лучше для изучения тенденций в области разработки ПО, чем ознакомление с мнениями экспертов-практиков?
Расцвет контейнеров
«Очевидно, что последняя тенденция — это контейнеризация. Kubernetes, Podman и все другие технологии, связанные с контейнеризацией, нашли свое место и развиваются. Любой разработчик ПО должен изучить их, если он хочет идти в ногу со временем», — считает Патрик Дюфресне, основатель компании IKUS Software.
По его словам, контейнеризация — это не только новый способ развертывания приложения, это также новый способ мышления и планирования. Хотя это влияние еще не заметно на небольших Open Source-проектах, более крупные проекты, такие как Gitlab, охватывают контейнеризацию и предоставляют архитектуру, которая будет развернута на Kubernetes.
«У отдельного контейнера может быть очень простая ответственность, но вы можете создать сотни контейнеров, каждый из которых будет нести свою долю ответственности за работу вашего проекта. С этим также приходит возможность повторного использования контейнеров и образов Docker», — отмечает Дюфресне.
В проекте, над которым он работает, практически для всего используется logstash. «Эта маленькая программка требовательна к ресурсам, но она очень гибкая и позволяет нам обрабатывать тысячи событий в секунду масштабируемым способом. Мы используем logstash для приема вызовов syslog, trap и webhook. А также для обработки, агрегирования, преобразования и обогащения данных по мере необходимости с предоставлением всего этого через веб-интерфейс. В общей сложности у нас около 40 контейнеров, в которых работает logstash, и каждый из них выполняет одну задачу», — рассказывает Дюфресне.
Угасание Java
«Не поймите меня неправильно, я любил Java. Это основной язык программирования, который я изучал в университете, и он служил мне долгое время. Некоторое время это был единственный язык программирования на рынке, который был кросс-совместим без проблем, — говорит Дюфресне. — Но сейчас, когда на рынке появились такие новые языки, как Go, Rust, Ruby и мой любимый Python, я чувствую, что лучшие годы Java остались в прошлом. В сообществе разработчиков открытого кода, по моим ощущениям, Java никогда не был языком выбора. Но в бизнесе Java был и остается таковым. Чтобы он ушел, возможно, потребуется время, но это неизбежно. Я не буду скучать по многословию и неряшливости Java».
Расцвет разработки Low-code
«Low-code-разработка определенно развивается. С начала пандемии ИТ-лидеры ускорили свои программы цифровой трансформации, но центральные ИТ-службы могут обеспечить лишь очень немного изменений. Следующий уровень трансформации заключается в том, чтобы дать возможность бизнес-подразделениям оптимизировать свои рабочие процессы и самостоятельно добавлять новые функции. И вот тут-то и приходит на помощь разработка Low-code», — говорит Джим Холл, генеральный директор компании Hallmentum.
Он отмечает, что термин «Low-code» в определенной степени новый, хотя на самом деле эта идея существует уже давно. Электронные таблицы были первой средой Low-code, начав с LANPAR в 1969 г. и взлетев до небес с VisiCalc в
«С тех пор каждое бизнес-подразделение с помощью электронных таблиц создало определенный уровень автоматизации или оптимизации процессов. Будь то построение бюджетов, составление отчетов о тенденциях или ввод данных в центральную ИТ-систему, электронные таблицы долгое время были основной технологией Low-code, — говорит Холл. — Мы видели, как появлялись и исчезали и другие технологии Low-code. Один запоминающийся пример: „персональные базы данных“ типа Microsoft Access процветали в
По его словам, рассматривая очередные тенденции в сфере Low-code, мы должны убедиться, что эти системы по-прежнему ориентированы на среднего бизнес-пользователя и не требуют тонны технических знаний для выполнения реальных задач. В то же время ИТ-лидеры должны сбалансировать потребности пользователей с ИТ-безопасностью, хранением данных, пропускной способностью и другими типичными аспектами центральных ИТ. «Те их них, кто смогут найти этот баланс, действительно преобразуют организации с помощью технологий», — считает Холл.
Уходит взгляд на программную инженерию как центр затрат
«Тенденция такова, что организации, которые раньше рассматривали инженеров-программистов как центр затрат, теперь по праву считают своих инженеров инноваторами, — говорит Рави Лачхман, технический директор Shipa.io. — Цели программной инженерии и бизнеса сегодня совпадают больше, чем когда-либо прежде. Организационные структуры, динамика команд, технологические стеки и пути к экспертизе теперь выстраиваются согласованно для поддержки инженеров, совершенствующих свое ремесло. На культурном уровне инженерам предоставляется свобода действий, необходимая для проб и ошибок и, в конечном итоге, успешного внедрения ценных программных инноваций».
Программная инженерия все больше рассматривается как центр инноваций
По словам Лачхмана, в этом же ключе организации все больше стремятся поддержать инженеров в их желании освоить новые навыки. Эта тенденция приводит к появлению модели Spotify, в которой инженеры могут менять роли и автономно взаимодействовать с «иными племенами и гильдиями» (и учиться у них) в своих сетях и отраслях.
«Организации с сильной культурой платформенного инжиниринга позволяют разработчикам регулярно менять команды без необходимости напрягаться по поводу пополнения тех команд, которые сосредоточены на технологиях развертывания или сборки», — отмечает Лачхман.
На уровне платформы организации также уделяют повышенное внимание сокращению технического долга, особенно в нефункциональных областях. В качестве примера Лачхман приводит движение DevSecOps в области безопасности и практику Site Reliability Engineering в области масштабирования/надежности — все это позволяет разработчикам сосредоточиться на разработке функций, а не на потенциальном техническом долге.
«Постепенный прогресс обеспечивает долгосрочный успех. Это тенденция, которая продолжает процветать, и я не ожидаю, что она ослабнет в ближайшее время. Платформы, инструменты и подходы продолжают двигаться в сторону более мелких, более постепенных изменений. Рост микросервисов, например, представляет собой эволюцию самой архитектуры для поддержки постепенных улучшений. Инженеры с постоянно развивающимися навыками могут обеспечить непрерывность итеративных доработок, сокращая цикл обратной связи и предоставляя разработчикам возможность получать ее от пользователей и от измерения производительности систем», — считает Лачхман.
