«Прежде чем написать первую строку кода, убедитесь, что законодатель уже не написал её за вас.»

Инвентаризация вам не это

Есть одна категория проектов, которую разработчики почему-то очень любят недооценивать.

Это не банковские системы. Не медицинские информационные комплексы. Даже не государственные порталы, где каждый второй запрос сопровождается молитвой и резервной копией. Это обычная… инвентаризация.

Слово настолько скучное, что хочется немедленно закрыть вкладку и пойти писать очередной менеджер задач. Кажется, будто вся предметная область сводится к одной таблице:

ID | Название | Кабинет | Ответственный

Пара кнопок «Добавить», «Удалить», «Изменить», зелёная галочка и можно идти пить чай.

К сожалению, законодательство с подобным оптимизмом категорически не согласно.

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

Именно здесь проходит довольно неприятная граница между «написал программу» и «разработал информационную систему».

Я никогда не был против использования искусственного интеллекта при разработке. Если инструмент позволяет быстрее написать код, замечательно. Проблема начинается немного раньше… …В тот момент, когда разработчик открывает IDE, не открыв Консультант Плюс (или любой другой аналог справочно-правовой системы в Вашей юрисдикции).

Можно бесконечно генерировать контроллеры, ORM-модели и REST API. Всё это будет работать. Пока не выяснится, что половина процессов противоречит приказам министерства финансов, другая половина не учитывает реальные сценарии работы организации, а оставшаяся часть просто не отвечает на главный вопрос:

зачем вообще существует эта система?

В случае АИС «Инвентарис» задача с самого начала формулировалась достаточно чётко: централизованный учёт оборудования, контроль его состояния, фиксация перемещений, привязка объектов к помещениям и ответственным лицам, а также формирование необходимой отчётности.

Заметьте одну интересную деталь!

Нигде не написано:

«Создать красивый сайт.»

Не написано:

«Использовать Flask.»

Не написано:

«Написать PostgreSQL-запросы.»

Потому что программирование является лишь способом реализации требований, а вовсе не их источником. Программирование не более чем навык, который может освоить практически каждый. И, если честно, в современном мире это далеко не самое ценное умение. Лучше будьте инженерами. Будьте великими разработчиками. Не становитесь людьми, которые умеют лишь «буковки печатать».

Я немного отвлёкся. Давайте вернёмся к теме грустной реальности (как будто до этого было весело)? Подводя итоги этого заголовка третьего уровня могу смело утверждать, что любой разработчик, который хотя бы однажды сталкивался с автоматизацией реальных процессов, довольно быстро обнаруживает неприятную истину.

Мы все подневольны.

Подневольны законодательству.

Подневольны внутренним регламентам организации.

Подневольны техническому заданию.

Подневольны ожиданиям заказчика.

И если хоть один из этих элементов проигнорировать, проект очень быстро окажется перед классическим выбором между двумя стульями. Причём оба обычно подписаны словами «переделать всё заново».

Pet Pet’ом

После статьи о «КОММУ» вполне закономерно возникает вопрос:

«Но ведь ты и раньше писал большие проекты. Почему здесь всё настолько серьёзно?»

Ответ довольно простой:

Потому что это уже не совсем pet-проект.

Не поймите неправильно. На самом деле «КОММУ» проходила тоже примерно такой же путь проектирования и бла бла бла, но… Во-первых, в той статье гораздо интереснее было рассказать про рефлексию дизайнера, а тут уже про «правила хорошего разработчика». Во-вторых, мнение кардинально не менялось: личные проекты являются лучшим способом чему-либо научиться. Более того, именно благодаря им вообще появилась большая часть моего опыта. Но между системой, которую ты пишешь для себя, и системой, которая моделирует реальные процессы организации, существует огромная разница.

В первом случае вполне можно позволить себе открыть PlantUML, набросать диаграмму вариантов использования, подумать пять минут и перейти непосредственно к реализации. Бога ради! Декомпозируй в голове. Никто не запрещает. Иногда это даже правильно.

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

Допустим, заказчик произносит всего одну фразу:

«Нам нужна система учёта оборудования.»

