|
|
| Строка 13: |
Строка 13: |
| | * Не должно быть диалогов с одной кнопкой, тем более модальных — не нужно тратить время пользователя там, где он ничего не решает и не может сделать | | * Не должно быть диалогов с одной кнопкой, тем более модальных — не нужно тратить время пользователя там, где он ничего не решает и не может сделать |
| | * Не надо выносить внутренний мир программы на пользователя — очень мало пользователей способны читать стеки | | * Не надо выносить внутренний мир программы на пользователя — очень мало пользователей способны читать стеки |
| − | {{ok}} В RMS с определенного момента мы этим озаботились — в новом функционале обращаем внимание на обработку ошибок и выдачу конкретных сообщений пользователям с описание конкретной проблемы в их терминах, а не «Sequence contains no elements».
| |
| − | {{remark|Хотя наши инженеры со мной не согласны}}
| |
| − | * Нужно ограничивать количество настроек — большинство из них никогда не понадобятся пользователю
| |
| − | {{warning}} Подумать про исправление настроек печати в RMS — все три настройки на рисунке (одна из которых произвольное поле ввода) можно объединить в один drop-down box с двумя вариантами
| |
| − |
| |
| − | [[Image:Rms print.png]]
| |
| | | | |
| | === Проще для программиста (Коллего-ориентированное программирование) === | | === Проще для программиста (Коллего-ориентированное программирование) === |
Текущая версия на 23:38, 20 мая 2011
Доклад-напоминание о том, что нужно думать о тех для кого пишешь, и о тех, с кем пишешь, не усложнять им жизнь лишний раз.
Не все советы, к сожалению, применимы к нашим системам. Например ответ на сакраментальный вопрос «Кто кого использует — пользователь систему или система пользователя?» далеко не всегда очевиден.
Проще для пользователя
- Обновления системы должны быть незаметными для пользователя
- не требовать его внимания
- не тратить его время
- не удивлять его резкими изменениями
Хороший пример — Google Chrome
- Система должна сама выполнять рутинные операции по собственному обслуживание
— плохой пример — Git, где тупую команду по сжатию БД репозитория пользователь должен запускать сам
- Не должно быть диалогов с одной кнопкой, тем более модальных — не нужно тратить время пользователя там, где он ничего не решает и не может сделать
- Не надо выносить внутренний мир программы на пользователя — очень мало пользователей способны читать стеки
Проще для программиста (Коллего-ориентированное программирование)
Главный принцип — YAGNI, «you aint gonna need it».
Слишком сложные структуры
- Интерфейсы с единственной реализацией — зло
- Использование паттернов только ради паттернов — тоже зло
Еще был сомнительный пример, главным тезисом которого было что Hibernate — это плохо, потому что в нам 4000 классов. Я его понимаю так — плохо то, что использовать приходится все 4000 классов, нельзя взять только то, что нужно.
такая простота тоже недешево обходится — монолитные системы создавать проще
Закрытость
- Sealed(final)-классы. Упрощают жизнь разработчику фреймворка, но сильно портят его пользователям. Автор привет в пример Wicket, но c Uni.Net у нас те же проблемы(
