Кто должен оценивать проект с точки зрения разработки?

[Духовность™]

Кто должен оценивать проект с точки зрения разработки?

Суть вопроса такая: дизайнеры рисуют проект для высоконагруженного сайта. В итоге программистам приходится писать скрипты, которые:

* выводят 4 случайных статьи из базы статей. универсального и хорошего алгоритма не существует для данной задачи, кэширование не применить. запросы тормозят базу.

* приходится ради одной ссылки в дизайне делать запрос на получение ID последней статьи раздела. имхо - накладно и можно было бы иначе дизайн слепить.

* дизайнеры рисуют макет, для которого приходится генерировать аж 5 превью изображений, хотя можно было бы сократить и до 3.

и т.д.

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

 

[korchasa]

Re: Кто должен оценивать проект с точки зрения разработки?

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

Тут палка о двух концах. С одной стороны дизайнер, конечно, должен контролироваться. С другой - программисты, иногда, любят гундосить (я по крайней мере), по поводу "ой, это ТАК сложно, что давайте не будем".

* выводят 4 случайных статьи из базы статей. универсального и хорошего алгоритма не существует для данной задачи, кэширование не применить. запросы тормозят базу.

Генерируем 40 случайных чисел. Делаем запрос "select * from article where id in(...)". Результат кэшируем, и выводим из него случайные 4. Пересчитываем раз в n-минут. Если статьи могут удаляться, то выбираем не 40, а побольше.

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

кэширование или денормализация

дизайнеры рисуют макет, для которого приходится генерировать аж 5 превью изображений, хотя можно было бы сократить и до 3.

В чем проблема? Цифра 5 хуже, чем 3?

 

[fixxxer]

> Кто должен оценивать проект с точки зрения разработки?

тех. менеджер

 

[Духовность™]

тех. менеджер

у нас таких нет. просто менеджеры.

В чем проблема? Цифра 5 хуже, чем 3?

проблема в размере дискового пространства, например. мне то похрен, сколько у клиента будет занимать одна статья с 10 превьюшками, речь о том, что этот макет можно сделать с тремя превью, ибо разница в 20 пикселей зачастую.

-~{}~ 30.12.08 14:26:

Генерируем 40 случайных чисел. Делаем запрос "select * from article where id in(...)". Результат кэшируем, и выводим из него случайные 4. Пересчитываем раз в n-минут. Если статьи могут удаляться, то выбираем не 40, а побольше.

вот о том и речь. вместо того, что бы вывести 10 последних по лимиту, приходится писать кэширование, извращаться со SQL запросами и делать запуск по крону для 4 статей в колоночке. Это и есть геморрой, который совершенно не обоснован в контексте задачи.

 

[korchasa]

Автор оригинала: triumvirat
у нас таких нет. просто менеджеры.

А вы переводите все на деньги. Т.е. эту фичу "стоит" 3 человеко/дня. В эксплуатации будет стоить 3 часа в месяц. Менеджеры по сути правы, т.к. "это сложно", это не цифры.

проблема в размере дискового пространства, например. мне то похрен, сколько у клиента будет занимать одна статья с 10 превьюшками, речь о том, что этот макет можно сделать с тремя превью, ибо разница в 20 пикселей зачастую.

SSD уже купили?

вот о том и речь. вместо того, что бы вывести 10 последних по лимиту, приходится писать кэширование, извращаться со SQL запросами и делать запуск по крону для 4 статей в колоночке. Это и есть геморрой, который совершенно не обоснован в контексте задачи.

Обоснован он или нет, решать не программисту, а заказчику. Он, как сказано выше, должен советоваться с тех. специалистом (чтобы хоть примерно оценить затраты на конкретную фичу), но это его бизнес.

 

[Духовность™]

Обоснован он или нет, решать не программисту, а заказчику.

заказчик - амеба. как ему нарисуют, так у него и будет.

 

[korchasa]

Автор оригинала: triumvirat
заказчик - амеба. как ему нарисуют, так у него и будет.

