Григорий Ситнин

Дано: один разработчик и проект «с нуля».

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

Попытка решения

1. Фиксация требований и пожеланий заказчика (как внешнего, так и внутреннего). Составить список функций продукта (feature set). Описать зависимости между функциями. Для каждой функции определить критерии её завершения.

2. Фиксация видения. Записать произвольным текстом своё личное видение проекта, отразив все требования, зафиксированные на предыдущем этапе.

3. Составление плана вех (итераций). Определить трудоёмкость и ценность (score) каждой функции. Распределить функции по вехам, учитывая из зависимость.

4. Исполнение. Создание ветки версионного хранилища. Последовательно исполнение вех.

4.1. Реализация функции. Выполнить работы по производству конкретной функции. Функция считается реализованной, когда все критерии завершения выполнены.

4.2. Фиксация изменений. Примененить изменения в версионное хранилище, включая актуализацию дампа БД.

4.3. Рефлексия. Оценка и фиксация реальной трудоёмкости и проблем, возникших при работе над функцией.

4.4. Пересмотр плана разработки. Отмена или перенос функций (если требуется).

5. Фиксация вехи. Фиксация ветки версионного хранилища. При необходимости, склеивание ветки с главной (merge в trunk). Веха считается достигнутой при завершении всех функций этой вехи.

Чего забыл?

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

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

Посмотрите сами: методы запуска редакторов разных данных из БД одни и те же. Механизмы, которые реализуют проверку так же имеют одинаковый интерфейс. По крайней мере, могут иметь.

Теперь мы сократим схему до минимума. Пусть у нас будет один URL (скажем, /edit/{guid}/), который мапится на наш скрипт построения редактора. Так же создадим в БД таблицу objects с двумя полями — guid и class. В первое соберём все guid-ы, а второе заполним названиями классов. Я делал это примерно вот так:

INSERT INTO objects (guid, class)
SELECT guid, 'iteration' class FROM iterations UNION
SELECT guid, 'milestone' class FROM milestones UNION
SELECT guid, 'project' class FROM projects UNION
SELECT guid, 'task' class FROM tasks UNION
SELECT guid, 'user' class FROM users


После чего во всех таблицах, кроме самой objects я заменил первичные ключи по guid на простые индексы и связал их с таблицей objects, установив на удаление-изменение правило cascade. Конечно, для того чтобы положить новую запись в БД, придётся сначала создать запись в objects, однако это не страшно. Особенно в наш век транзакционных субд.

Дальше всё кристально просто: при обращении к нашему URL выделяется GUID редактируемого объекта, с помощью которого мы получаем класс сущности.

Каждому классу сущности соответствует smarty-шаблон с формой редактора и класс, умеющий проверять и сабмитить форму. Проверку я делаю с помощью ajax, который, если всё хорошо, уже дёргает сабмит.

Теперь остаётся сделать нужное количество шаблонов и классов-обработчиков для форм, а это единственное, что различается у редакторов сайта.

Небольшая ремарка: в БД все сущности у меня имеют первичный индекс в виде GUID-ов. Это мне нравится больше, хотя и не обязательно. Если у таблицы objects сделать составной первичный ключ из, скажем autoid сущностной таблицы и имени класса, то тоже будет работать. Но мне это кажется дурацкой идеей и без гуидов я бы до неё всё равно не додумался. =) К тому же, у GUID-ов есть ещё всякие вкусности.

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

Сначала делал по-старинке, используя голову, руки, формы и проверки. Некрасиво получалось.

Потом попробовал делать на ext-js. Красиво, но очень уж монструозно и методология большого фреймворка начала сильно влиять на код.

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

Теперь терзает мысль: а ведь наверняка есть фреймворки, которых я не знаю, предназначенные именно для такой работы — делать интерфейсы управления. Не идиотские конструкторы форм (да, в них есть автопроверки, но это не делает их хорошими), не интегрированные в универсайльные сайто-фреймворки типа Code Igniter-а. Именно фреймворки для разработки интерфейсов управления.

Ведь, если до сих пор нет, то надо такой сделать. А вы как думаете?

Если делать, то какие задачи он должен решать? Какую меру кастомизируемости должен содержать?