Application Developer Days 2: Отчет Кудрявцева В.Б/Философия простоты или еретическая лекция о программировании

Ссылки сюда (2) →

Доклад-напоминание о том, что нужно думать о тех для кого пишешь, и о тех, с кем пишешь, не усложнять им жизнь лишний раз.

Не все советы, к сожалению, применимы к нашим системам. Например ответ на сакраментальный вопрос «Кто кого использует — пользователь систему или система пользователя?» далеко не всегда очевиден.

Проще для пользователя

• Обновления системы должны быть незаметными для пользователя
  • не требовать его внимания
  • не тратить его время
  • не удивлять его резкими изменениями

Хороший пример — Google Chrome

• Система должна сама выполнять рутинные операции по собственному обслуживание

— плохой пример — Git, где тупую команду по сжатию БД репозитория пользователь должен запускать сам

• Не должно быть диалогов с одной кнопкой, тем более модальных — не нужно тратить время пользователя там, где он ничего не решает и не может сделать
• Не надо выносить внутренний мир программы на пользователя — очень мало пользователей способны читать стеки

В RMS с определенного момента мы этим озаботились — в новом функционале обращаем внимание на обработку ошибок и выдачу конкретных сообщений пользователям с описание конкретной проблемы в их терминах, а не «Sequence contains no elements».

Хотя наши инженеры со мной не согласны

• Нужно ограничивать количество настроек — большинство из них никогда не понадобятся пользователю

Подумать про исправление настроек печати в RMS — все три настройки на рисунке (одна из которых произвольное поле ввода) можно объединить в один drop-down box с двумя вариантами

Проще для программиста (Коллего-ориентированное программирование)

Главный принцип — YAGNI, «you aint gonna need it».

Слишком сложные структуры

• Интерфейсы с единственной реализацией — зло
• Использование паттернов только ради паттернов — тоже зло

Еще был сомнительный пример, главным тезисом которого было что Hibernate — это плохо, потому что в нам 4000 классов. Я его понимаю так — плохо то, что использовать приходится все 4000 классов, нельзя взять только то, что нужно. такая простота тоже недешево обходится — монолитные системы создавать проще

Закрытость

• Sealed(final)-классы. Упрощают жизнь разработчику фреймворка, но сильно портят его пользователям. Автор привет в пример Wicket, но c Uni.Net у нас те же проблемы(