Какой должна быть админка
Административное приложение (админка) – это отдельная самостоятельная программная часть, которая служит для управления поведением и настройками приложения. АП встраивается во внутрь приложения и является его неотъемлемой частью.
Технология. Серверные продукты чаще всего имеют админку в своём составе. Она выполняется по клиент-серверной технологии. Чаще всего используют framework (в хорошем случае), но иногда и без него (в не очень хорошем случае).
Разработка и дизайн. Все АП разрабатываются одновременно с основным приложением с самого его начала. Это означает, что в основе (в ядре программы) заложены технологии и дизайн, применяемые в начале разработки приложения. Иногда - очень старые.
Использование. Предполагается, что АП используют опытные операторы или администраторы систем. АП разрабатываются в соответствии с этим предположением. Следовательно, может показаться, что для данных приложений не требуется особый интерфейс. Однако это заблуждение. Удобство пользования и внятный, интуитивный интерфейс всегда должны быть на первом месте.
Очень часто АП, написанные кое как, обладают недостатками, примеры которых написаны ниже.
АП могут дорабатываться и исправляться только теми отдельными программистами, которые к ним «привязаны». Невозможно разобраться в программе во внятные сроки. Это происходит потому, что не используются базовые принципы программирования. Вместо этого присутствуют: отказ от использования ООП, использование глобальных функций и глобальных переменных в скриптах, отсутствие определённой структуры и архитектуры. Для доказательства достаточно открыть любой крупный файл программы.
Слишком большие файлы. Огромные, перегруженные функции.
Огромное количество предупреждений, а также ошибки, которые выдаются современной IDE при открытии файлов.
Смешивание в одном файле разных языков и стилей CSS. Это приводит к путанице и неразберихе. Необходимо отделять логику от вёрстки, вёрстку от стилей, backend от frontend. Хороший пример, который попадался мне на глаза, это файл options.php. Можно предположить по названию, что здесь происходит подготовка или сбор настроек, но вместо этого здесь:
a. Подключение скриптов PHP и JavaScript.
b. Аварийный выход.
c. Вывод вёрстки.
d. Выполнение JavaScript.Огромное количество комментариев, часто устаревших и не соответствующих действительности. Перенасыщение бессмысленными комментариями. В серийном продукте не должно быть закоментированного кода, произведённого для частных модификаций. Пример бессмысленного комментария:
// имя пользователя
$username = $_SESSION['username'];Настройки, данные и алгоритмы разбросаны самым неожиданным образом по разным файлам, логика отсутствует.
Дорабатывать или перерабатывать отдельные части АП, переводить их на современные технологии слишком трудозатратно, а потому не имеет смысла.
В современном программировании приняты следующие предельные объёмы для файлов, классов и методов:
Длина файла не более 3000 строк.
Длина класса не более 1000 строк.
Длина функции не более 50 строк.Возможно превышение, но это всегда сигнализирует о необходимости декомпозиции, и, возможно, смены архитектурных решений в программе.
Следует отметить, что не все ошибки и предупреждения, которые выдаёт IDE, влияют на выполнение программы. Множество слабых предупреждений сигнализируют о потенциальных проблемах, которые могут себя проявить в определённых условиях. Опечатки обозначают литералы, слова и выражения, которые IDE не распознала ни на русском, ни на английском языке с учётом правил их написания. Например, «тАкI_e».
Далее приведу рекомендации что делать в таких случаях.
Следует полностью переписать АП на современных технологиях. Структуры хранения конфигураций оставить прежними.
Принять архитектуру, доказавшую временем свою состоятельность.
Передумать дизайн АП, если он местами нелогичен и без документации невозможно разобраться. Дизайн должен быть единым на все АП в рамках одной системы, предельно простым и понятным даже неопытному пользователю.
Разработать внятную авторизацию.
На период разработки АП на новом дизайне приостановить внедрение новых возможностей в существующие АП, допускать только исправление ошибок.
Назначить ответственных за приёмку кода. Ответственные должны следить за соблюдением норм и правил программирования.
Внедрить и требовать соблюдения принципа code review, по которому программа не принимается до тех пор, пока её не одобрят другие программисты и дизайнер.
Уйти от практики изоляции программистов на отдельных проектах. Это означает, что в каждом проекте должно быть минимум несколько программистов, достаточно глубоко погружённых в него.
Принципы, которые должны быть учтены.
Вход в АП должен быть закрыт авторизацией.
Удобное АП очень важно; сложное, запутанное, плохо продуманное АП увеличивает вероятность ошибок во время работы; для тестирования простоты интерфейса нужно привлекать неопытного пользователя.
Структура наполнения должна быть иерархической – от крупных логических блоков до единичных; в любой момент времени должна быть возможность перейти на любой верхний логический уровень; предусмотреть навигацию.
Пользователь должен иметь возможность управлять только одной логической единицей в один момент времени; при этом весь остальной интерфейс должен быть скрыт.
Предусмотреть ограничения доступа к разным логическим единицам АП; единицы, требующие большего доступа, чем есть у данного пользователя, необходимо отображать недоступными или скрывать.
Настройки должны сохраняться после любой манипуляции.
Необходимо обеспечить откат к предыдущим версиям настроек приложения прямо в интерфейсе АП (возможно, предусмотреть точки сохранения).
Недопустимо предположение о ручной манипуляции файлами с настройками; АП не должна создавать файлы наподобие .bak, .old, которые предполагается вручную восстанавливать.
Изменения настроек через интерфейс обязательно должны фиксироваться с указанием автора изменения.
Лёгкая ненавязчивая анимация упрощает восприятие, избыточная – отвлекает; переключение разделов и появление всплывающих модальных окон можно анимировать; формы можно плавно раскрывать; удаляемые элементы могут плавно исчезать; это добавляет осмысленности действиям.
Ключевые элементы должны иметь всплывающие подсказки, поля ввода – заполнители (placeholders).
Кнопки должны быть крупными и заметными, выделенными соответствующими цветами.
Особыми преимуществами обладает модульная система, наибольшее преимущество которой состоит в декомпозиции и возможности повторного использования в других приложениях. Пример такой системы:
модульная система (описана ниже);
автоподгрузка модулей;
возможность наследования;
соблюдены PSR-стандарты;
покрыт тестами;
содержит встроенную документацию;
адаптирован под разные web-сервера;
имеется чёткая структура, разделение программы и конфигурации;
гибкое логирование;
локализация;
подготовка сборки для выпуска.
Модульная система. Для разработки приложения объявляются модули, расширяющие общие (native), или создаются новые. Далее они инициализируются по необходимости, используя технологию автоматической подгрузки классов.
Надеюсь, Вы сможете почерпнуть некоторую пользу из этой выкладки и что-нибудь оказалось для Вас здесь новым или натолкнуло на новые мысли и идеи.