Рисунок 1. А ты хотел по простому?

ЧТО ТУТ СЛОЖНОГО? Пять минут работы! Сейчас быстренько нагенерируем что-нибудь в… Эм… GigaChat. Да ведь? А знаете, что Вы на самом деле должны были сделать? Как минимум задать следующие вопросы:

• Что именно считается оборудованием?
• Кто имеет право его регистрировать?
• Можно ли удалять записи? (НЕТ! НИКОГДА!)
• Что делать при списании?
• Кто подтверждает перемещение между кабинетами?
• Как долго хранится история?
• Какие роли существуют в системе?
• Какие данные являются критическими?
• На каком сервере всё будет работать?
• Требуется ли интеграция с LDAP?
• Нужно ли журналирование действий?
• Нужно ли резервное копирование?

Большая часть этих вопросов вообще никак не относится к программированию. Но именно они определяют, какой получится программа.

Да, ещё существуют Федеральный закон «О бухгалтерском учёте» № 402-ФЗ, приказ Минфина России № 204н, приказ Минфина России № 4н… И ещё целая пачка нормативно-правовых актов, КОТОРЫЕ ТЫ ДОЛЖЕН БЫЛ ПРОЧИТАТЬ ПЕРЕД ТЕМ, КАК ВООБЩЕ ОТКРЫТЬ ОКНО ВВОДА ЗАПРОСА К ИИ!

Закрыл.

Вкладку.

С ИИ.

Открывай справочно-правовую систему, действующую в твоей юрисдикции. Сначала разберись, что ты должен разработать. И только потом спрашивай у нейросети, как это реализовать.

По этой причине разработка «Инвентариса» начиналась вовсе не с написания базы данных.

Сначала появился бриф → Потом общая концепция → Затем техническое задание.

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

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

Почему? Потому что память человека удивительно плохо подходит для хранения проектов продолжительностью несколько месяцев. Давайте! Попробуйте через полгода вспомнить, почему в системе существует определённое ограничение. Почему именно такая модель данных. Почему пользователь не может удалить оборудование. Почему журналирование обязательно.

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

Давайте создавать

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

Нет, не о ГОСТах. О диаграммах.

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

Проектируем

Как бы странно это ни звучало, но написать код в подобных проектах зачастую оказывается проще, чем его спроектировать.

После появления технического задания появляется закономерное желание немедленно открыть IDE, создать первый маршрут Flask и начать героически писать SQL-запросы. Проблема лишь в том, что программа пока существует исключительно в голове разработчика, а минусы человеческой памяти были описаны приблизительно за 5 абзацев до этого. Помните? Нет? Ну так поэтому прежде чем появилась первая таблица MariaDB и первая HTML-страница, пришлось сделать то, что не любит практически каждый студент, увидевший слова IDEF0 впервые.

Рисовать диаграммы.

Нет, не потому что так захотел разработчик (он этого не хочет). И даже не потому что так требует очередной ГОСТ.

А потому что одна диаграмма способна ответить на вопросы, на которые потом пришлось бы отвечать несколькими сотнями строк кода.

Галерея 1: IDEF0 • Диаграмма вариантов использования • IDEF1X

Разумеется, подробно рассматривать каждую из них в рамках статьи было бы несколько жестоко по отношению к читателю. Если Вам действительно интересно разобраться в каждой стрелочке, подписи и обозначении, настоятельно рекомендую обратиться к пояснительной записке (часть персональных данных скрыта для соблюдения № 152-ФЗ). Там все проектные материалы приведены полностью вместе с описанием и спецификациями. Здесь же ограничимся кратким обзором того, какую задачу решала каждая из них.

Первой появилась IDEF0. Её задача максимально проста: ответить на вопрос «что вообще происходит внутри процесса регистрации оборудования?». На контекстной диаграмме отображается весь процесс целиком, после чего он последовательно декомпозируется на более мелкие операции. В моём случае регистрация оборудования перестала быть банальной записью новой строки в таблицу и превратилась в последовательность действий: проверка полномочий пользователя, получение исходных данных, проверка их корректности, обращение к базе данных и фиксация результата в журнале событий. Помимо самих действий модель также показывает входные данные, управляющие воздействия, механизмы выполнения и конечный результат процесса. Именно благодаря этому становится очевидно, что регистрация оборудования представляет собой полноценный бизнес-процесс, а не одну SQL-команду.

