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

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

Как все начиналось

Все началось примерно в 2009 году. Наша первая версия команды стартовала разработку инструмента, который будет удобен нам самим в разработке типовых интерфейсов без написания большого количества однотипного кода. На тот момент не было такого понятия как low code или no code, а широко ходила трудно выговариваемая аббревиатура WYSIWYG(What You See Is What You Get) - что видишь, то, собственно говоря, и имеешь. Вот этого подхода мы в силу своего понимания и старались придерживаться.

Изначально у нас была база с которой мы стартовали. Нулевая версия уже была реализована на стеке Java-Servlets-JSP и заточена на работу с БД Oracle(о самом проекте чуть ниже подробнее). Почти все сделано было одним довольно крутым дядькой который с лёгкостью мог вертеть своим ассемблером и писал огромные корпоративные биллинги на Delphi. Он был идейным вдохновителем, архитектором и тем массивным тараном, который пробивал с пеной у рта идею в руководстве, что свое надо делать, нефиг покупать всякое дорогущее костыльное айбиэм эйчпи и прочий энтерпрайз. Без этого человека ничего не стартовало бы.

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

И понеслось... Не было какого-то четкого плана кроме того, что нужно повторить все что было в версии на JSP и осовременить все это под трендовые технологии. С утра придумываем - после чаепития начинаем делать.

Тезисно, что хотелось иметь:

1. Возможность рисовать интерфейсы прямо в браузере. Типа Delphi, но свое и на вебе.

2. Все очень плотно и удобно должно вязаться с БД, как в плане источника данных, так и исполнения кода.

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

4. На севере: Tomcat и его стандартные сервлеты. Мы как-то своими не окрепшими мозгами джунов поняли, что JavaEE это тупиковая ветвь, да и всякие навороты не слишком популярного в то время Spring-а нам не дадут какого-то ощутимого профита. В общем мы за осознанный подход.

5. На фронте GWT - это тот который компилирует Java в JavaScript. Ну а чё! Знали более менее вменяемо именно Java - ну его в пень ваш этот JS со всеми его "'11'+1='111' '11'-1=10 - какого х...?!" Да и рассинхрон реализации стандартов в браузерах был тогда катастрофический и GWT позволял это все более менее удобно обходить. За счет этого кстати помимо Firefox и Chrome мы без особых напрягов работали нормально во всех версиях IE начиная с 6-ой.

6. Новый на тот момент подход Single Page Application.

7. Все взаимодействие через AJAX.

На этом из начальных условий все.

Прошло три года... мы построили из костылей и процедурного кода в Java "чудо-юдо" которое очень хорошо подходило под наши задачи.

По крупноблочному функционалу вышло не так много:

1. Визуальный конструктор форм метаданные которых хранилась нормализовано в БД. Как оказалось хранить данные в БД в таком виде под описание интерфейса это то ещё извращение, но получилось, то что получилось.

2. Визуальный конструктор ER объектов в БД - не надо было писать DDL. Зачем его надо было не писать, сейчас я понять уже не могу, так как основными пользователями были именно разработчики БД которые умели все это делать качественнее, да и все равно нужно было все, что автогенерировалось этим конструктором допиливать по итогу.

3. Довольно специфическая самописная ORM.

На базе этой платформы мы делали внутренние инструменты для бизнеса и личный кабинет пользователя.

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

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

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

Как раз тогда появилось понимание основной сути продукта:

1. Это должна быть система рассчитанная на разработчиков приложений с минимальными требованиями по стеку технологий - только SQL на старте.

2. Порог вхождения должен быть максимально низким. Через недели 3 старта с полу-активными обучением разработчик должен писать приложения для бизнеса: как бек, так и фронт часть.

3. Избавляемся от всего лишнего: никакой автогенерации объектов в БД. Разработчик SQL умеет это делать лучше.

Приняли эти условия, сохранили технологический стек и переписали все с нуля за года 2.

Причины по которой приняли решение переписать все это:

• Отвратительно спроектированный дизайн кода платформы.

• Отсутствие концептуальной целостности реализованных решений.

• Плохо расширяемый функционал.

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

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

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

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

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

2. Нужен только один человек для разработки, а не фронт+бек+БД-шник. Правда к нашим проектам довольно часто подключали матёрых БД-шников старожилов в качестве проектировщиков/консультантов/менторов.

