E-Commerce. Делаем интернет-магазин без шаблонов в современных реалиях. Часть 1. Разработка сайта и паралелльная работа с заказчиком
Всем привет. Спасибо тем, кто на меня подписался - надеюсь, эта информация будет полезной или интересной. В крайнем случае в середине поста есть фотка котика, можно промотать до неё и закрыть длиннопост :3
Итак, во вступлении я вкратце рассказал, что планирую сделать в ближайший месяц и с чем точно придётся столкнуться. Проблем, несомненно, будет больше и о них будут постцы или комменты.
Помимо общения с заказчиком, вам предстоит ещё и сама разработка. Я не буду рекламировать или упоминать отдельно взятые сайты, которые использую при разработке - аналитику можно оставить для другого раза. Разработка без проектирования стопроцентно скатывается в стыд и затраты. Вам будет стыдно смотреть на то, что было написано на коленке, а исправлять это придётся, иногда испытывая ещё большее чувство стыда. Но при этом попытка создать обобщенный абстрактный продукт может вылиться в кучу проблем - от невозможности создания сверхтонкой абстракции с точки зрения программирования до сложности в настройки абстракции для конкретной имплементации. Поэтому, как обычно, нужно искать грань.
Начнём, пожалуй, с общения с заказчиком. Он должен либо чем-то заниматься, либо быть довольным. Можно сразу оба пункта, но это сложнее. В моём случае, сайт - это расширение возможностей заказчика, и он уже чем-то занят. Плюс существуют типичные задачи, которые должен решить заказчик:
1. Правовая сторона вопроса - контакты, документация, налоговая - выбирать на любой вкус. Главное не закидывать требованиями сразу;
2. Функционал - это нужно решать сразу и держать заказчика как можно дальше от описания того, что вы МОЖЕТЕ сделать. Только необходимый минимум, который Вы точно сможете сделать. К концу проекта всё равно обрастёт хотелками;
3. Сроки и бюджет - помимо затрат на вас, заказчик должен быть в курсе трат на содержание продукта. Если вы не берете на себя фул стек содержания (сертификаты/хостинг/поддержка/гарантийка/железо), то уведомите заказчика о масштабах потребления. Если вы делаете проект, за который вам хочется получить 300-500к рублей, а на его содержание в год будет уходить больше 100к, есть высокий шанс получить отказ, если вы не обладаете уровнем красноречия 100.
Пунктов гораздо больше, но выкидывать их все сразу, как я уже говорил, не стоит - тем не менее в голове (или на бумаге) всё это должно присутствовать. О том, как обстоит общение с заказчиком - согласовывать только вам. Главное понимать - всегда существует такой заказчик и такой объем работ, который лучше не брать. Даже если вы уже начали - иногда лучше отказаться. Историй таких проектов и заказчиков тьма - может не повезти и вам.
Поздравляю или сожалею, если на этом этапе вы не уснули, как котик. Дальше перейдем к сайту.
Разработка сайта ... Я постараюсь не вдаваться в технические детали, выбор языка, синтаксис и прочее - это не относится к этой части и, в принципе, существует для любого актуального технического решения. На этом этапе мы будем делать сайт, который будет отвечать требованиям произвольного интернет-магазина. Составление ТЗ без формального согласования занимает не очень много времени, и оно прежде всего нужно нам самим.
При первичном обсуждении и планировании, у меня получилось порядка 30-60 пунктов для реализации. И это просто для функционирования интернет-магазина с более-менее формальной точки зрения.
Я хотел выложить их сюда, но это получается какое-то дикое количество текста, читать который - можно заснуть быстрее кота. Если интересен стек или формализация - можно написать в комментарии.
Основные пункты сводятся к описанию потоков данных - что может пользователь, что он и где видит, как хранятся данные; что может контент-менеджер, что такое роли и как администратор может их выдавать.
Ещё стоит понимать, что при разработке сайта желательно иметь возможность предоставления прототипа заказчику. Можно обойтись и без этого, если проект маленький или если вы уверены в своих силах. Ну и, конечно, если вы согласовали это с заказчиком.
В противном случае, у вас под рукой всегда должен быть работающий сайт. Будет лучше, если данные будут реальными и весь функционал будет совпадать с конечным, а не заткнут заглушками в виде фейковых данных, сертификатов или псевдобд.
Первая проблема - это в количестве данных для контент-менеджера. Совершенно очевидно, что пользователь не сможет выйти за рамки просмотра данных (за исключением формирования количества товара в заказе), поэтому нужно создавать рамки для редактирования. Я решил ограничиться 10 фотографиями до 20 мб на каждый представленный товар. Плюс немного нужно поиграться с несколькими экземплярами изображениями - не стоит загружать на страницу до 200 мб, если пользователь сам этого не захочет.
Вторая проблема - масштабируемость и производительность. У данного заказчика количество категоризированных товаров не превышает 200 единиц категорию, но всё же следует сразу предусмотреть выгрузку данных пользователю. Конкретный пример - отображение товаров в категории. При загрузке с сервера всех 200 единиц, пользователь может быть недоволен. Некоторые магазины выгружают все товары и делают страничный вывод уже на клиенте - мы не такие - постраничность должна поддерживаться системой на самом базовом уровне, как и фильтрация.
Ф - Фильтрация. Это отдельная песня и тому, что я понимаю под ней, будет посвящена отдельная часть, так как поиск по неспецифичным данным должен быть максимально абстрактным, если вы не хотите превратить систему в набор костылей.
Вторую проблему можно решить ещё на уровне написания базовых классов, а вот для решения первой проблемы необходимо понимать, что и как будет работать. И оповестить заказчика. Если заказчик хочет загружать 5000 изображений одной единицы товара - необходимо будет решить эту задачу. Ну, и, конечно же, не выводом 5000 изображений сразу.
Котик всё ещё спит, поэтому фотография будет уже в следующем посте.