Галерея 2: Функциональная модель и её декомпозиции

После этого (ещё была вариантов использования, но она скучная даже для статьи) настало время IDEF1X. Пожалуй, именно эта диаграмма оказалась для меня наиболее интересной, поскольку она напрямую связывает требования предметной области с будущей структурой базы данных. Здесь уже появляются сущности, их атрибуты, первичные и внешние ключи, а также связи между таблицами. Центральным объектом модели становится оборудование, вокруг которого постепенно выстраиваются категории, помещения, поставщики, статусы, перемещения, обслуживание, пользователи и множество других сущностей.

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

Галерея 3. Диаграммы последовательностей: авторизация • загрузка оборудования • формирование отчёта

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

И только после этого можно было наконец открыть IDE и заняться тем, чего все обычно ожидают от разработчика. Написанием кода.

Пишем код

После завершения проектирования наступает тот самый этап, которого обычно все и ждут, услышав слово «разработка». Flask, SQL-запросы, маршруты, шаблоны, авторизация… Словом, начинается написание кода. Однако даже здесь предметная область продолжает диктовать свои правила, а многие архитектурные решения были приняты задолго до появления первого @app.route.

Одним из наиболее интересных решений стала версионность карточек оборудования. В большинстве простых CRUD-приложений изменение записи означает изменение строки в базе данных. В «Инвентарис» подобный подход оказался неприемлем. Если пользователь меняет помещение, статус или другую значимую характеристику оборудования, прежнее состояние не должно исчезнуть. Вместо этого система создаёт новую актуальную версию карточки, а предыдущая остаётся в базе данных в качестве архивной. Благодаря такому подходу сохраняется полная история изменений, а при возникновении спорной ситуации всегда можно восстановить последовательность действий пользователя. Более того, архивные карточки запрещено редактировать, что исключает возможность случайного изменения исторических данных. Ниже представлена функция, которая отвечает за создание новой версии оборудования. Не шедевр, но хоть что-то.

<... пропущен рендер при GET запросе ...>
    if request.method == "POST":
        try:
            # !Как видишь сначала мы проверяем на фальсификацию
            if not is_actual_equipment(item_id):
                flash("Редактирование архивной версии запрещено. Откройте актуальную запись.", "warning")
                return redirect(url_for("equipment.list_equipment"))

            # !Конечно же нельзя "перезаписать" на другое оборудование
            # !Либо пишем на него же, либо другой инвентарник
            data, errors = read_equipment_form()
            if data["inventory_number"] and db.fetch_all(
                "equipment_inventory_exists_for_other",
                data["inventory_number"],
                item_id,
            ):
                errors.append("Актуальное оборудование с таким инвентарным номером уже существует.")

            if errors:
                for error in errors:
                    flash(error, "warning")
                data["id"] = item_id
                return render_template("equipment_form.html", item=data, references=references, mode="edit")

            new_id = create_equipment_version(db, item_id, data)
            if not new_id:
                flash("Не удалось создать новую версию оборудования.", "danger")
                return redirect(url_for("equipment.view_equipment", item_id=item_id))

            flash("Создана новая версия карточки оборудования.", "success")
            return redirect(url_for("equipment.view_equipment", item_id=new_id))

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

Не менее важной частью проекта стала модель разграничения доступа ESR, разработанная специально для данной системы. Вместо десятков отдельных булевых флагов было решено использовать компактную трёхзначную строку, где каждая позиция соответствует одному из функциональных контуров приложения: Equipment, System и Reports. Каждая цифра принимает значение от 1 до 3, обозначая отсутствие доступа, чтение или запись соответственно. Благодаря этому права пользователя описываются всего тремя символами, а проверка доступа сводится к простому посимвольному сравнению строки пользователя со строкой, требуемой конкретным маршрутом. Например, роль 311 позволяет создавать и изменять оборудование, но не предоставляет доступа к системному администрированию и отчётам, тогда как 333 соответствует полному административному доступу. Давай посмотрим код?

