Аннотация
Закончил Факультет информационных технологий НГУ. За шестилетнюю профессиональную карьеру успел позаниматься как веб-интерфейсами автоматизированных систем на Java (и в какой-то момент чуть не умер со скуки), так и аудитом и проектированием различных интерфейсов пользователя. В данный момент работает веб-экспертом в компании Xored, Академгородок, Новосибирск.
- Докладчик
- Никита Прокопов
В докладе я расскажу о двух принципах написания кода, которые, как это обычно бывает, самые важные на свете и про них все забывают (или не знают).
Первый принцип — принцип простоты. На примерах будут рассмотрены проявления культа сложности у программистов и, обратно, преимущества постоянного упрощения и те прекрасные места, куда оно может привести.
Второй принцип — забота о пользователе. Вещь не менее очевидная, но и про нее часто забывают при разработке продуктов; в программировании, кажется, такая постановка вопроса в голову приходит людям еще реже. Назовем этот принцип коллего-ориентированным программированием.
Доклад строится вокруг примеров популярных инструментов разработчика, библиотек и фреймворков, личного опыта автора. Будет полезен начинающим программистам; заблудшим людям; тем, кто ищет правду и лучшего будущего для нас всех.
Видео
- Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1a2-philosophy-of-simplicity-prokopov.avs.avi
Для этого доклада нужен подкаст (аудиозапись)?
Примечания и отзывы
У Никиты Прокопова был интересный доклад о философии простоты, но снабжен он был не самыми лучшими (и даже местами возмутительными!) примерами. Нельзя же брать юниксовые команды с кучей параметров и на их приемре показывать как это неудобно по сравнению с однокнопочными интерфейсами, это же сравнение теплого с мягким! Но тема конечно затрагивает любого разработчика ПО.
И мысль правильная: максимальная простота во всем - наша цель. Кроме неудачных примеров никаких возражений тема не вызывает.
©
Весь доклад был построен на двух основных принципах:
- Первый принцип — принцип простоты.
- Второй принцип — забота о пользователе.
Доклад интересный, хотя ничего нового, вроде и не рассказал. По поводу не совсем корректных примеров уже писали. При повторном просмотре виде сложилось впечатление, что рассказывает сам для себя, причем местами слишком быстро, наверное, слайдов слишком много.
В остальном все нормально. Посмотреть, думаю, стоит, особенно любителям все усложнять. ©
Следующим был Никита Прокопов с выступлением про простоту. Задорное название предвещало веселье в духе, скажем, опуса Павла Кудинова про кошерные костыли. А получилось чуть менее чем полностью унылое ношение воды решетом. Кроме довольно неумелых попыток затроллить линуксоидов нечего и вспомнить. Ни фана, ни трюков. Предложение автора бороться со сложностью методом ее игнорирования категорически не поддерживаю. ©
Философия простоты. С одной стороны я со всем в докладе согласен, с другой — и чего об этом рассказывать, вроде все очевидно.
Интересный доклад.
Основная мысль — о том, что программисты часто реализуют сложные решения по разным причинам. И часто — внутренне тяготеют к сложным решениям. А правильно — стремиться к простоте. Поэтому лекция — еретическая, против культа сложности программиста (используешь сложный редактор — крут).
В проблемной части достаточно много экстремистских примеров — про простоту, которая игнорирует разнообразие мира. Я вижу реальные причины — разные люди, разные задачи, в которых востребовано разное использование продукта. С другой стороны, сложность растет и по другим причинам — накапливаясь исторически, или из-за отложенных решений. Все это надо убирать (рефакторинг), но этого не делают.
Экстремизм в проблемной части не мешает предлагаемым решениям быть вполне конструктивными:
- Вопросы Почему и Зачем
- Забота о пользователе
- Использовать шаблоны только когда они нужны, а не тотально по коду
- Коллего-ориентированное программирование — думайте о своих товарищах
Да, многие решения очевидны. Только в реальном мире почему-то не слишком используется :(
Я: Решение могут быть в синтезе и за плоскостью, типа общезначимых конфигов, отделенных от конкретных систем в примере с конфигами и настройками. Об этом в докладе не было. Еще было достаточно много спорных примеров улучшения решений. Однако сам доклад — безусловно интересно слушать, он будет собственные мысли.
Доклад-напоминание о том, что нужно думать о тех для кого пишешь, и о тех, с кем пишешь, не усложнять им жизнь лишний раз.
Не все советы, к сожалению, применимы к нашим системам. Например ответ на сакраментальный вопрос «Кто кого использует — пользователь систему или система пользователя?» далеко не всегда очевиден.
Проще для пользователя
- Обновления системы должны быть незаметными для пользователя
- не требовать его внимания
- не тратить его время
- не удивлять его резкими изменениями
Хороший пример — Google Chrome
- Система должна сама выполнять рутинные операции по собственному обслуживание
— плохой пример — Git, где тупую команду по сжатию БД репозитория пользователь должен запускать сам
- Не должно быть диалогов с одной кнопкой, тем более модальных — не нужно тратить время пользователя там, где он ничего не решает и не может сделать
- Не надо выносить внутренний мир программы на пользователя — очень мало пользователей способны читать стеки
Проще для программиста (Коллего-ориентированное программирование)
Главный принцип — YAGNI, «you aint gonna need it».
Слишком сложные структуры
- Интерфейсы с единственной реализацией — зло
- Использование паттернов только ради паттернов — тоже зло
Еще был сомнительный пример, главным тезисом которого было что Hibernate — это плохо, потому что в нам 4000 классов. Я его понимаю так — плохо то, что использовать приходится все 4000 классов, нельзя взять только то, что нужно.
такая простота тоже недешево обходится — монолитные системы создавать проще
Закрытость
- Sealed(final)-классы. Упрощают жизнь разработчику фреймворка, но сильно портят его пользователям. Автор привет в пример Wicket, но c Uni.Net у нас те же проблемы(
- Философия_простоты,_или_еретическая_лекция_о_программировании_(Никита_Прокопов,_ADD-2011)
«Nobody likes molting boron» © Futurama.
Разумеется, никто не любит сложность. Это хорошо видно и по остальным отзывам к докладу.
Сложность систем, сложность интерфейсов.
Но для меня сложность — это не легкое раздражение при виде меню из пяти пунктов, вместо кнопки «включить».
Сложность — это стресс, это нервы, это специализация, это риски «тут ничего не сможет сделать неспециалист», причем
специалист становится фантастически редкой штукой.
Нереально вручную починить иномарки и бытовую технику — хотя вроде бы интерфейс-то у них простой, а сложность упрятана за сотни пломб.
Позволю отвлеченный пример.
Когда-то я смотрел комедию братьев Коэнов «Аэроплан», где разыгрывалась смешная сценка —
в небе летит пассажирский лайнер, где все, кто выбрал на обед рыбу — отравились.
Включая пилотов.
Стоит фантастическая задача — найти среди пассажиров кого-то, кто сможет посадить этот Боинг.
И доктор — комедийный персонаж Лесли Нильсена, говорит стюардессе «Вам нужно не только найти человека, который сможет посадить самолет. Но и того, кто не ел на обед рыбу».
Тут разумеется смех в зале, за кадром и везде. Бггг — сравнил вероятность найти пилота среди паксов, 1/100500 и
50/50 (выбор «рыба или курица» за обедом).
Какого же было мое удивление, когда я таки добрался до первоисточника, на который сняли эту пародию,
«[Взлетно-посадочная полоса ноль-восемь]» Артура Хейли, и обнаружил, что исходный диалог еще более адовый:
- Мисс Бенсон, вы когда-нибудь слышали о теории вероятности?
- О теории вероятности? Я полагаю, да. Но я не знаю, что это такое.
- Я вам объясню. Это значит вот что. Из общего количества в пятьдесят
шесть человек наш единственный шанс выжить зависит от того, есть ли на
борту человек, который не только способен посадить эту штуковину, но и
который бы НЕ ЕЛ рыбу на обед. ©
(и кстати, рыбу там выбрали только 30% пассажиров).
По тексту также видно, что полно персонажей тоже летчики (газетчики и т.п.), и вообще, умение управлять самолетом было не rocket science, ну может как водительские права для СССР в застое.
Кстати, сюжет не совсем художественный — были реальные случаи, пассажир-пилот в 1954 отлично посадил самолет, после приступа аппендицита у первого пилота (со вторым там какая-то паника приключилась).
А сейчас, если среди пассажиров лайнера вдруг оказались люди умеющие им управлять — это наоборот, офигенный фактор риска, что самолет полетит совсем не туда (9/11).
Так вот, в этом докладе был взят классический беспроигрышный вариант — взять программерские тулы и фреймворки, издревне известные негламурностью интерфейсов и демонстративно отпинать за это самое.
Я был особенно польщен, что с особым восторгом отпинали мой совет линуксоидам, у которых нет тулы для записи скринкастов (я просто не в курсе), как это можно сделать пайпом из двух непредназначенных для этого утилит (Я сам не очень линуксоид, поэтому альтернативы не нашел).
Однако почему это так? Почему программерские тулы любят настройки, опции?
Может это заговор программистов? против программистов?
Почему они не хотят использовать красивый и гламурный GUI-based SourceSafe, а возятся с таким исчадием ада как Git? Без conspiracy theory тут не разобратся, наверняка это влияние ордена тамплиеров, и чтобы бросить ему вызов нужна проповедь еретика.
На самом деле все просто.
При выборе «Свобода или гламур», «Возможности или кажущаяся простота» программисты выбирают свободу и возможности.
Страховка от неверного выбора — это отдельный вопрос, он решается не запаиванием пульта управления под девизом «вам это не нужно», а контролем версий, тестами, и т.п. А в остальном — все для максимальной производительности, для максимума скорости, все для победы.
Если серьезно работаешь, каждая мелочь в твоем инструменте может стать важной, и правильная настройка сэкономит годы жизни. От чего можно отказаться в текстовом редактире? От настройки шрифтов? Клавиатурных сокращений? Настраиваемой синтаксической раскраски? Режима редактирования колонками? Вызова внешних команд? Разбора их вывода? ...
Мне нужно все. И больше. Ах много настроек? — ничего, я справлюсь с этим.
Всего этого я жду от любой программы, включая медиаплеер. Я хочу, чтобы программа могла сделать все, на что она потенциально способна.
Плеер? ОК. Ты должен уметь играть быстрее и медленее, управлятся с клавиатуры, причем глобально (хрен иначе сделаешь стенограмму), переключать звуковые дорожки и субтитры, должна быть эффективная навигация по видеофайлу, обязателен и commandline интерфейс.
Да, такой только один, VLC, и то, я хочу от него еще кучу фич! Ах, он не гламурен, нет скина со свистелками-перделками, в диалоге настроек много страшных опций пугающих хомяков? Мне плевать!
Раз он на порядки эффективней.
И так во всем остальном. В молодости простительно жаждать простоты, и плевать на эффективность — еще мало знаешь, время твое дешево, и его очень-очень много. Пройдет лет 10, и станет ясно, что времени осталось чуть, каждый час на счету, на счету и остатки зрения, нервов и т.п. — и растрачивать это, пользуясь простыми немудренными мотыгами вместо тракторов — глупо.
И фантастически обидно пользоваться, внешне простым и гламурным инструментом или фреймвором, когда никак, ни за что нельзя (даже если это нехорошо), залезть и использовать так, как тебе надо — автоматизировать через командную строку, посмотреть внутренние структуры данных и т.п.
Я не хочу внезапно оказаться в воздухе на лайнере без пилотов! Пусть даже он будет внутри сто раз гламурен, а интерфейс кресла просто до невозможности.
Я против тупого гимна простоте — «Будь проще, и люди к тебе потянутся» — тут потянутся такие люди, что об этом сто раз пожалеешь.
Да, сложность бывает необоснованной, бывает заградительной на начальном этапе — а я хочу, чтобы была невырожденная кривая обучения!
Чтобы можно было пользоваться и с нуля, прочитав «Getting Started», «Crash course» или «Airplanes for dummies», но продолжать совершенствование, не упираясь запаянные люки в потолоке.
Но это уже совсем другой вопрос, как обеспечить это — вот это уже интересная задача.
Например, разумный конструктивный вопрос — какой интерфейс должен быть когда настроек много?
Когда нет шансов выбрать однозначную иерархию, чтобы пользователь мог выбрать правильный путь не перебирая углы и тупики скрытых иерархий и закладок.
Тут на самом деле решение есть — простые текстовые файлы, в незамусоренном формате типа INI-файлов, с комментариями, очень удобны для настроек. И чисто для нубов заводят эти страшные диалоги настройки,
И т.п.
Надо развивать эти мысли на отдельную тему «Usability for advanced users».
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