Если он свое бабло не считает, то надо реализовывать ВСЁ, и даже чуть больше

 

[Dreammaker]

Автор оригинала: triumvirat
вот о том и речь. вместо того, что бы вывести 10 последних по лимиту, приходится писать кэширование, извращаться со SQL запросами и делать запуск по крону для 4 статей в колоночке. Это и есть геморрой, который совершенно не обоснован в контексте задачи.

Я подобным путём делал реализацию вывода случайных постов - времени заняло около часа-двух, это с учётом, что нужно было ждать заказчика, чтобы он посмотрел. Сложности абсолютно никакой, даже без крона обошлось (я в кеш пишу время генерации в виде timestamp и если время прошло, кеш перегенерируется, идея в CodeIgniter подсмотрена). Ну а, если нагрузка будет зашкаливать, то тогда можно и на крон перевести.

А так правильно выше сказали - требуйте денег за функционал. Если хочется быть "первее" дизайнеров возьмите Denim или что-то подобное и набросайте протитотип интерфейса. Тут и волки будут сыты, и овцы там же.

 

[grigori]

triumvirat
что конкретно тебе лично не нравится?

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

Хочешь решать в проекте все? Тогда welcome во фриланс.

 

[nalim]

Я вот triumvirat'а отлично понимаю)

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


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

Я согласен тут палка о 2х концах.
С одной стороны: программер мог бы подумать поднатужиться и решить.
С другой стороны дизайнер рисует чтото на страницах сайта от болды?????
Т.е. у него даже не было информации что должно быть на странице?

Или ему "для композиции не хватало"?
Т.е. он не знал чем заполнить пустоту в таком то месте:
это тоже недопустимо!
Если дизайнер не может просто расположить красиво на сайте
то что ему сказали, а вместо этого вставляет отсебятину -
он проявил профессиональную несостоятельность!

-~{}~ 30.12.08 18:41:

Автор оригинала: grigori
Хочешь решать в проекте все?

Ха, я полагаю что автор хочет чтобы в проекте всё было решено!
Вариант гуд:
Вот подошел к нему менеджер и говорит вот здесь будут случайные тексты!
Вопросов нет.

А то например звонит тебе клиент и говорит:
а почему здесь вот нет текста? ты ему так в тз не было, а он тебе:
а вот в дизайне был )

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

 

[grigori]

nalim
вопрос в том, хочет ли triumvirat понимания и сочуствия (это, правда, лучше просить у жены/девушки), или совета коллег

 

[nalim]

triumvirat,
а вот кстати интересно,
если никто не решил
что там должны быть тексты,
то кот вам сказал что они там должны быть?

если вам это сказал дизайнер,
то пусть подойдет к менеджеру,и решит это с ним,
если вам это не нравиться, - подойдите к менеджеру и решите это с ним,
если менеджер не принимает решения и говорит разбирайтесь сами,
то спокойно выкиньте это из головы:
менеджер просто не в духе, но когда у него загориться ж он примет решение )))

 

[Gas]

или совета коллег

я вообще не понимаю как они работают: дизайнер рисует от балды, программист говорит что "я это делать не буду", мнение клиента вообще никого не интересует - красота.
Как минимум сначала с клиентом согласовывается вся функциональность, пишется ТЗ с оценкой по времени и деньгам каждой фичи, дизайнер на основе описанного функционала малюет дизайн (который принимается клиентом раза с 3-го , программер делает что написано. Дополнительные изменения, возникающие у клиента по ходу работы, оцениваются дополнительно, сроки соответственно сдвигаются. Места для отсебятины, которой нет в ТЗ быть и не должно, вернее она может быть на уровне пропихивания клиенту новых фич, за которые дополнительно платятся деньги.

 

[nalim]

Gas
есть такая схема : дизайнер напрямую общается с клиентом,
рисует пока его не удовлетворит

тут есть преимущества:
клиенту понятнее визуально когда он видит что получится,
но минус в том что планируемы программинг может
поменятся.
Пути 2 : 1 согласование
2 - наплевать и забыть)