# !Допустим нам нужно убедиться, что человек имеет доступ к чтению оборудованию
@equipment_bp.route("/<int:item_id>")
@require_permissions("211")
def view_equipment(item_id: int) -> Any:
    pass

# !Вызываем декоратор require_permissions и говорим ему, что как минимум нужно
# !иметь право чтения (2) в контуре оборудования (E)

<... Пропускаем скучный код и идём прямо к декоратору ...>

# !На всякий случай проверяем, что в БД не лезли
# !Нам интересна только схожесть с системой прав
def permissions_value(value: Any) -> str:
    raw = str(value or "").strip()
    if len(raw) != 3 or any(char not in "123" for char in raw):
        return "111"
    return raw

# !По очереди идём по каждому числу из необходимых и имеющихся
# !Какое-то число меньше? Тогда будет 403
def has_permissions(user_permissions: Any, required_permissions: str) -> bool:
    current = permissions_value(user_permissions)
    required = permissions_value(required_permissions)
    for current_digit, required_digit in zip(current, required):
        if int(current_digit) < int(required_digit):
            return False
    return True

# !Загружаем права из сессии (не переживай, они с БД сверяются)
def current_permissions() -> str:
    return permissions_value(session.get("permissions"))

# !Обёртка, которая всё соберёт
def can(required_permissions: str) -> bool:
    return has_permissions(current_permissions(), required_permissions)

# !Сам код декоратора. Он вызывает обёртку и отказывает если прав нет
def require_permissions(required_permissions: str) -> Callable[[Callable[..., Any]], Callable[..., Any]]:
    def decorator(view_func: Callable[..., Any]) -> Callable[..., Any]:
        @wraps(view_func)
        @login_required
        def wrapper(*args: Any, **kwargs: Any) -> Any:
            if not can(required_permissions):
                abort(403)
            return view_func(*args, **kwargs)

        return wrapper

    return decorator

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

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

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

Вместо вывода

На этом, пожалуй, стоит поставить точку. Это всё таки публицистическая статья, а не полноценный анализ, не так ли? «Инвентарис» оказался не просто дипломным проектом, а возможностью снова пройти весь путь разработки информационной системы: от изучения законодательства и проектирования до реализации, тестирования и подготовки документации.

Если Вам стало интересно узнать о проекте больше, ниже собраны материалы, которые могут оказаться полезными:

• GitHub-репозиторий — если интересно заглянуть в исходный код, посмотреть архитектурные решения или просто убедиться, что всё действительно работает.
• Руководство пользователя и администратора системы — если интересно посмотреть, как устроено взаимодействие с системой, какие сценарии работы поддерживаются и каким образом реализовано администрирование.
• Пояснительная записка к дипломному проекту — почти 140 страниц проектирования, анализа, диаграмм, технических решений и документации. Да, часть страниц украшена чёрными плашками. Как иначе соблюдать сохранность чужих персональных данных? Зато всё остальное осталось на месте, и, если вдруг захочется погрузиться в детали, материала там более чем достаточно.

Система коммуникации сотрудников «КОММУ» по своей сути была именно учебным проектом во всех возможных проявлениях этого понятия.

Началось всё в конце второго курса. Тогда в планах система ещё пафосно называлась СУБ, она же «Система управления бизнесом», но, не выдержав конкуренции с великим и ужасным «Битрикс24», решила слегка умерить амбиции и переквалифицироваться в систему коммуникации сотрудников.

Примерно тогда же был выбран первоначальный стек разработки, представленный в таблице 1.

Таблица 1. Первоначальный стек разработки «КОММУ»

Только недавно сдавшему экзамен по «Базам данных» мне казалось, что библиотеки объектно-реляционного отображения данных (ORM) являются «излишней тратой времени».

Да. Это была ужасная ошибка новичка.

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

Но об этом преступлении против здравого смысла поговорим позже.

Дизайн

