Персональные инструменты
 

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

Материал из CustisWiki

Перейти к: навигация, поиск

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

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

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

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

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

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

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

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

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

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

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

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

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

Закрытость

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