Пришел шеф. Обрадовал — техническое задание подписано, потенциальная работа окончательно превратилась в Проект. Действительно обрадовал. Мне, как аналитику, пришлось немало поработать над общей моделью обработки. Но ничего, справился. Даже самому понравилось. После обеда пойдем к программистам утрясать рабочие моменты… Да уж, сходили. Нет, поначалу всё было неплохо. Рассказал про модель данных и логику. Программисты одобрительно похмыкали. Потом шеф озвучил остальное. И началось. Пара вроде незначительных и ранее несогласованных с разработчиками деталей привела к резкому повышению температуры. Пытался вбросить пару мыслей. Был вознагражден упертым в схему пальцем и ехидным вопросом «Это сам напишешь?» Пришлось мысли забрать. Разошлись все в состоянии хмурого поиска грибов в зимнем лесу. Причем шеф искал гриб под названием «вдохновение для разговора с заказчиком», программисты — дополнительные пару часов в сутки. А я, как программист в недалеком прошлом и аналитик в текущий момент — ответы на «Это сам напишешь? Если да — то как?»
Пожалуй вынырну я из этого шутливого вступления. Тема задана — с помощью чего аналитик может выполнять роль полноценного разработчика. Некий мысленный эксперимент по автоматизации работы аналитика-программиста.
Кстати — на встречный вопрос «Зачем?» какого-либо однозначного канонического ответа нет. С одной стороны — раз в команде есть специальный человек, который решает отдельную задачу, то зачем на него вешать не очень-то характерную для него функцию. С другой — кто лучше аналитика понимает прикладную логику проекта и требуемое функционирование? Если аналитик будет в состоянии реализовать самостоятельно спроектированное — это будет только плюсом. В общем, полезна ли такая возможность аналитику — одна из тем предлагаемой дискуссии. Но, независимо от своего решения, читать данную статью можно до конца. Если вы против, то мысленно заменяйте «аналитик» на «программист». Результат будет уместен и для того и для другого.
Поехали дальше. У нас в наличии аналитик — человек со светлой головой, прямыми руками и базовой подготовкой в программировании. Обеспечиваем ему рабочее место разработчика. Выделяем компьютер, устанавливаем операционную систему, компилятор и … ставим его и себя в тупик. Подготовка-то у аналитика базовая. Утонет он в большом озере специфики программирования: системы сборки, сетевое взаимодействие, программные интерфейсы баз данных, криптозащита и много других в общем-то знакомых, но непонятных на уровне «сделай сам» для него слов. Явно нужно что-то другое. И это «что-то другое» должно по максимуму исключить необходимость реализации нижнего уровня программного комплекса аналитиком (отмечу для въедливых читателей — «реализации», а не использования). В конце-концов целевая задача — логика, остальное лишь средство достижения цели.
Назовем «что-то другое» абстрактным термином «инструментарий» и попытаемся выработать к нему требования. Пока без особых раздумий о способах реализации. Нужна основная идея.
Пойдем от поля деятельности самого аналитика. Он работает в терминах «проект», «архитектура» системы (как набор серверов разного назначения, клиентских модулей, баз данных, интерфейсов взаимодействия и так далее). Давайте сделаем формальное описание проекта, в котором легализуем все модельные элементы. Какие плюсы это даст? Если подумать — то многое. За каждым модельным элементом скрываются некие шаблонные задачи. И эти задачи решаются отработанными и проверенными штампами, который обычно составляет «культурный слой» любой команды разработчиков. То есть прямое сопоставление «модельный элемент» — «шаблонное решение» существует. На основании этого заставим наш инструментарий сгенерировать для каждой модельной сущности свой код. Если осмыслить такой радикальный фортель разума сразу сложно, то можно пойти от небольшого мысленного эксперимента.
«Сервер». Пусть это будет некий абстрактный сервер, реализующий REST — интерфейс в сети tcp/ip. Транспортный протокол — http, прикладной — json. Операционные системы функционирования — Windows, Linux. Достаточно типичный случай или, по крайней мере, близкий к типичному.
Посмотрим, что можно описать декларативно. Во первых — заявить в нашем описании проекта сам сервер. Пока хватит некого идентификатора и целевых операционных систем. Руками написали немного. Но уже на основании этого наш инструментарий может проделать не такую уж и малую работу: добавить новую цель в общепроектную систему сборки; сгенерировать каркас исполняемого модуля с возможностью запуска в режимах сервиса OC Windows, демона Linux; код для чтения/записи конфигурационного файла; добавить штатное логирование. Откуда взялся исходный код, сгенерированный нашим инструментом? А это собственно и есть тот «культурный слой» опыта предыдущих работ, заботливо формируемый годами. Аналогично добавляем к серверу через соответствующие сущности модельные элементы http — порт, интерфейс взаимодействия с набором допустимых json — запросов. После генерации получаем соответствующие изменения в системе сборки проекта, коде обработки конфигурационного файла. Подтягивается необходимый сетевой уровень и так далее.
Думаю, что принцип понятен. Первый этап размышлений вроде удовлетворителен. Вышеобозначенный аналитик вполне может справиться с таким подходом. Фиксируем момент необходимости «модельное описание проекта — автогенерация кода» в памяти. Размышляем дальше.
У нас получилась масса исходного кода, которая компилируется под заданными ОС и порождает выполняемые модули. Надо заметить — абсолютно бессмысленные. Нет там логики. Вот только на чем ее реализовать? Делаем следующий простой логический шаг в наших размышлениях — нужен язык программирования и сразу второй, более сложный — ни один из общепринятых языков нам не подходит. Хотя бы потому, что наша модель проекта им незнакома. Кроме того — этот язык реализации логики проекта должен быть понятен на уровне синтаксиса, семантики инструментарию с целью контроля корректности на этапе чтения описания проекта. Согласитесь, было бы неприятно получать ошибки при компиляции и сопоставлять сгенерированный код нашему модельному-программному (теперь же именно так) описанию.
Что можно и нужно потребовать от языка описания логики? Полнота по Тьюрингу, возможность преобразования в исходники для компилятора выбранных ОС (иначе придется разрабатывать свой компилятор), расширяемость (подключение внешних модулей на компилируемом языке, так как мало ли какие внешние sdk потребуются в реализации), простота синтаксиса. Обязательно — жесткий контроль в рамках статического анализа: неиспользуемые переменные и методы, несоответствие типов и так далее. Автогенерация кода не должна порождать хаос.
Жестко пошла мысль насчет языка реализации логики? Возможно. И, возможно, свернула не туда. К сожалению, дальнейшие размышления невозможны без прикидок о способе реализации. Это уже более серьезно и явно выбивается из темы мысленного эксперимента.
Вроде логический круг замкнулся. И подход «модельное описание проекта плюс реализация логики с последующей кодогенерацией» имеет неплохой потенциал: есть выход на снижение порога вхождения в полноценное программирование для аналитика, на системный подход к использованию «культурного слоя», на повышение эффективности разработчиков и так далее.
С другой стороны всё это пока напоминает пятиминутные фантазии за кружкой чая в перерыве между работой. Ибо окончательным критерием истины является практика, а наши размышления для практической стороны только добавили вопросов. Думаю, что на некоторые попытаюсь ответить со стороны практика. Не сочтите скрытой рекламой, я просто пытаюсь дополнить все свои мысленные выкладки реальными фактами.
«Возможна ли реализация?». Вопрос для проформы. Но, тем не менее — да. В нашей команде подобный инструментарий есть. Мало того, является основным средством разработки прикладных проектов.
«Насколько сложна реализация?». Если вкратце — непростая. В основном из-за языка реализации логики. Есть еще один трудоемкий момент, требующий постоянного времени разработчиков — инструментарий не является статикой, как и любое другое средство разработки. Практический любой прикладной проект приносит в «культурный слой» под капотом инструментария что-то новое.
«Стоит ли овчинка выделки?». Для нашей команды — да. Для вашей — не знаю. Чисто технически можно выработать несколько критериев применимости: у вас есть проекты, которые в своей основе решаются однотипно (как примеры — классическая трехзвенная архитектура клиент-сервер-СУБД или браузер-веб сервер-прикладной сервер-СУБД), большое количество рутинного ручного кода для шаблонных операций. И всё остальные моменты, которые поддаются автоматизации. Как говорит один из наших разработчиков — «этот инструментарий возник из-за мозолей на пальцах». Так что это вопрос в вашу сторону. И надеюсь, что от вас в этом отношении будет отклик в виде обсуждения.
«А что насчет аналитика из дурацкого вступления статьи?» С этим всё хорошо. В нашей команде аналитик в роли ведущего разработчика проекта это скорее норма, чем исключение. Хотя дай ему задание написать на С (у нас C/C++ используется в качестве языка, на который происходит кодогенерация) простой «Hello,world!» — без подсказки не справится. Ну да ладно, от него не требуется знания кухни классической разработки. За это, собственно, и боролись. Вообще, классовые различия аналитик — программист инструментарий очень сильно стирает.
Вот и всё. Хотя нет — надо еще прояснить мотивацию написания данного словесного потока. А то получается — сначала теоретизировал, потом похвалился. А смысл? Смысл в том, что хочется поинтересоваться у сообщества — интересен ли такой комплексный подход к автоматизации разработки?
Автор: pull