С чего вообще может начать веб-разработчик?

Вопрос неоднозначный, ведь если идти по этапам, то МЫ начинаем с предпроектной стадии, затем переходим к проектированию, затем к реализации…

Ах! Восхитительная вещь этот жизненный цикл программного продукта! Сколько схем, сколько мнений, и все почему-то уверены, что именно ИХ каскадная / спиральная / капиталистическая модель есть истина в последней инстанции…

Вы так не думаете?

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

Сегодня же мы сразу перейдём к дизайну.

Точнее, Я буду разбирать дизайн, а Вы постараетесь не потерять нить рефлексии ученика, который спустя время вернулся к собственному проекту и теперь вынужден выяснять, почему он вообще сделал именно так.

Архаичный разработчик

Будучи ещё не до конца сформировавшимся специалистом в области дизайна, я совершил очередную непростительную для учебного проекта ошибку: не стал использовать Bootstrap.

Непростительный шаг! — скажете вы.

Ужасная трата времени для учебного проекта! — добьёте вы.

Юношеский максимализм и боязнь неизведанного, — отвечу я.

Чем именно закончилась эта замечательная попытка изобрести фронтенд самостоятельно, можно увидеть на изображениях 1–3.

Рисунок 1. Комму.Регламенты написанные на чистом CSS

Рисунок 2. Очередное творение CSS безумца. Страница авторизации Комму

Рисунок 3. Страница новостей в ужасном дизайне! Почему у новости есть «владелец файла» неизвестно. Логика была слишком сложной в то время…

К счастью, в тот момент я ещё не успел окончательно загрязнить репозиторий подобными творениями, поэтому ранний дизайн системы сохранился исключительно на скриншотах внутри проклятых файлов с названиями в духе «Курсова Работа Проектирование.финал.финал.docx».

Возможно, это и к лучшему. Некоторые вещи должны оставаться погребёнными в документах времён колледжа, чтобы случайный git blame однажды не уничтожил остатки самоуважения автора.

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

Как выяснилось, разработчики всё-таки не зря потратили десятилетия на создание готовых компонентов интерфейса.

Конвейерный девелопер

Рисунок 4. Наглядная демонстрация различий между древностью и конвейером

Пройдя все стадии принятия, было решено, что интерфейс Windows 98 (иначе я не могу назвать то стилистическое решение, которое когда-то было выбрано при написании нативного CSS) всё-таки устарел примерно в 1999 году. Ну, на крайняк, в 2000-м.

Следовательно, великую «КОММУ» необходимо было переписать с использованием современных фреймворков, коих запертые в подвалах программисты за прошедшие годы наплодили вагон и ещё примерно две сотни тележек.

В качестве оного был выбран Bootstrap, на который как раз была ориентирована учебная программа. Решение не самое оригинальное, зато теперь не требовалось собственноручно объяснять каждому <button>, как именно ему следует выглядеть. С примером Bootstrap интерфейса можно на рисунке 5 и на официальном сайте в разделе Examples→Snippets.

Рисунок 5. Наглядный пример того как выглядит типичный Bootstrap интерфейс

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

Люди (не смотря на то, что это слово не является сказуемым я бы подчеркнул его двумя палочками, но великий WordPress не позволяет ;-;) обладают удивительно типичными паттернами поведения. Благодаря им пользователь зачастую понимает назначение элемента ещё до того, как прочитает написанный на нём текст.

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

Например, кнопки:

Даже если убрать половину подписей, общий смысл остаётся довольно предсказуемым. Яркая основная кнопка привлекает внимание и обозначает главное действие. Вторичная старается не мешаться под ногами. Красная недвусмысленно намекает, что после нажатия может произойти нечто, о чём пользователь через три секунды напишет в техническую поддержку.

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

Булочка, сосиска, булочка

Другой великолепный результат многолетней дрессировки пользователей — бургер-меню.

Булочка. Сосиска. Булочка.

Три горизонтальные полоски сами по себе не имеют никакого врождённого значения. Однако за годы существования мобильных интерфейсов пользователи привыкли: увидел три полоски где-нибудь в верхнем углу — скорее всего, там меню.

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

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

