-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Энумсрач
- Автор темы The employer
- Дата начала
The employer
Новичок
А о чем? Тут апеллируют к тому, что серьезные проекты требуют enum'ов в половине таблиц.
Или я как-то не так понимаю серьезность, или давайте уже поговорим в том числе о документообороте.
Например, о такой прикольной задаче как передача прав на подписание документов в случае отсутствия людей на рабочем месте (по причине болезней, командировок. отпусков - и это еще не говоря о ситуации с равными прравами подписи).
Знаю, кто ж этот баян не знает. Но тут же ссылаются на действительно сложные задачи, выходящие далеко за рамки детской пеесочницы или уютной клетки в зоопарке.
В противном случае навороты (как и "оберточки под mysql") не нужны - три с половиной запроса можно без всего этого писать, нет?
Зависит от размеров switch в твоем коде (или размеров бороды из if...else if...else if...).
Борьба идет за то, чтобы из таких вот switch убрать всю бизнес-специфичную логику, оставить только интерпретатор некоего языка (или, в других терминах, реализацию некоего конечного автомата, с переходами под воздействием входных данных). Вот в чем упрощение.
То ли ты включаешь логику расчета возможных действий в код, в виде if или switch, и потом при всех изменениях логики вносишь изменения в код (рискуя при этом возникновением неочевидных "дыр" в логике - например, случайным предоставлением лишних возможностей тем, кто таких возможностей иметь не дложен). То ли ты описываешь правила взаимодействия объектов и правила расчета полномочий - один раз. И дальше в рамках этого "метаязыка" описываешь реальные взаимоотношения объектов предметной области.
Слушай, ну общее место уже давно. Мировой тренд. И оно не пустом месте же родилось.
Критерий? Для чего, извини? Это вопрос скорее дисциплины разработки - как использование системы контроля версий или багтрекера. Нет критерия. который можно механистически применить и сказать: "'этому проекту багтрекер не требуется". Скорее, это вопрос личных ощущений и зрелости исполнителя.
-~{}~ 26.07.09 19:36:
Что кто пишет - это индивидуальный выбор. К примеру, у нас есть несколько внедренных систем управления деятельностью предприятия. Как подсистема в них присутствует собственная система управления проектами.
Кстати, заказывают эти магазины в основном те, кто не в курсе, что можно просто арендовать хостинг с готовым скриптом долларов за сто в год. К нам регулярно обращаются с просьбой написать какой-нибудь магазинчик, мы всех отправляем к готовым решениям.
korchasa
LIMB infected
К этому апеллировал один совершенно отдельный человек. С таким же успехом можно апеллировать к разделению таблиц по этому самому полю. Это даже интереснее - хотя бы сильные различия в подходах есть.
Если карту переходов писать в файл, то сильных различий в коде не будет. Будет меньшая сложность данных, меньшее количество запросов и невозможность (без костылей) сделать изменение матриц администратором.
Это не вопрос дисциплины, это вопрос требований. Так же, как и система контроля версий и багтрекер. Даже если вы не используете специальное ПО для багтрекинга, вы все равно запоминаете, что нужно сделать. Ну или на бумажку записываете. Так и тут: совсем не всегда необходима такая фича, как добавление новых статусов.
The employer
Новичок
Каких требований? Это служебная вещь, примерно как логирование ошибок или юнит-тесты. Или как использование багтрекера.
Если тебе достаточно писать на бумажку, или ты вручную запросами или смастеренными вьюхами получаешь достаточную для тебя картину объектов в БД - так и не ставь багтрекер/не делай браузер объектов. Но если у компании нормальный процесс разработки, то багтрекер дается просто на старте проекта и ты ОБЯЗАН им пользоваться. А в других конторах могут оставлять этот момент на выбор разработчикам. Бог им судья.
korchasa
LIMB infected
Это я относительно словосочетаний "нормальном приложении", "всегда", "никогда" и прочим крайностям. Надо же чем-то заниматься, пока подкасты слушаешь.
Мне почему-то кажется, что все служебные вещи должны либо приносить бабло, либо уменьшать риски по потере бабла. А не внедряться просто потому что "так надо".
Ну вот, нет у нас отдельного багтрекера(жиры с головой хватает), и браузера всего подряд (только по требованию заказчика с заточкой под типичные операции), и юнит тесты с целью уменьшения стоимости делаются только для критических и сложных кусков, приемочных тестов вообще нет, как класса, потому, что заказчик не хочет платить, и проверяет все сам - ручками. Все? Процесс разработки плохой?
слова "серьезный" на 1й странице нет. вообще.
"enum-ы в половине таблиц" удобно ставить в обычных проектах
>арендовать хостинг с готовым скриптом долларов за сто в год.
для магазина бижутерии с шикарным уникальным интерфейсом?
"Страшно далеки вы от народа" (С)Ленин
о том, как из модели убрать "бороду из if...else if...else if..." при подготовке запроса insert - думаю давно
"enum-ы в половине таблиц" удобно ставить в обычных проектах
>арендовать хостинг с готовым скриптом долларов за сто в год.
для магазина бижутерии с шикарным уникальным интерфейсом?
"Страшно далеки вы от народа" (С)Ленин
о том, как из модели убрать "бороду из if...else if...else if..." при подготовке запроса insert - думаю давно
The employer
Новичок
Хуже чем мог бы быть, imho. Да, положа руку на сердце, ты ведь и сам это знаешь, верно?
У нас тоже процесс несовершенен, мы об этом знаем и работаем над его совершенствованием. Потому что если занимать позицию "заказчик не просит, так что и не надо" - это перекрывает пути на более высокий уровень, где заказчику уже надо. Иными словами - не нужно ждать пока появится заказчик, готовый платить за приемочные тесты. Потому что тогда есть серьезный шанс, что такой заказчик не появится вовсе.
Я допускаю, что есть такие интернет-магазины, для которых какой-нибудь шоп-скрипт или любая поделка на основе ос коммерс не подходит. Но мало таких, если мерять в процентах от общего количества.Автор оригинала: grigori
>арендовать хостинг с готовым скриптом долларов за сто в год.
для магазина бижутерии с шикарным уникальным интерфейсом?
"Страшно далеки вы от народа" (С)Ленин
Ну правда, большинство интернет-магазинов уже давно не представляют собой ноу-хау.
-~{}~ 26.07.09 21:39:
Вот да, вот это самое интересное в теме. Буду рад чем-то помочь, если смогу.
korchasa
LIMB infected
Конечно не имеет. Он же всего лишь за него платит. С чего бы ему иметь отношение.
Я писал про конкретный проект, а не о том, что мы можем в принципе. Тут не случай "заказчик не просит", тут "заказчику предложены варианты, и он выбрал более рисковый для себя, но более дешевый". Т.е. заказчик примерно понимает уровень качества, получаемый на выходе, и согласен с ним (в отношении юнитов и приемочных тестов).
ЗЫ: Приемочные тесты для веба это, ИМХО, вообще отдельная и сильно недешевая песня. Я таких проекта видел 3 или 4 штуки, и везде приемочные тесты (Selenium RC и все такое), ИМХО, не оправдали вложений, из-за высокой стоимости написания и поддержки (не смотря на всякие Selenium IDE и сторонние продукты). Со всякими аяксами и богатым JS постоянно тыкались в детские грабельки.
StUV
Rotaredom
а зачем "энумсрач" выбросили в помойку?.. =)
имхо, ему вполне место в БД или оффтопе
-~{}~ 27.07.09 11:00:
The employer
добавив к этому интерфейс описания кейсов + динамический скл - можно вполне отделаться "обобщенной логикой" построения запросов вида "... IN ...", с сохранением производительности и без необходимости выноса этой логики в "серверную модель"... - ?
соотсетственно, указанный интерфейс может быть "клиентским редактором состояний/правил переходов" без необходимости "лезть в бд с енум-ами"
имхо, ему вполне место в БД или оффтопе
-~{}~ 27.07.09 11:00:
The employer
в модель, описанную конечным набором кейсов, всегда можно заложить некоторый конечный набор состояний, комбинаций которых достаточно для описания этих кейсов.
добавив к этому интерфейс описания кейсов + динамический скл - можно вполне отделаться "обобщенной логикой" построения запросов вида "... IN ...", с сохранением производительности и без необходимости выноса этой логики в "серверную модель"... - ?
соотсетственно, указанный интерфейс может быть "клиентским редактором состояний/правил переходов" без необходимости "лезть в бд с енум-ами"
korchasa
был у меня такой опыт
те части, которые писал человек с тестами, пошли в работу без проблем (только он жаловался, что нудно)
те, что были без тестов - пришлось переписать
-~{}~ 28.07.09 17:39:
>когда у кого-нить появится время - вычистим...
предлагаю отнестись к этой интесной теме теме, как к статье на википедии и подправить/подчистить, оставив дело
был у меня такой опыт
те части, которые писал человек с тестами, пошли в работу без проблем (только он жаловался, что нудно)
те, что были без тестов - пришлось переписать
-~{}~ 28.07.09 17:39:
>когда у кого-нить появится время - вычистим...
предлагаю отнестись к этой интесной теме теме, как к статье на википедии и подправить/подчистить, оставив дело