Whirl Platform — разработка длинной в 10 лет
Поведаю историю развития одного проекта длительностью в более чем 10 лет. На основе проекта, речь о котором пойдет ниже, случилось мое становление как разработчика/архитектора.
История более биографическая, чем техническая, с вкраплением мыслей о разработке в целом и небольшим обзором проекта который развивает наша команда. Если вы ждете техно-жесткача с фреймворками, конфигами и кусками кода, то дальше читать не надо — такого не будет. Продолжив вы узнаете про чужой опыт развития долгоживущего продукта, узнаете о еще одном отечественном open source проекте и просто увидите картинки с UI конструктором приложений.
Картинка
Как все начиналось
Все началось примерно в 2009 году. Наша первая версия команды стартовала разработку инструмента, который будет удобен нам самим в разработке типовых интерфейсов без написания большого количества однотипного кода. На тот момент не было такого понятия как low code или no code, а широко ходила трудно выговариваемая аббревиатура WYSIWYG (What You See Is What You Get) — что видишь, то, собственно говоря, и имеешь. Вот этого подхода мы в силу своего понимания и старались придерживаться.
Изначально у нас была база с которой мы стартовали. Нулевая версия уже была реализована на стеке Java-Servlets-JSP и заточена на работу с БД Oracle (о самом проекте чуть ниже подробнее). Почти все сделано было одним довольно крутым дядькой который с лёгкостью мог вертеть своим ассемблером и писал огромные корпоративные биллинги на Delphi. Он был идейным вдохновителем, архитектором и тем массивным тараном, который пробивал с пеной у рта идею в руководстве, что свое надо делать, нефиг покупать всякое дорогущее костыльное айбиэм эйчпи и прочий энтерпрайз. Без этого человека ничего не стартовало бы.
Во главе с ним и сформировалась довольно хорошо мотивированная джуновая команда. Случаем я как раз попал в эту команду именно нормальным разработчиком, а не на фирму «тыж программистом» прокладывать сеть и чинить картриджи принтеров, чем в то время большая часть прогеров в небольших конторах и занималась. Мы все хотели кодить просто потому, что хотели кодить и делать свой продукт, а не потому, что зарплата с большим количеством нулей. Вообще тогда мало кто попадал в профессию из-за денег — в IT тогда их было чуть выше среднего, но не так чтобы намного.
И понеслось… Не было какого-то четкого плана кроме того, что нужно повторить все что было в версии на JSP и осовременить все это под трендовые технологии. С утра придумываем — после чаепития начинаем делать.
Тезисно, что хотелось иметь:
Возможность рисовать интерфейсы прямо в браузере. Типа Delphi, но свое и на вебе.
Все очень плотно и удобно должно вязаться с БД, как в плане источника данных, так и исполнения кода.
Трехзвенная архитектура. Причем в звене сервера приложений никакой бизнес логики, чисто технина, которая должна связывать фронт с логикой в БД. На этом пункте кто-то начнет плеваться и говорить, что подход лузерский, не правильно так делать и т.д. и т.п., но именно это подходило под бизнес задачи и текущую архитектуру всего с чем мы работали на тот момент.
На севере: Tomcat и его стандартные сервлеты. Мы как-то своими не окрепшими мозгами джунов поняли, что JavaEE это тупиковая ветвь, да и всякие навороты не слишком популярного в то время Spring-а нам не дадут какого-то ощутимого профита. В общем мы за осознанный подход.
На фронте GWT — это тот который компилирует Java в JavaScript. Ну, а чё! Знали более менее вменяемо именно Java — ну его в пень ваш этот JS со всеми его »'11'+1='111' '11'-1=10 — какого х…?!» Да и рассинхрон реализации стандартов в браузерах был тогда катастрофический и GWT позволял это все более менее удобно обходить. За счет этого кстати помимо Firefox и Chrome мы без особых напрягов работали нормально во всех версиях IE начиная с 6-ой.
Новый на тот момент подход Single Page Application.
Все взаимодействие через AJAX.
На этом из начальных условий все.
Прошло три года… мы построили из костылей и процедурного кода в Java «чудо-юдо» которое очень хорошо подходило под наши задачи.
По крупноблочному функционалу вышло не так много:
Визуальный конструктор форм метаданные которых хранилась нормализовано в БД. Как оказалось хранить данные в БД в таком виде под описание интерфейса это то ещё извращение, но получилось, то что получилось.
Визуальный конструктор ER объектов в БД — не надо было писать DDL. Зачем его надо было не писать, сейчас я понять уже не могу, так как основными пользователями были именно разработчики БД которые умели все это делать качественнее, да и все равно нужно было все, что автогенерировалось этим конструктором допиливать по итогу.
Довольно специфическая самописная ORM.
На базе этой платформы мы делали внутренние инструменты для бизнеса и личный кабинет пользователя.
В процессе дальнейшей работы со всем этим, как бы невзначай и сбоку, но при этом очень пламенно в нашем отделе загорелась микро революция в результате которой значительная часть команды ушла в другую организацию вместе с нашим руководителем и мной. Этой группой мы основали там отросток секты поклонников собственной платформы со своим блек джеком и т.д.
Руководитель, с которым мы релоцировались, в новой организации быстро ушел в высшие эшелоны власти, так как был довольно активным и пробивным человеком. Отчасти я перенял его паттерны поведения и в каждой организации в которой в дальнейшем работал довольно быстро из штатного программиста вырастал либо в лиды, либо в архитекторы. В современных реалиях оказывается, что при всей важности технических знаний софт скиллы имеют больший вес в развитии твоей карьеры.
Примерно с этого момента я стал архитектором, Product Owner-ом, визионером, разработчиком, лидом самой платформы и всего, что вокруг нее строилось.
Как раз тогда появилось понимание основной сути продукта:
Это должна быть система рассчитанная на разработчиков приложений с минимальными требованиями по стеку технологий — только SQL на старте.
Порог вхождения должен быть максимально низким. Через недели 3 старта с полу-активными обучением разработчик должен писать приложения для бизнеса: как бек, так и фронт часть.
Избавляемся от всего лишнего: никакой автогенерации объектов в БД. Разработчик SQL умеет это делать лучше.
Приняли эти условия, сохранили технологический стек и переписали все с нуля за года 2.
Причины по которой приняли решение переписать все это:
Отвратительно спроектированный дизайн кода платформы.
Отсутствие концептуальной целостности реализованных решений.
Плохо расширяемый функционал.
Влиянием на развитие платформы этих трех фактором было то, что было довольно сложно добавлять новый функционал. Нас тормозило качество кода и не возможность убрать/изменить/расширить функционал, который уже использовался в нескольких десятках приложений.
Вообще на реализацию с нуля ушло больше времени чем я рассчитывал. По итогу этого и последующих проектов у меня в голове укрепилась мысль, что любой долгоживущий продукт должен развиваться непрерывно. То есть не должно возникнуть момента, когда мы приходим к мысли, что надо все выкинуть и переписать с нуля. Если ты рубишь взрослое дерево, то тебе все равно понадобится много лет, чтобы вырастить новое до того же состояния — так же и с разработкой ПО.
Параллельно с написанием новой версии платформы, мы разрабатывали кучу проектов как на старой, так и на новой версии. Были как небольшие проекты, где были задействованы всего по одному разработчику+аналитику+тестировщику, так и довольно крупные под пару десятков человек в команде и с пользователями из десятка различных подразделений.
По итогу бизнесу вкатило делать проекты на нашей платформе, хотя других вариантов в организации было огромное количество. Из плюсов, которые влияли на выбор в нашу сторону:
По отзывам ИТ руководства, с нуля и до внедрения приложения созданного с помощью платформы необходимо было чуть ли не в два раза меньше времени чем по классике.
Нужен только один человек для разработки, а не фронт+бек+БД-шник. Правда к нашим проектам довольно часто подключали матёрых БД-шников старожилов в качестве проектировщиков/консультантов/менторов.
Дешевизна специалистов. SQL разработчик не так дорог и их было больше, чем например дифицитных Java. По другому, если разрабатывать в одного, то нужен фуллстек если хотим не плодить пусть даже не большую, но команду и обеспечивать между ними коммуникации. По факту мне в команду давали вчерашних студентов (со знанием технологий БД), которые недели через 3 могли делать бек+фронт в одиночку.
Бывали случаи, когда бизнес давал на оценку проект и, сравнивая оценки по разработке у нас с решением от команды фронт+бек+БДшник, через директоров продавливал реализацию именно через нас. Вопрос был не в затратах на разработку из-за стоимости специалистов (довольно часто в крупных корпорациях это не самое приоритетное), а именно в сроках реализации.
Здесь надо оговориться — чтобы все это хорошо работало необходимо 2 компонента:
Небольшая сильная команда core специалистов со скиллами Java и SQL для допиливания самой платформы.
Хорошая система наставничества и онбординга для начинающих спецов которые разрабатывают приложения непосредственно для бизнеса.
С этим мы некоторое время процветали.
Затем я уволился в никуда так как подзациклился, да и хотелось работать на удаленке и параллельно путешествовать. Сменил за это время несколько работодателей. Думал, что нужно поработать с новыми технологическими стеками, языками, продуктами — искал что-то неизведанное… Поработал — понял, что в корпоративной разработке ничего принципиально нового нет, а все, что преподносится как «прорывное решение», под капотом работает также как и то, что придумывали еще 5–10 лет назад (может и больше), просто в красивой обертке/на новом успешно-успешном языке/с новыми удобно-удобным API. Поизучал машинное обучение (даже купил топ видеокарту под это), прошел курс по квантовым вычислениям от СпбГУ (вот там что-то новое и куча математики).
При этом периодически возвращался к этому проекту, так как постоянно мне попадаются проекты для которых вообще не требуется городить всего этого набора технологий и фреймворков а-ля спринги, хибернейты, депенденси инджекшен, реакты, ангуляры и т.д. Вижу возможности и приемущества использования как в самостоятельной работе так и на собеседованиях при вопросах по архитектуре проектов над которыми кандидаты работают. Всякие админки, CMS, WMS, LMS и другое трехбуквенное. Плюс мысль о том что ты развиваешь, что-то свое родное она знаете-ли греет.
Сейчас платформа вместе со мной тоже отпочковалась в еще одну ветку. Теперь мы уже с новой командой разработчиков, работающих на энтузиазме, находимся в текущей точке. Проект живет в open source под лицензией GPLv3 в репозитории и в зеркале.
Что же вообще мы делаем такое?
Платформа называется Whirl Platform.
Лучше всего она подходит для создания внутрикорпоративных инструментов — всего того о чем писал выше: админки, системы управление клиентами, контентом, ассортиментом, мастер-данными и другими артефактами бизнеса.
Есть случаи, где использование будет не совсем уместно. Там где появляется универсальность уменьшающая трудозатраты разработки сразу проседает гибкость таких инструментов. Наша платформа не исключение. В случаях где например требуется высокая степень гибкости визуального оформления интерфейсов платформа не подойдет. Появляются дополнительные трудозатраты на кастомизацию заложенного в компонентах платформы функционала, а с учетом того, что необходимо обеспечивать обратную совместимость эти трудозатраты могут быть довольно значительными.
Далее кратко, без деталей с помощью скриншотов опишу пару основных принципов вокруг которых строится работа нашей платформы.
Связка данных с компонентами с помощью SQL
Прототип интерфейса используется как шаблон, в который при работе приложения наложением на него данных предоставляемых результатом выполнения SQL запроса подставляются необходимые параметры.
Трансляция прототипа в рабочий интерфейс.
Результат запроса может иметь множество результатов и в этом случае прототип тоже множится на несколько экземпляров
Дублирование компонентов при множестве данных.
Ничего не обычного, простая шаблонизация — все этим пользуются.
Как это делается в нашем инструменте:
Делаем прототип интерфейса через Drag&Drop:
Создание прототипа в редакторе.
Прописываем заменяемые параметры.
Шаблонизация значений свойств компонентов.
Выбираем область для которой нужно заменить значения и прописываем SQL-запрос.
Связка прототипа с данными.
Таким образом готовится интерфейс.
Связка событий UI с логикой в БД
Выполнение бизнес логики происходит по событиям компонентов, а источником параметров опять же являются компоненты. Даже не буду схемы рисовать — снова стандартная практика. Сразу к делу, как это выглядит у нас.
Для компонента определяем событие по которому выполняется функция БД:
Создание события компонента.
Добавляем передаваемые параметры:
Привязка списка параметров событию.
Даем право на выполнение группе/ам пользователей:
Права на выполнение события.
Собственно все — кусок приложения готов.
Функциональность
Одной статьей довольно сложно в краткой форме описать всю функциональность доступную в платформе. Да и нет у меня задачи сконцентрировать здесь всю документацию. Из основного хочется отметить:
Более 30 компонентов для построения интерфейса.
Работа с несколькими БД одновременно — то есть можно в одной форме вытаскивать и компоновать данные параллельно из независимых БД. Модное сейчас название для этого: Microservice Ready.
Безопасность:
Доступ к приложениям на основе групп.
Разделение прав доступа к объектам и событиям.
Константные и вычисляемые динамически права.
Контроль доступа на уровне колонок и строк.
Отчёты в форматах Html и Excel.
CRUD для таблиц БД «из коробки».
Поддержка мультиязычности в приложениях.
Инструменты совместной разработки приложений.
Вместо заключения
Наша небольшая команда разработчиков-энтузиастов которые двигают все вперед: @lichnost, @VladWick, @NastiaDanchenko, @DaniilOrlov.
Несколько раз в неделю мы созваниваемся онлайн и обсуждаем задачи, проблемы и технологии. Мы открыты для тех кому нравится разрабатывать и кто хочет поучаствовать в каком-то движе, но до сих пор не решился во что-то ввязаться.
Проект живет здесь
Зеркало в github.com
Заинтересованные могут потестировать онлайн. Как это сделать описано в README проекта.
Любые комментарии/вопросы/пожелания приветствуются в комментариях, в issue gitlab.com или в личных сообщениях.
На этом все.
Hasta la vista!