Конечно, существуют региональные и культурные различия. В некоторых регионах планеты Земля, особенно в азиатских странах вроде Японии и Китая, исторически сформировались заметно отличающиеся подходы к плотности интерфейсов, навигации и количеству одновременно отображаемой информации. Поэтому универсального «психологически правильного интерфейса для всего человечества» не существует.

Но внутри конкретной аудитории знакомые паттерны всё равно работают. Если пользователь тысячу раз видел крестик как «закрыть», корзину как «удалить», шестерёнку как «настройки», а бургер как «меню», заставлять его на тысяча первый раз разгадывать авторскую метафору обычно бессмысленно.

Ух! Это было восхитительное мини-эссе, не правда ли?

А я, кажется, знаю, что вы теперь хотите сделать.

НЕТ! НЕ ЗАКРЫВАЙТЕ САЙТ!

Я не об этом.

Я просто хотел пошутить, что на этом сайте (великий и прекрасный r.zezh.ru) меню сделано не в виде бургера, а в виде плюсика.

Да.

Действительно.

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

От теории к практике

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

Для начала предлагаю ещё раз взглянуть на то, с чем мы имели дело изначально. Можете снова посмотреть на Рисунок 3.

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

Слева располагалось основное меню системы, сверху — логотип, строка поиска и элементы управления учётной записью, а всё оставшееся пространство отдавалось непосредственно содержимому страницы. Поэтому при переходе на Bootstrap я не стал сносить всё до фундамента исключительно ради возможности торжественно назвать произошедшее редизайном.

Эта раскладка сохранилась.

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

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

Изменять требовалось не столько расположение, сколько визуальную иерархию элементов внутри него.

Рисунок 6. Обновлённый интерфейс просмотра новости

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

В обновлённой версии появляется нормальная визуальная иерархия.

Заголовок новости крупнее обычного текста. Сама новость находится в отдельном визуальном блоке. Информация об авторе вынесена в собственную карточку. Основное действие «Вернуться на главную» выделено синим цветом, тогда как второстепенное «Вернуться назад» остаётся серым.

То есть интерфейс начал сообщать пользователю не только что здесь находится, но и насколько это важно.

Это небольшая разница на уровне CSS и огромная на уровне восприятия.

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

Рисунок 7. Интерфейс просмотра содержимого файла

Та же логика используется и на странице файла. Имя файла, отправитель и дата собраны в одном информационном блоке, после которого сразу расположены доступные действия.

Причём действия снова различаются визуально: «Скачать файл» является основным и поэтому выделено синим, а переход в мессенджер и возврат на главную являются вспомогательными и не пытаются перетянуть внимание на себя.

Отдельно помогают иконки. Стрелка загрузки, сообщение и домик позволяют распознать назначение кнопок ещё до чтения текста. Разумеется, подписи всё равно оставлены, потому что превращать корпоративную систему в экзамен «угадайте значение пиктограммы» никто не собирался.

Но лучше всего преимущества новой системы компонентов видны там, где интерфейс становится действительно сложным.

Рисунок 8. Интерфейс мессенджера «КОММУ»

Мессенджер одновременно содержит список чатов, текущую переписку, участников, сообщения, вложения и поле ввода. В старой стилистике всё это довольно быстро превратилось бы в братскую могилу серых прямоугольников.

Здесь же каждая область имеет понятную функцию и своё место.

Список диалогов закономерно находится слева, текущая переписка занимает большую центральную область, информация о выбранном чате и его участниках вынесена вправо и может быть скрыта нажатием на информационную кнопку i. Собственные сообщения выделены синим и прижаты к правой стороне, благодаря чему переписку можно визуально разделить на «я» и «остальные», даже практически не читая её.

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

И вот здесь проявляется главное преимущество перехода на готовый фреймворк.

