Примат — советчик: Если в приложении должны быть пользователи — начинайте разработку приложения именно с пользователей!
апреля 22, 2012 | Published in Примат - советчик | 14 Comments
Primate say: «Если в приложении должны быть пользователи — начинайте разработку приложения именно с пользователей!»
Зачем? Почему?
Не раз сталкивался с разработкой приложений, в которых имелась модель User и регистрация пользователей. То есть это были не закрытые приложения с одним или несколькими администраторами, а приложения в которых могут регистрироваться различные пользователи, приложения, в которых у пользователей есть роли и права. Как правило, я всегда начинал работу над тем, что называется основным функционалом приложения, а пользователей пытался добавить где-то в средине процесса разработки. У меня всегда были сомнения по поводу правильности такого подхода, но привычка не давала мне возможности пересмотреть подход к разработке.
Относительно недавно изучая несколько различных проектов, в которых имелась более-менее аналогичная модель User я заметил, что разработка части приложения отвечающей за пользователей происходила в самом начале, а остальной функционал снежным комом наворачивался поверх пользователей. Попробовав этот подход в недавнем своем проекте aka стартапе я убедился, что такой подход является более эффективным. Построение приложения вокруг пользовательской модели является более удобным и правильным.
Поскольку все дейсвия в приложении выполняются не сами по себе, а от имени пользователя, то вполне логично, что сначала должен быть Большой Взрыв пользователь, а затем уже перечень его возможностей. В коде, где пользователям уделена центральная роль у вас значительно меньше вероятность запутаться с распределением привилегий, при этом объявление прав на выполнение определенного действия должно предшествовать собственно реализации самого действия. Создание пользователей раньше остального функционала больше соответствует BDD и облегчает разработку по такому принципу; в случае, когда User создается после некоторого набора функций приложения, у вас скорее всего возникнет необходимость переписывать спецификации для этих функций.
апреля 22, 2012 at 17:26 (#)
А что за стартап?)
апреля 22, 2012 at 17:47 (#)
Конструктор несложных электронных магазинов.
апреля 22, 2012 at 17:50 (#)
Круто
апреля 22, 2012 at 17:50 (#)
Скоро во вконтакте выложу первые скрины, но он еще сильно сырой.
апреля 23, 2012 at 08:51 (#)
Давай лучше в G+, вконтакте уже прошлый век
апреля 23, 2012 at 13:17 (#)
Мне G+ и Facebook не нравятся, а Вконтакт — достаточно удобен для меня. Кроме того во Вконтакте группа 250 человек и у меня много подписчиков, а в G+ почти никого.
апреля 23, 2012 at 13:46 (#)
Владимир, а на CMS свою забил?
апреля 23, 2012 at 19:43 (#)
Пока еще нет =). Время от времени делаю коммиты. Ядро более-менее готово.
апреля 23, 2012 at 20:45 (#)
Ты сделай страницу в G+ для RubyDev, во вконтакте напиши ссылку, и посмотришь сколько будет подписчиков
апреля 23, 2012 at 20:56 (#)
Не не не, не завязывай с cms… CMS будет классной вообще…
апреля 23, 2012 at 23:06 (#)
В этом плане очень интересно почитать блог некого Ayende Rahien из мира .NET. Мужик впринципе известный и знаковый в определённых кругах. Так вот, в некой серии постов он как раз говорит и о проблеме User-ов и вообще доменых сущностей. То есть если мы решаем что собираемся вести проект по принципу DDD или какой то вариации на тему, так надо слушать domain experts. Ибо никто лучше самого бизнеса не знает как имено он устроен и что ему надо. Например бывает так, что сущность User не единственная связанная с пользователями в системе. Очень может быть, что бизнесу также важна и сущность Visitor, а не только зарегестрированные пользователи. Или например сущность Address, может быть многообразной. Ибо у одного пользователя могут быть разные адреса. Бизнес адрес, адрес для билинга, адрес дочернего филиала и т.д. Ещё помню он предлагал как некий концепт, разделить User-ов и Аккаунт-ы. Потому что у одного пользователя могут разные аккаунты, с разными правами. Если например он пользуется услугами субподрядчика. Короче говоря пользователи это очень важно и глубже чем может показаться вначале разработки, но не важнее бизнес правил, бизнес логики, которая и определяет что есть важное.
апреля 24, 2012 at 17:21 (#)
хм… была подобная идея (про конструктор магазинов), даже накидал структуру приложения, но пока нет свободного времени довести до ума
апреля 25, 2012 at 01:38 (#)
А можно глупый вопрос, что делать конструктор должен ? в плане генерации кода , зачем , когда можно предпочеасть конфигурацию над генерацией ?
Ну вот с точки зрения пользователя, скажите, чем ваш конструктор лучше чем spree к примеру, или тонна других магазинов которые настраиваются по времени столько же, сколько конфигурировать генерацию кода (т.е. конфигурация и там и там) ?
может стоит влиться в открытый проект и на его базе делать улучшения ?
апреля 25, 2012 at 13:53 (#)
Валентин, spree — это опенсорс движок для магазинов. Человек берет несколько тысяч $ и нанимает программиста,чтобы тот ему все установил и настроил, что-то дописал. Мой проект больше похож на Shopify, простой человек регистрируется и за 5 минут полностью настраивает свой магазин: указывает название, слоган, тип продукции, выбирает тему оформления, разрешает или запрещает комментирование товаров и т.д. Разумеется, для крупных магазинов такое решение не годится, а вот для небольших — очень даже подходит. А самое главное — дешевизна. Не нужно сразу вливать кучу денег, достаточно каждый месяц платить абонплату 5-10$ или сразу заплатить за год.