Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
ИТ-компании всё чаще задумываются о необходимости оптимизации разработки ПО за счёт автоматизации рутинных процессов. С каждым годом желания заказчиков, сложность и объёмы проектов возрастают. Сегодня никого уже не удивишь решениями с миллионами строк кода. При этом стоимость разработчиков на рынке неуклонно растёт — за последний два года она увеличилась в два раза. Оптимизация призвана решить вопросы снижения стоимости разработки, уменьшения времени кодинга и повышения качества создаваемых продуктов.
В 2010 году компания ОТР задумалась о необходимости уйти от ручной обработки требований заказчика и сократить штат разработчиков с помощью средств автоматизации. К тому времени был накоплен большой опыт работы со сложными системами, чтобы понять все тонкости и возможные проблемные места разработки. Были заложены основы концептуального плана развития, который базировался на максимальной автоматизации процесса разработки.
Дополнительный плюс автоматизации — снижение количества ошибок со стороны программистов. Не секрет, что каждый разработчик допускает ошибки. Это не плохо, просто таковы реалии разработки сложных систем. Как говорится, не бойся первой ошибки, избегай второй. Кто-то, конечно, допускает их реже, но всё же полностью избавиться от ошибок при ручной разработке просто невозможно, как минимум из-за человеческого фактора. Не говоря уже об унифицированности кода.
Это подтверждает исследование Coralogix — разработчик в среднем на 1000 строк кода допускает 70 ошибок. Для исправления ошибок требуется минимум в 30 раз больше времени, чем на кодинг.
Как было раньше
Заместитель начальника управления разработки и архитектуры компании ОТР Алексей Кузнецов рассказывает, что в процессе разработки сложных информационных систем обязательными участниками являются бизнес-аналитики. Они готовят задание с указанием того, как должен работать будущий проект. Но есть трудность для запуска заданий в разработку — они пишутся на языке бизнеса.
Тут на помощь приходит ещё один участник процесса разработки — системный аналитик, который переводит и дополняет инструкцию бизнес-аналитиков на понятный разработчикам язык. После чего программисты читают постановку задачи и приступают к кодингу проекта.
В этом процессе мы увидели сразу же несколько возможностей для оптимизации. Во-первых, системных аналитиков можно заменить на скрипты, которые автоматически будут раскладывать бизнес-требования в готовую инструкцию. Во-вторых, ряд процессов при разработке повторяются из проекта в проект. Можно сократить штат высокоуровневых разработчиков, если запрограммировать среду разработки самостоятельно вставлять куски кода в нужные места. Реализовывать задумку решили на Java.
Первые шаги со «Студия 1.0»
Мы решили делать low-code систему, которая потребует минимум разработчиков высокого уровня, и будет понятна технологам, ранее никогда не писавшим код. Обычно подобные проекты используют визуальные интерфейсы с простой логикой и функциями drag-and-drop для прописывания жизненного цикла. Код подставляется в автоматическом режиме.
Чтобы визуально представить low-code систему, можно вспомнить среду для быстрой разработки Delphi 7. С ней многие читатели могли познакомиться ещё в школе или вузе. Для создания элемента достаточно было перетащить его на поле рабочий области. Он тут же прописывался в теле программы и оставалось лишь закодировать логику.
В «Студии 1.0» принцип был схож с Delphi 7, но только описывать логику уже было не нужно. Из имеющейся базы подтягивался написанный метод, который ранее использовался на проектах. Важно отметить, что мы не собирались полностью отказываться от труда программистов. Если технолог не находил нужный код, то программист, обслуживающий проект, дописывал недостающие куски самостоятельно. С каждой итерацией инструмент становился мощнее.
Специалисту достаточно было создать в визуальном конструкторе элементы будущей системы: структуру данных, взаимосвязи, статусные модели, жизненный цикл, бизнес-логику, пользовательский интерфейс. Весь процесс чем-то напоминает популярную игру Alchemy, когда нужно соединять определённым образом имеющиеся элементы, чтобы получить нужный результат.
Как только модуль саморазработки выдавал созданный на основе сконструированных элементов код, проходил процесс тестирования. После чего готовый продукт отдавался клиенту.
С этим low-code решением нам удалось сократить количество высокоуровневых разработчиков, которые работают над проектами, на 44%. А также уменьшить время разработки и тестирования готового продукта.
Автоматизируем разработку со «Студия 2.0»
В первой версии «Студии» мы не смогли уйти от необходимости передавать задание от бизнес-аналитиков к системным аналитикам. Но уже сейчас разрабатывается интерпретатор требований, который парсит техническое задание от бизнес-аналитиков и адаптирует его для разработчиков. Модуль умеет работать с популярными форматами файлов от офисных пакетов. Бизнес-аналитикам не придётся менять привычные инструменты.
Как это работает? Интерпретатор получает на входе от бизнес-аналитиков неструктурированные требования, которые подчас представляют собой кучу таблиц с атрибутами кнопок, жизненных циклов и так далее. На некоторых проектах подобные требования занимают до 600 страниц. А это половина книжного формата романа «Война и мир».
На выходе модуль формирует XML файл со структурированными требованиями. Их можно дать на вход ещё одной новинке — модулю саморазработки. Он позволит отказаться от ручной работы в конструкторе. С помощью ИИ модуль выбирает релевантный метод реализации определённой функциональности и подставляет необходимый код. Например, он может автоматически создать визуальную форму и наполнить нужными элементами пользовательского интерфейса. Без модуля технологи ранее делали это вручную.
Модуль саморазработки постоянно обновляется и обрастает новыми возможностями и методами реализации. Он является главным отличием от первой версии «Студии». Модуль позволит нам в будущем добиться максимальной автоматизации.
Задумались мы над облегчением труда бизнес-аналитиков. Писать талмуды с табличками, конечно, неудобно. Заменить текстовые и табличные редакторы призвана «Система управления требованиями». В её интерфейсе с помощью дружелюбного визуального редактора бизнес-аналитики могут прописывать параметры и атрибуты кнопок, жизненного цикла, бизнес-логики и так далее. По нажатию на кнопку все требования выгружаются в единый файл, где они хранятся в структурированном виде. Файл можно передать в модуль саморазработки.
«Студия 2.0» оптимизирует затраты на тестирование, так как нет смысла делать отладку после работы автоматизированной системы.
Куда идём дальше
Наша «Студия» продолжает совершенствоваться. Например, мы хотим и дальше упрощать работу бизнес-аналитиков. Для этого разрабатывается функция транскрибации разговора специалиста с клиентом. Бизнес-аналитик во время телефонных переговоров будет использовать определённые ключевые слова и теги, которые автоматически расшифруются в требования для передачи в модуль саморазработки.
Отдельно список требований будет сформирован для подтверждения заказчиком. Он экспортируется в привычные офисные форматы DOC или XLS. Процесс займёт не больше времени, чем выпить чашечку кофе.
В будущем планируем сделать «Студию» кроссплатформенной. То есть отвязать её от платформы «ОПОРА», где она сейчас работает, и подключать к другим системам. Это как раз то, чего не хватает многим системам автоматизированной разработки.
Намечен план развития до 2023 года. «Студия» уже сейчас используется для решения коммерческих задач компании ОТР. Но со временем мы отдадим её и во внешнее пользование.