Bootstrap не сделал интерфейс хорошим автоматически. Если достаточно постараться, отвратительный интерфейс можно написать на чём угодно, и люди ежедневно героически это доказывают. Я не шучу! Есть целая ветка Reddit, посвящённая этому, и мини-игра под названием User Inyerface за авторством бельгийской студии Bagaar. Кстати, советую поиграть, если не хотите заставлять пользователей страдать. А если не поиграете, есть второй путь: можете, как я, самостоятельно разработать говно из Windows 98, посмотреть на него спустя год и уже на собственном опыте понять, зачем специалисты последние лет тридцать изучали UX и его психологию. Тоже работает, но первый вариант несколько дешевле.

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

И именно это, пожалуй, было главным результатом редизайна. Не красивые кнопочки. Не модные скругления. И даже не избавление от эстетики Windows 98.

Пользователю наконец перестали мешать пользоваться системой.

Помимо кнопок?

Интересное название главы, не правда ли? Интрига, поиск скрытого смысла автора, попытка понять, что же он хотел этим сказать…

Нет. Этого не будет.

Увы и ах, но мы переходим к той части проекта, которую мне так и не удалось отрефлексировать в полной мере. Почему? Потому что принцип «не мешай пользователю пользоваться» в моей системе координат почему-то оказался значительно выше принципа «не мешай системе быстродействовать».

Чем это закончилось?

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

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

База данных

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

Это была ошибка. Ужасная ошибка.

Думаю, стоит начать с малого. Юные разработчики! Прильните к экрану и проанализируйте следующий фрагмент:

