Здравствуйте, Andrbig, Вы писали:
A>Вот мы добрались и до бизнес-сценария. Опытный проектировщик предложил идентифицировать бизнес-сценарий и под него написать UI. Видимо обилие опыта заслонило проектировщику тот маленький факт, что бизнес-сценарий может быть просто неизвестен на момент разработки программы.
Если заказчик/пользователь не может объяснить зачем ему эта функциональность и какие задачи он собирается решать с ее помощью то смысла реализовывать эту функциональность нет никакого (кроме как сбить побольше денег с заказчика или показать начальству что мы вот работаем).
Здравствуйте, Andre, Вы писали:
A>Если заказчик/пользователь не может объяснить зачем ему эта функциональность и какие задачи он собирается решать с ее помощью то смысла реализовывать эту функциональность нет никакого (кроме как сбить побольше денег с заказчика или показать начальству что мы вот работаем).
Это в идеальном мире. А в реальном — часто бывает, что заказчик/пользователь не может внятно объяснить < ... >. И с этим надо как-то жить. Потому что заказчик может быть большой и богатый, а кушать хочется. И хотя при грамотной огранизации работы над проектом, обычный программист с "проблемой заказчика" не столкнется, грамотная огранизация бывает только в идеальном мире. А в реальном...
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Это в идеальном мире. А в реальном — часто бывает, что заказчик/пользователь не может внятно объяснить < ... >. И с этим надо как-то жить. Потому что заказчик может быть большой и богатый, а кушать хочется. И хотя при грамотной огранизации работы над проектом, обычный программист с "проблемой заказчика" не столкнется, грамотная огранизация бывает только в идеальном мире. А в реальном...
Если заказчик не может внятно объяснить что ему нужно, пусть опишет письменно Обычно на этом этапе уже большой отсев идей. Далее нужно задавать уточняющие/наводящие вопросы. Дать время пусть думает если нужно. Иногда через месяц ничего уже не нужно Если сопротивляется, значит все таки что то в этом есть. Придется предлагать наводящие идеи по ходу уточняя. Здесь можем прийти или к "внятному" описанию или все таки решению что это не нужно.
Да, это не проблема разработчика. Такие вещи вообще не должны его волновать и такие задания не должны доходить до него. Выдав в таком случае задание на разработку (хотя как тут сформулировать требования к задаче ) получим соответственно "грид с 10000 записями" и 99.9% что это будет переделано. Да, бывают исключения в виде форс-мажоров, богатых дядек и т.д.. Из приведенных выше обрывочных описаний у меня не сложилось впечатление что это такой исключительный случай.
p.s. Я наверное зажрался, работая в последнее время в комфортных условиях, когда какая то фича делается не потому что так кому то захотелось, а это входит в план, описано в требованиях, проработано и согласовано с заказчиком аналитиками.
Здравствуйте, Andre, Вы писали:
A>Если заказчик не может внятно объяснить что ему нужно, пусть опишет письменно Обычно на этом этапе уже большой отсев идей.
См. пункт второй — "И хотя при грамотной организации работы над проектом..." — а ты сейчас именно эту организации и описываешь. Она, конечно, бывает в природе, но чаще все-таки ее не бывает.
A>p.s. Я наверное зажрался, работая в последнее время в комфортных условиях, когда какая то фича делается не потому что так кому то захотелось, а это входит в план, описано в требованиях, проработано и согласовано с заказчиком аналитиками.
Здравствуйте, VladD2, Вы писали: VD>Ты конечно волен делать и так. Но я бы такого работника выгнал, так как мне не нужны не эффективные работники.
А кто сказал, что я бы пошел к тебе работать? При таком отношении, лучше работать в другом месте в более комфортных условиях. Хотя чем черт не шутит возможно и придется
Здравствуйте, Andrbig, Вы писали: A>Ребята, вот вам пример того, как делать НЕ НАДО — вещать выводы, не разобравшись в ситуации.
Ок, давай подробнее. Я всегда для критики открыт. A>Пойду расскажу нашим пользователям, какого ты мнения об их мозге — именно они предложили данный способ работы.
Да запросто. А что, твои пользователи — великие специалисты по usability? Да они просто слаще редьки ничего не ели, от того и выражают свои потребности "хотя бы так". A> Кстати, про пользователей — откуда уверенность, что у них нет ни записей, ни полей?
Из опыта. Из очень большого опыта. Объясни мне, в какой области бизнеса есть записи и поля? A>У наших пользователей есть записи (они называются позициями), есть поля и это им понятно и привычно. Заменить что-то абстрактно — да, этого нет, есть задачи заменить что-то конкретно. Но об этом дальше — в бизнес-сценарии.
A>Вот мы добрались и до бизнес-сценария. Опытный проектировщик предложил идентифицировать бизнес-сценарий и под него написать UI. Видимо обилие опыта заслонило проектировщику тот маленький факт, что бизнес-сценарий может быть просто неизвестен на момент разработки программы.
Гм. Есть такое — называется "недопроектирование". Как можно писать софт, который решает неизвестно какую задачу? В каком виде было сформулировано ТЗ? "Освоить полтора миллиона долларов IT-бюджета" что ли?
S>>В данном примере, как всегда, произошла кошмарная потеря информации. А именно, Andbrig легким манием руки выкинул самое важное из того, что ему рассказал бедный пользователь: A>В данном примере произошло кошмарное предположение о сути задачи. А именно, Sinclair решил, что прользователь что-то рассказал о своей бизнес-задаче на этапе разработки программы. Это неверно и потому весь вал последующих рассуждений можно выбрасывать в мусорку, как основанный на неверных предпосылках.
А, то есть общения с пользователями Andrbig вообще избежал? Ну это, конечно, гарантированный способ добиться успеха. A>Весь этот кладезь информации отсутствует.
Значит, нужно его получить. Никто за вас это готовить не будет. 50% успеха — это выяснить, что именно нужно пользователям. Еще 50% — это умение быстро исправить все написанное после того, как оказалось что пользователям нужно совсем другое S>>Попробуем поспекулировать на эту тему и угадать, что иименно было выплеснуто из ванны. A>Ты не один старался или это мы, Николай II? Увы, не угадал.
Да я и не собирался угадать. Я просто хотел показать, какова разница в результатах, если начинать "от грида и комбобокса" и если начинать от бизнес-сценария. S>>А куда же делась многостраничная сетка ? Ой, оказывается она нам не понадобилась. И это не случайно — она неудобна для выполнения поставленных перед пользователем задач. A>Конечно не случайно — ведь пример был выбран такой чтобы она не понадобилась.
A>Sinclair, раз уже ты сказал "А", я хочу узнать у тебя про "Б": готов ли ты обсудить архитектурные решения, если я опишу задачу?
Да, готов. Может быть не сразу — у меня еще и работа есть
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Да, готов. Может быть не сразу — у меня еще и работа есть
Ok, отлично. Я заведу ветку в алгоритмах, здесь же дам ссылку. Только тоже не сразу — и у меня еще есть работа.
Здравствуйте, Andrbig, Вы писали:
S>>Да, готов. Может быть не сразу — у меня еще и работа есть A>Ok, отлично. Я заведу ветку в алгоритмах, здесь же дам ссылку. Только тоже не сразу — и у меня еще есть работа.
В алгоритмах это оффтопик. ИМХО лучше в проектирование или вобще в юзабилити.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Память и .Net
От:
Аноним
Дата:
27.04.06 20:10
Оценка:
А у меня 20000 строк отображается, а в них — 6 полей %). Это было очень жесткое требование -- отображать все записи.
Соответственно, вот тесты. Все проведены на одном компьютере с WinXP. Все данные округлены +/- 5.
1. 128 МБ RAM практически равноценен 256 МБ RAM и 758 МБ RAM ввиду того, что без загруженной программы системой используется только 67 МБ RAM
С закрытым НД -- 35 МБ
С открываем НД -- 45 МБ
Ищем не встечающуюся строку -- 45 МБ
Закрываем НД -- 45 МБ
Минимизируем приложение -- 700 кБ
Теперь снова показываем форму -- 4 МБ
Открываем НД — 14 МБ
Ищем не встечающуюся строку -- 14 МБ
Минимизируем приложение -- 730 кБ
И так делее...
2. 64 МБ RAM !!! Системой занята вся память.
С закрытым НД -- 5 МБ
С открываем НД -- 30 МБ
Ищем не встечающуюся строку -- 30 МБ
Закрываем НД -- 45 МБ
Минимизируем приложение -- 700 кБ
Теперь снова показываем форму -- 5 МБ
Открываем НД — 15 МБ
Ищем не встечающуюся строку -- 15 МБ
Минимизируем приложение -- 600 кБ
И так делее...
Из всего этого делаем вывод, что фактически требуется не более 5 метров на интерфейс и 10 метров на работу с БД (грубо, но понятно)
Здравствуйте, Andrbig, Вы писали: A> Правильно — это как, воинственный ты наш? Например, юзеру надо что-то найти, он открывает поисковую форму (или переключается в нее, если она уже открыта), попадает мышью в нужное поле, вводит там строку поиска, жмет кнопку "Искать". Программа находит 5000 элементов. Он снова переходит в поисковую форму, дополняет поиск (а это может быть пара букв), снова жмет, программа находит, он снова переключается — и так до тех пор, пока не будет найдено приемлимое число.
A> Другой вариант. Список из 10..20 тыс. Юзер вводит в фильтрационном поле букву, список тут же фильтруется, еще букву — еще фильтруется, еще пара букв — и результат перед глазами. Сравни сколько кликов по окнам и полям происходит в этих вариантах.
1. Принять стёб за воинственность? Извините
2. В предложении "Правильно работать надо, а не фигней страдать" после слова "правильно" имелась ввиду запятая , но и с таким вариантом я согласен.
3. По-поводу примера, есть у нас программулина (на клиппере еще писанная) с таким интерфейсом, которая делает задачу попроще: просто становится на первую строчку начинающуся с введенного текста. Так вот в списке из 10000 строк для меня очевидно, что одной буквы будет не достаточно чтобы найти то что надо, понадобится несколько больше, и вот то что программулина фигней страдает после каждого нажатия жутко раздражает. Я бы предпочел чтобы действия по поиску или тому подобному начиналась по моей команде, т.е. я ввожу текст и жму enter — ИМХО лучшее юзабилити, чем автомат после каждой буквы. Как показывает наш опыт, поиск по одной букве нужен только людям, которые не знают чего они ищут. По-моему очевидно, модификация сценария с enter'ом является как раз средним между описанными вами. Будем считать количество кликов и нажатий клавиш и их существенность (клавиша ввода не зря такая большая)?
4. Польностью согласен с A> "Правильно работать" для сервера и программиста не всегда совпадает с "удобно работать" для юзера, увы.
И тут как раз работать со списком в 10000 строк сразу — это удобство для программера, а никак не для юзера.
5. Даже для описанного вами сценария не проглядывается необходимость иметь все и сразу.
6. RL>>Объясните откуда такое бредовое требование все и сразу? A> То что ты его не понимаешь не значит что оно бредовое.
Вот я и стараюсь понять, чтобы оно для меня перестало быть бредом.
Теперь ко второму посту: A> OK, я этим все понятно, следующий вопрос. Вываливается список, надо выделить N записей и у всех заменить определенное поле на какое-то значение. Для определенности пусть это будет ФИО человека, обрабатывающего эти позиции. A> Вариант со страницами. Рассмотрим случаи, когде N > размера страницы (иначе все одинаково и сравнивать нечего). Итак, надо сделать поиск, выделить все строки, указать заменяемое поле и новое значение, нажать "Заменить". Перейти на следующую страницу, выделить, указать, заменить. При этом надо держать в голове (!) сколько страниц уже пройдено и высчитывать сколько осталось. Да, круглые цифры запомнить легко, но так же легко и сбиться. A> Вариант с общим списком. Находятся все записи у которых нужное поле пусто (или сразу найти или найти все и отфильтровать — неважно), выделяется первая строка, хватается бегунок и тащится вниз. Просходит страшный скроллинг, компьютер трясется и скрипит, но скролирует. Слева есть номер строки, дотаскивается бегунок до нужной строки, там выделяется строка с нажатым Shift. Все выделяется. Выбирается поле, новое значение, жмется кнопка "Заменить". Это делается один раз. A> Что удобнее юзеру и где меньше возможностей запутаться?
1. Мне интересно, вы подгоняете задачи под условия "10000 строк все и сразу" или приводите реальные задачи?
2. Мне как юзеру в этой задаче нужно выделить скажем 10 строчку, глазами проскролить с шифтом до 8752 строки??? А там точно не надо пропустить с 5632 строки по 5676? Я что сумашедший? Да я просто выкину такую программу, если автор сего творения решил сделать супер универсальный интерфейс, вместо того чтобы посмотреть какие бывают юзкейсы и для каждого сделать соотвествующий. Вы что, сравнивая очень очень плохой интерфес с просто очень плохим, обосновываете необходмость в списке из 10000 строк?
>>Если заказчик не может внятно объяснить что ему нужно
Беседовать с заказчиком должен не разработчик, который только от "станка" отошел, а психолог. Опытный психолог. У разработчика и клиента разный уровень восриятия. Первый мыслит на уровне API, другой на уровне эмоций, каких-то своих ассоциаций и амбиций.
>>Обычно на этом этапе уже большой отсев идей.
Это плохо. Нужно помогать рождаться идеям. Из них можно извлечь много путного и для других проектов. Идеи на полу валяются. Их нужно уметь ценить.
>>Иногда через месяц ничего уже не нужно
Ну вот. Упустили клиента и радости полные штаны...
>>Да, это не проблема разработчика. Такие вещи вообще не должны его волновать и такие задания не должны доходить до него.
Не волновать такие вещи могут разработчика в одном единственном случае: от этого не зависит его заработная плата.
>>Я наверное зажрался, работая в последнее время в комфортных условиях, когда какая то фича делается не потому что так кому то захотелось, а это входит в план, описано в требованиях, проработано и согласовано с заказчиком аналитиками.
Зажрались, батенька Сам сейчас весь в XP ушел. Ибо по другому никак
Господа, а чего спорить-то? Всё зависит от конкретного случая.
Из моего скромного опыта, превыборка гораздо эффективнее (при числе строк до 20 000). Во-первых, в противном случае приходится вводить ещё один слой абстракции как на клиенте, так и на сервере. Во-вторых, гораздо лучше масштабируемость, снижается общая нагрузка на сервер и сеть. Заодно — меньше вероятность коллизий. (напоминаю, объём данных — константа, говорим о числе пользователей... порядка полусотни активно работающих с серваком на Cel2.4/512 Для действительно больших объёмов всё как раз наоборот...).
Насчёт производительности... Запрос 10 338 строк в 5 таблиц с кучей джойнов с холодного старта занимает 3,5 сек (на server-side — 1,5-2 сек). Повторный запуск — 3 сек. Ворксет после активной работы разрастается до 45 МБ, что, впрочем, мешает чисто психологически...
Это — в дебаге и из-под студии. В реальности производительность процентов на пятнадцать-двадцать выше...
А вот с отображением надо думать... Как насчёт введения древовидного каталогизатора + поиск?
Эмпирическое изучение граблей высоких энергий несколько затруднено…
Поддержу Andrbig'а. Требуются большие списки и очень часто.
Основной пример — психологический. Если пользователю от 40 лет и выше, то он в свое время наверняка работал с FoxPro программами, которые выводили все в виде длинных списков. В связи с этим у многих сформирован следующий стереотип: если я чего-то не вижу на экране монитора, то этого нет. Бороться с этим очень-очень сложно.
Обычно на этом этапе уже большой отсев идей. Далее нужно задавать уточняющие/наводящие вопросы. Дать время пусть думает если нужно. Иногда через месяц ничего уже не нужно 
1.1.4 stable rev. 510