3. Дешевизна специалистов. SQL разработчик не так дорог и их было больше, чем например дефицитных Java. По другому, если разрабатывать в одного, то нужен фуллстек если хотим не плодить пусть даже не большую, но команду и обеспечивать между ними коммуникации. По факту мне в команду давали вчерашних студентов(со знанием технологий БД), которые недели через 3 могли делать бек+фронт в одиночку.

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

Здесь надо оговориться - чтобы все это хорошо работало необходимо 2 компонента:

1. Небольшая сильная команда core специалистов со скиллами Java и SQL для допиливания самой платформы.

2. Хорошая система наставничества и онбординга для начинающих спецов которые разрабатывают приложения непосредственно для бизнеса.

С этим мы некоторое время процветали.

Затем я уволился в никуда так как подзациклился, да и хотелось работать на удаленке и параллельно путешествовать. Сменил за это время несколько работодателей. Думал, что нужно поработать с новыми технологическими стеками, языками, продуктами - искал что-то неизведанное... Поработал - понял, что в корпоративной разработке ничего принципиально нового нет, а все, что преподносится как "прорывное решение", под капотом работает также как и то, что придумывали еще 5-10 лет назад(может и больше), просто в красивой обертке/на новом успешно-успешном языке/с новыми удобно-удобным API. Поизучал машинное обучение(даже купил топ видеокарту под это), прошел курс по квантовым вычислениям от СпбГУ(вот там что-то новое и куча математики).

При этом периодически возвращался к этому проекту, так как постоянно мне попадаются проекты для которых вообще не требуется городить всего этого набора технологий и фреймворков а-ля спринги, хибернейты, депенденси инджекшен, реакты, ангуляры и т.д. Вижу возможности и приемущества использования как в самостоятельной работе так и на собеседованиях при вопросах по архитектуре проектов над которыми кандидаты работают. Всякие админки, CMS, WMS, LMS и другое трехбуквенное. Плюс мысль о том что ты развиваешь, что-то свое родное она знаете-ли греет.

Сейчас платформа вместе со мной тоже отпочковалась в еще одну ветку. Теперь мы уже с новой командой разработчиков, работающих на энтузиазме, находимся в текущей точке. Проект живет в open source под лицензией GPLv3 в репозитории и в зеркале.

Что же вообще мы делаем такое?

Платформа называется Whirl Platform.

Лучше всего она подходит для создания внутрикорпоративных инструментов - всего того о чем писал выше: админки, системы управление клиентами, контентом, ассортиментом, мастер-данными и другими артефактами бизнеса.

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

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

Связка данных с компонентами с помощью SQL

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

Результат запроса может иметь множество результатов и в этом случае прототип тоже множится на несколько экземпляров

Ничего необычного, простая шаблонизация - все этим пользуются.

Как это делается в нашем инструменте:

1. Делаем прототип интерфейса через Drag&Drop:

2. Прописываем заменяемые параметры.

4. Выбираем область для которой нужно заменить значения и прописываем SQL-запрос.

Таким образом готовится интерфейс.

Связка событий UI с логикой в БД

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

1. Для компонента определяем событие по которому выполняется функция БД:

2. Добавляем передаваемые параметры:

3. Даем право на выполнение группе/ам пользователей:

Собственно все - кусок приложения готов.

Функциональность

Одной статьей довольно сложно в краткой форме описать всю функциональность доступную в платформе. Да и нет у меня задачи сконцентрировать здесь всю документацию. Из основного хочется отметить:

• Более 30 компонентов для построения интерфейса.

• Работа с несколькими БД одновременно - то есть можно в одной форме вытаскивать и компоновать данные параллельно из независимых БД. Модное сейчас название для этого: Microservice Ready.

• Безопасность:
  

  • Доступ к приложениям на основе групп.

  • Разделение прав доступа к объектам и событиям.

  • Константные и вычисляемые динамически права.

  • Контроль доступа на уровне колонок и строк.

• Отчёты в форматах Html и Excel.

• CRUD для таблиц БД “из коробки”.

• Поддержка мультиязычности в приложениях.

• Инструменты совместной разработки приложений.

Вместо заключения

Наша небольшая команда разработчиков-энтузиастов которые двигают все вперед: @lichnost, @VladWick, @NastiaDanchenko, @DaniilOrlov.

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

Проект живет здесь
Зеркало в github.com

Заинтересованные могут потестировать онлайн. Как это сделать описано в README проекта.

Любые комментарии/вопросы/пожелания приветствуются в комментариях, в issue gitlab.com или в личных сообщениях.

На этом все.
Hasta la vista!