CREATE TABLE `employees` (
  `EmployeeID` int(11) NOT NULL,
  `UserLogin` varchar(100) NOT NULL COMMENT 'Логин ЛК сотрудника',
  `UserPassword` varchar(100) NOT NULL COMMENT 'Пароль ЛК сотрудника',
  `FirstName` varchar(100) NOT NULL COMMENT 'Имя сотрудника',
  `LastName` varchar(100) NOT NULL COMMENT 'Фамилия сотрудника',
  `PositionID` int(11) NOT NULL COMMENT 'Идентификатор роли, к которой относится сотрудник',
  `ManagerID` int(11) DEFAULT NULL COMMENT 'За каким менаджером закреплен сотрудник?',
  `MobileNumber` varchar(15) NOT NULL COMMENT 'Мобильный телефон сотрудника',
  `CorporateNumber` varchar(15) NOT NULL COMMENT 'Корпоративный номер сотрудника',
  `BirthDate` date NOT NULL COMMENT 'День рождения сотрудника',
  `PhotoLastUpdated` timestamp NULL DEFAULT current_timestamp(),
  `AboutMe` text DEFAULT NULL COMMENT 'Сотрудник пишет что-то о себе',
  `StartDate` date NOT NULL COMMENT 'Дата создания личного кабинета',
  `Photo` longblob DEFAULT NULL COMMENT 'Содержимое изображения',
  `IsDismissed` tinyint(1) NOT NULL DEFAULT 0
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

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

Но особенно прекрасна строка Photo с типом данных LONGBLOB. Да, изображение пользователя хранится прямо в основной таблице сотрудников. Решение не является запрещённым древними законами SQL и в отдельных системах вполне оправданно, но в данном проекте оно лишь раздувало таблицу и усложняло работу с данными там, где можно было хранить файл отдельно, оставив базе его идентификатор или путь.

И это, к сожалению, не единичный приступ архитектурного вдохновения. Рассмотрим, например, устройство мессенджера:

CREATE TABLE `chatmember` (
  `MemberID` int(11) NOT NULL COMMENT 'Уникальный код участника',
  `EmployeesID` int(11) NOT NULL COMMENT 'Идентификатор пользователя',
  `ChatID` int(11) NOT NULL COMMENT 'Идентификатор чата'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

CREATE TABLE `chats` (
  `ChatID` int(11) NOT NULL COMMENT 'Уникальный идентификатор чата',
  `ChatPreview` mediumblob DEFAULT NULL COMMENT 'Иконка чата',
  `ChatName` tinytext NOT NULL COMMENT 'Имя чата'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

CREATE TABLE `message` (
  `MessageID` int(11) NOT NULL COMMENT 'Уникалльный код сообщения',
  `ChatID` int(11) NOT NULL COMMENT 'Идентификатор чата',
  `SenderID` int(11) NOT NULL COMMENT 'Идентификатор пользователя-отправителя',
  `SendDate` timestamp NULL DEFAULT NULL COMMENT 'Дата отправки',
  `ContentType` int(11) NOT NULL COMMENT 'Тип отправляемого контента',
  `IsHidden` tinyint(1) NOT NULL DEFAULT 0,
  `ReplyToMessageID` int(11) DEFAULT NULL COMMENT 'В ответ на определённое сообщение',
  `ProcessingCompleted` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'Хранит состояние обработки сообщения на сервере',
  `ProcessingHEXCode` varchar(16) NOT NULL COMMENT 'Уникальный код обработки, существует только во время этапа обработки сообщения'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

CREATE TABLE `messagecontenttype` (
  `TypeID` int(11) NOT NULL COMMENT 'Уникальный код типа сообщений',
  `Name` tinytext NOT NULL COMMENT 'Кодовое название типа сообщения. Нужно для правильной генерации внешнего вида'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

CREATE TABLE `messagewithfile` (
  `FileID` int(11) NOT NULL COMMENT 'Идентификатор файла',
  `File` longblob NOT NULL COMMENT 'Содержимое файла',
  `FileName` tinytext NOT NULL COMMENT 'Имя файла',
  `MessageID` int(11) NOT NULL COMMENT 'Идентификатор сообщения, к которому прикреплён файл'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

Помимо гениальных комментариев вроде «Нужно для правильной генерации внешнего вида», здесь можно заметить ещё одну характерную особенность архитектуры: это BLOB на BLOB’е и BLOB’ом погоняет. Иконка чата? MEDIUMBLOB. Прикреплённый файл? LONGBLOB. Фотография сотрудника из предыдущего примера? Разумеется, тоже LONGBLOB. Если данные существуют в виде последовательности байтов, значит, по мнению тогдашнего меня, им самое место непосредственно в MariaDB.

Впрочем, гораздо интереснее таблица message. Поскольку логика мессенджера и без того казалась нам недостаточно сложной (см. рисунок 3 на нём отчётливо видны проблемы с разумностью), в ней существуют замечательные поля ProcessingCompleted и ProcessingHEXCode. Они обслуживали отдельный механизм отслеживания создаваемого сообщения и были нужны исключительно потому, что я не знал о существовании lastrowid и вместо получения идентификатора только что вставленной записи построил вокруг проблемы собственную систему.

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

Слава богу, мне уже не придётся переписывать этот проект.

Если после увиденного у Вас всё ещё осталось нездоровое желание подробнее ознакомиться с базой данных «КОММУ», ниже я прикреплю PDF-документ со словарём данных и диаграммой «сущность–связь». Там подобных решений значительно больше.

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

Что это было?

Если подводить итог, то великая «КОММУ» была совсем не плохим учебным проектом. Именно с неё начался тяжкий и долгий путь к тому, что видите Вы сейчас.

Именно после неё я начал понимать, что такое айдентика, как работает психология пользователя и почему бизнес-система почти всегда синяя…

Что? Вам стало интересно, почему синяя?

Нет, не стало?

Так или иначе, позже в блоге появится отдельная статья, целиком и полностью посвящённая реалиям современной айдентики. Там и разберёмся, почему половина корпоративного мира однажды посмотрела на синий цвет и коллективно решила: «Да. Вот так выглядит доверие».

«КОММУ» действительно умела многое, и я горжусь этим проектом. Со всеми её LONGBLOB, странными архитектурными решениями, самодельными механизмами обработки сообщений и интерфейсом родом из прошлого тысячелетия.

Для парня, который только начинал по-настоящему программировать, она стала идеальным полигоном для проверки собственных сил. Здесь можно было ошибаться, переделывать, изобретать уже изобретённое, не знать о существовании lastrowid, а через несколько лет открыть исходный код и наконец понять, почему некоторые вещи лучше было не изобретать вовсе.

И всё же Ваш покорный автор справился.

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

Спасибо за внимание. На странице блога Вы можете почитать и другие размышления на свободные темы.