Доклад-напоминание о том, что нужно думать о тех для кого пишешь, и о тех, с кем пишешь, не усложнять им жизнь лишний раз.
Не все советы, к сожалению, применимы к нашим системам. Например ответ на сакраментальный вопрос «Кто кого использует — пользователь систему или система пользователя?» далеко не всегда очевиден.
Проще для пользователя
- Обновления системы должны быть незаметными для пользователя
- не требовать его внимания
- не тратить его время
- не удивлять его резкими изменениями
Хороший пример — Google Chrome
- Система должна сама выполнять рутинные операции по собственному обслуживание
— плохой пример — Git, где тупую команду по сжатию БД репозитория пользователь должен запускать сам
- Не должно быть диалогов с одной кнопкой, тем более модальных — не нужно тратить время пользователя там, где он ничего не решает и не может сделать
- Не надо выносить внутренний мир программы на пользователя — очень мало пользователей способны читать стеки
Проще для программиста (Коллего-ориентированное программирование)
Главный принцип — YAGNI, «you aint gonna need it».
Слишком сложные структуры
- Интерфейсы с единственной реализацией — зло
- Использование паттернов только ради паттернов — тоже зло
Еще был сомнительный пример, главным тезисом которого было что Hibernate — это плохо, потому что в нам 4000 классов. Я его понимаю так — плохо то, что использовать приходится все 4000 классов, нельзя взять только то, что нужно.
такая простота тоже недешево обходится — монолитные системы создавать проще
Закрытость
- Sealed(final)-классы. Упрощают жизнь разработчику фреймворка, но сильно портят его пользователям. Автор привет в пример Wicket, но c Uni.Net у нас те же проблемы(
