Как мы делали formoza29.ru

[ermouth]

Когда я взялся за новый сайт Архангельской Формозы, – это было в начале ноября, – мне нужно было решить, на чём сфокусировать свои дизайнерские и организационно-инженерные скиллы. Вводные были примерно такие:

• до НГ надо сделать публичную бету с основным функционалом
• это должен быть Битрикс – пожелание заказчика
• есть база товаров, выгружаемая из 1С не последней версии, база актуальна – на ней работают офлайновые магазины
• база – это очень неравновесное дерево (см первые два уровня на старом сайте и попробуйте чёнить понять) с кучей проблем:
  • некоторые маловажные группы товаров находятся на самом верхнем уровне
  • некоторые важные группы распределены по нескольким веткам
  • другие важные группы закопаны очень глубоко (2-3 уровень вложенности)
  • логика вложений групп по большому счёту для покупателя совершенно неочевидна
• база не атрибутирована и не категоризирована – в каждой строке базы есть только описание и цена, никаких полей типа “призводитель” или там “объем памяти” или “диагональ”
• в описаниях полный разнобой и каша
• привести исходную базу к единообразным описаниям не получится – там в районе 9000 наименований, да и не ясно было, каким должно быть это единообразие
• атрибутировать руками базу не получится: 1С-бухгалтерия – это чудовищное интерфейсное говно, на задание одного атрибута товара нужно сделать в районе 10 кликов и выборов из дропдаунов, а атрибутов может быть несколько (диагональ там, цвет, то-сё)

Чтобы было понятно, какие там описания товаров в базе – вот три строчки со старого сайта:

Это причём из одного раздела. Насколько различаются описания из разных разделов, лучше не знать.

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

Как я это решал (многабукф, неподготовленному читателю будет сложно :) …

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

Первый подход к снаряду – попробовать переразбить базу при импорте из 1С на сайт – отвалился при самой грубой оценке трудозатрат.

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

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

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

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

прямо в браузере становится вот таким (тоже не ах, но куда читаемей):

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

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

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

Также часто воспринимается как ересь и отказ от человекопонятных урлов (у меня просто хэши, в гробу я видел урлы типа /catalog/aksessuari-dlya-planshetnikov/).

Ещё «ереси»:

• разработка проекта вообще без техзадания (я использую vision-based подход, “жирное” прототипирование и всю мощь русского языка как для описания, так и для управления)
• agile-подход с элементами scrum (без присущего скрам-подходу идиотизма типа митингов в фиксированное время, приколочнной частоты спринтов и тп)
• пользовательское бета-тестирование с публичной руганью недоработок
• доработки прямо на боевом сайте
• полное игнорирование seo- и “маркетинговых” подходов к структурированию контента.

Ну и так далее. Все эти ереси вместе сократили время разработки до 5 недель (с моей первоначальной пессимистичной оценки 4 месяца) и бюджет примерно раз в 10.

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

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

Такие вот пирожки. Остальное – дело техники и команды отличных инженеров.

Comments

[ermouth.livejournal.com]

бггг )