lex_kravetski

Про название

По-научному её наверно надо называть «предельная автоматизация», однако название «авто-всё» гораздо лучше раскрывает суть концепции.

Введение

Двадцатый век принёс не только полёты в космос, телевизоры и мобильные телефоны. Основным его завоеванием стал переход от инструмента вида «молоток» к автомату. И до этого ведь строили механизмы, в том числе автоматические – водяные мельницы, например, мололи зерно с незапамятных времён. Да и более суровые аппараты собирались. Автоматические прялки, линотипы, пивоварни – всё это появилось раньше двадцатого века. Однако оно имеет один нюанс: данные автоматы – станки. То есть, механизмы, использующиеся для производства однотипного товара.

Заслуга двадцатого века не просто рост количества аппаратов, а понимание на уровне принципов: автоматизировать можно что угодно. Автоматизировать надо всё, что можно автоматизировать. Любой процесс, производственный он или нет, заслуживает автоматизации. Не надо заставлять абонента каждый раз набирать номер – номер можно запомнить. Не обязательно требовать от водителя крутить ручку, чтобы завести мотор – достаточно как-то опознать его присутствие в машине, например, по повороту ключа. Печатная машинка может перевести строку по нажатию клавиши – не нужно крутить барабан. И так далее.

Но вершиной повальной автоматизации всё-таки стал компьютер. Не конкретная его реализация – идея. Идея аппарата, основная цель которого – автоматизация процессов.

Хотя игры тоже однозначно руля́т.

Первые компьютеры использовались в качестве калькуляторов, способных выполнять миллионы математических операций за то время, пока человек выполнит одну. Уже неплохо. Однако революция произошла в тот момент, когда коллективный разум понял: мы сделали нечто большее. Не просто большой арифмометр. Не просто волшебного счетовода. Мы сделали машину, которая в перспективе возьмёт на себя все рутинные операции, которые ранее приходилось выполнять каждому человеку.

Поток слабосвязанных жалоб, необходимых однако для понимания концепции

Осознать перспективу – одно, а вот воплотить её в жизнь – совсем другое. До сих пор многие приборы работают так, будто проектировались с мыслью «человек нужен для прибора». Например, многие программисты, – особенно начинающие, – убеждены, что основной способ пользователя их программ продемонстрировать свой развитый интеллект – это разобраться с тем, как с их программой следует работать. Стоит пользователю сказать «вот тут неудобно», так сразу на него сыпется поток диагнозов «ты – тупой юзверь». Ему рекомендуют срочно починить мозги, заменить прокладку между стулом и монитором и прочее подобное. Хотя нужно было всего-то сделать удобнее.

В данном случае программисты просто не отдают себе отчёт, что свой интеллект любой пользователь проявляет с помощью программы, а не ради неё. Да, некоторые программы неминуемо будут сложными. В них огромное множество функций, в их логике довольно нетривиальные абстракции, они подразумевают не всегда привычные в быту сценарии работы и так далее. Но суть всего этого вовсе не в том, чтобы дать тупому юзеру блеснуть интеллектом, вычислив и заучив комбинации клавиш, которые приводят к закрытию программы без сохранения. Всё это нужно для упрощения решений задач, которые юзеру надо решить. И эти самые абстракции не упражнение для ума, они – способ сократить время на решения задачи. Пусть даже ценой времени, однажды потраченного на постижение сути предложенных абстракций. Крайне тяжело нарисовать трёхмерный мультик просто на бумаге. На компьютере проще. Для этого надо понять, что такое «меш», «ребро», «вершина». Что такое «текстура», «ключ», «модификатор». Как они между собой связаны. Как с ними работать. Но не «почему у меня вдруг половина рёбер куда-то пропала, хотя я в этот момент за компом вообще не сидел». Последнее ведь только затягивает решение.

Программу, написанную новичком, кстати, довольно легко опознать. Например, если в ней предлагается ввести набор параметров для каких-то расчётов, то форма для ввода параметров будет пустая. «Пользователь моей программы не дурак, он сам знает, что и куда вводить». В меню такой программы будут фигурировать не привычные «сохранить», «открыть» и «выйти», а «запердолить в вечность», «прикоснуться к прекрасному» и «признать себя лузером». И это ещё хорошо, если делать эти команды будут то же самое, что «сохранить», «открыть» и «выйти». Начинающий не думает об удобстве пользователя, ему главное быть непохожим на «серую массу». Ну и «форму заполнять за пользователя – это фи».

Ровно тот же метод зачастую используют и маститые специалисты, что мы наблюдаем сплошь и рядом. Например, крайне затруднительно перенести текст из буфера обмена Ворда в браузер с сохранением форматирования. В буфер почему-то попадает только то оформление, которое прописано локально в тексте, а не в стилях, к нему применённых. Однако куда чаще всего копируют этот текст, за исключением другого текстового процессора? В браузер – об этом легко догадаться хотя бы потому, что в буфере обмена лежит html. Неужели разработчики не могли предвидеть такой вариант использования? Могли. Но они об этом даже не думали.

С другой стороны, если из Ворда записать html, то он будет содержать всю информацию для того, чтобы Ворд сумел потом считать эту информацию без потерь. Кто-то в мире, интересно, использует команду «сохранить html» для последующего открытия результата Вордом? Подозреваю, никто не использует. Тогда почему выбраны именно вот эти два варианта, не подходящие 99% задач пользователей? Да потому, что о распространённых задачах пользователей разработчики не думали. Они думали просто о задачах. «Им нужно сохранить html – вот команда, им нужно скопировать в браузер – копирование работает». Но никто не подумал о результатах, к которым обычно стремятся пользователи. О том, что им обычно надо не просто записать html, а получить html-код, сохраняющий форматирование и при этом имеющий минимальный размер.

При этом возможные варианты, заведомо лучшие реализованных, буквально лежат на поверхности. Например, можно было бы переносить в html просто все отличия от базового стиля, неважно, проставлены ли они локально или заданы через пользовательский стиль. Можно было бы вывести диалог с вопросом «что перенести желаете», в котором какая-то более-менее разумная комбинация переносимого уже выбрана. Можно, наконец, оставить вариант, при котором сохраняется html, полностью восстанавливающий исходный текст, но сделать ещё одну команду, которая вырезает при сохранении все вордовские тэги, для тех случаев, когда пользователь хочет получить просто html. Не восстановимый.

Идём дальше. Винамп без спецплагина не запоминает место, где остановилось воспроизведение при закрытии винампа. Аналогичным образом 99% музыкальных центров и проигрывателей не помнят, даже какая песня играла, когда их выключили. Не говоря уже про позицию воспроизведения в этой песне.

И это ещё что – виндовый плеер не запоминает даже плэйлист.

Многие ли пользователи, выключив плеер перед уходом из дома, после возвращения слушают альбом сначала? Подозреваю, крайне немногие. Почему же тогда нельзя сделать очевидное: запомнить место, которое воспроизводилось перед выключением и после включения продолжить с него? Ну ладно, кто-то захочет сначала. Однако для перехода к началу достаточно нажать кнопку «стоп». Для возвращения же к предыдущей позиции надо её, во-первых, весь день помнить, во-вторых, переключиться на нужную песню, в-третьих, на быстрой перемотке найти место, где в прошлый раз остановился. По трудозатратам данные два процесса несравнимы. Но нет, никто из производителей не осиливает запоминание. Наиболее логичное и распространённое действие в результате практически нигде не реализовано.

Музыка ещё ладно. А вот фильм наверняка 99,999% смотрят с места остановки, а не заново сначала. И что бы вы думали? Да, именно так, большинство проигрывателей после выключения не помнят, где мы остановились.

Ровно так же с Вордом, Фотошопом и кучей других программ – ну неужели нельзя запомнить, что было открыто в прошлый раз? Неужели никак нельзя дать возможность восстановить то состояние, на котором вчера всё закрыл? Почему Eclipse и Visual Studio осиливают его запоминание, а текстовые процессоры и программы для дизайна – нет? Там какие-то особые сложности имеются?

Люди за время существования компьютеров додумались, что настройки можно обьеденить в пресеты. Это – удобно. Не надо каждый раз заполнять все поля. Почему тогда половина программ, даже имеющих пресеты, не позволяет сохранить свои? Либо выбирай из готовых, либо заполняй всё сам – запомнить однажды введённое никак нельзя. Почему музыкальные центры позволяют сохранить пресет эквалайзера, но не позволяют сохранить пресет всех настроек разом? Да потому, что разработчики не думают про сценарии пользователя. Они уверены, что это не прибор говорит с пользователем, а пользователь с прибором. Поэтому подстраиваться под прибор должен именно пользователь. А если не хочет, то он – ленивый тупой юзверь.

Смотрим теперь на телевизор.

Лично я, кстати, рекомендую смотреть на него как можно меньше. В идеале антену лучше вообще отключить и пользовать телевизор только как большой монитор.

С чего начинается общение пользователя с телевизором? Ну, что он делает сразу после первого подключения? Настраивает, ядрён батон, программы. Либо совсем вручную, перерывая весь доступный диапазон, либо кнопкой «настроить всё», которая находит не только программы, но и просто какую-то рябь, чуть-чуть отличающуюся от белого шума. После этого пользователь удаляет рябь и дубликаты, а потом расставляет остаток в удобном ему порядке. Такой процесс занимает что-то в районе часа. При этом, сделан он так, чтобы каждое действие отняло возможный максимум времени.

Как надо было бы сделать? По заранее заданной частоте в режиме нон-стоп передаётся список частот, на которых у данного антенного подключения имеются программы, имён этих программ и их порядок. Выбором одного пункта меню пользователь заставляет телевизор прочитать список и трансформировать его в настройки. После этого пользователь только лишь, при желании, меняет порядок программ. Очевидно же. Но не сделано. Настройки давно уже цифровые, а способ общения с телебашней, тарелками и кабельным – чисто аналоговый.

Кстати, про смену порядка. Как её делают нормальные люди: на экран выводится весь список (если длинный, то в несколько столбцов), в нём выбирается элемент при помощи кнопок «вниз» и «вверх», жмётся кнопка «двигать», после этого кнопки «вниз» и «вверх» уже используются для перемещения выбранного элемента по списку.

Теперь как это делают разработчики телевизоров. На экране отображается один элемент списка. С помощью кнопок можно переключиться на следующий. Когда найден нужный, пользователь жмёт спец-кнопку и ему предлагают ввести номер программы, с которой будет поменяна местами выбранная. Более идиотский способ трудно даже придумать. Пользователь мало того, что должен помнить, на какой программе какой канал у него был, но ещё и  вдобавок – где что находится после каждого обмена номерами программ. Более того, пользователь до кучи должен самостоятельно разработать алгоритм сортировки, который приведёт его к желаемому расположению каналов по программам.

Это неплохая задача, надо отметить. Дан ряд чисел:

5, 2, 4, 10, 7, 1, 3, 9, 8, 6

Разработать алгоритм сортировки этих чисел по возрастанию, путём попарного обмена позициями, которые эти числа занимают. Добиться того, чтобы количество перемещений было минимальным.

Есть мнение, что разработчики телевизоров таким образом приучают пользователей к удивительному миру головоломок.

Вероятно, тот, кто изобрёл такой механизм настройки программ, надеялся, что настраивать программы никто и никогда не будет. Ему и в голову не приходило, что настройка будет проводиться минимум один раз для каждого экземпляра телевизора.

Однако приборы, предназначенные для конечного пользователя, не идут ни в какое сравнение с тем, что мыслится как детали приборов. Если на конечного пользователя разработчику просто плевать, то на следующего разработчика в процессе производства, ему плевать с колокольни.

Конечные пользователи должны испытывать безграничное счастье из-за того, что они всего лишь пользуются софтом, который не может запомнить предыдущее состояние, но знать не знают о тех библиотеках, которые использовались в процессе разработки этого софта.

При разработке библиотек даже опытный разработчик подвергается соблазну испытать интеллект других разработчиков. Поэтому он делает API, каждый метод которого требует ввода всех возможных параметров связанных с данным действием. Такой подход называется «гибкость». Пофиг, что 99% пользователей библиотеки будут создавать с её помощью окна ровно двух типов. Всё равно, метод создания окна должен требовать ввода всех возможных параметров. Ещё лучше – и невозможных тоже. Пусть половину позиций занимают нули. Пусть отличное от нуля значение в данной версии библиотеки вообще ничего не поменяет – их всё равно надо вводить. Нельзя просто одной командой создать окно. Надо сначала создать девайс, контекст, подтекст и аусвайс, сообщить как зовут бабушку вахтёра и надо ли на Первое Апреля в углу рисовать смайлик, указать, сколько рамок должно быть у окна, следует ли поручить рисование рамок операционной системе или же сам справишься, какой формы рамки, какого цвета, есть ли смысл в рамках и как звучит слово «рамка» на всех языках планеты Земля. Без всего этого – мало ли, вдруг какой-то параметр останется неучтённым. «Я же не знаю, чего хочет пользователь библиотеки».

Хочется спросить: «если ты не знаешь, чего хочет пользователь библиотеки, зачем ты её вообще пишешь?». Почему так мало разработчиков предоставляют не только самый общий API, но и уже готовые обёртки для наиболее вероятных сценариев использования? Обычно ведь 3-4 сценария охватывают 99% надобностей.

Если нет – есть повод задуматься: «и что же это мы такое написали?».

Ошибки в программном коде встречаются с пугающей неизбежностью и уже мало кто требует предоставлять ему программы, гарантированно лишённые ошибок. Наверно такое вообще невозможно. Как ни крути, а даже сотня тестеров вряд ли проделает с программой всё то, что догадаются с ней проделать миллион пользователей. Однако упомянутые сценарии использования в обязательном порядке пишутся хотя бы на этапе проверки работоспособности кода. Почему эти сценарии не попадают в API? Чтобы библиотека, блин, не была перегружена функциональностью.

За счёт этого функциональностью перегружен код тех, кто эту библиотеку использует. Каждый начинает разработку проекта с написания обёрток к такой вот библиотеки. У 99% пользователей библиотеки обёртки по смыслу совпадают. Однако «мы же не знаем, что нужно потребителю. Вдруг он захочет всё сделать по-другому?». Давайте пойдём дальше в рассуждениях: вдруг потребитель захочет по-другому реализовать вообще всё, что есть в вашей библиотеке? Может, вам вообще ничего не писать? Никто же не заставляет вас полностью скрыть ваш наиболее общий API, просят предоставить наиболее частые сценарии использования. В простой для использования форме.

Но нет, так нельзя. Такое делать – себя не уважать. Умный ведь разберётся и сам. Сам напишет обёртки. А не разобрался – тупой, значит. Ха-ха, не знает как устроен супер-пупер-контекст в вашей программе. Во дурак-то! А я, нет, я – умный. Вона как выпендрился! Никто теперь не догадается, что делает этот пункт меню. Кроме меня. Все, все тупые.

Для созерцания дивных потоков мысли из предыдущего абзаца, не обязательно становиться программистом. Достаточно зайти на русскоязычный форум по программированию и почитать, что там пишут. Главное даже – как пишут. Задаёт человек вопрос: «а как мне написать вложенную аннотацию?». На этот вопрос он получает пару сотен ответов вида «не используй аннотации, лох», «выкинь свою Яву на помойку, пиши на CGDD++--», «ты совсем что ли дурак – азов не знаешь?», «на хрена тебе вообще аннотации?», «а я вот на ассемблере пишу, чего и вам желаю!». И только в одном ответе будет просто написано, как такую аннотацию сделать.

Почему? Потому, что на этом форуме подавляющее большинство участников просто самоутверждается. Они на любой вопрос будут отвечать так.

По счастью, описанное в разделе «поток жалоб» имеет изрядное количество счастливых исключений. В связи с этим остаётся надежда, что в светлом будущем как раз причины жалоб станут исключениями, а правилом будет делать правильно. Даже не только делать – мыслить. Небольшой набор осознанных принципов вполне способен повысить автоматику продукта до уровня, близкого к идеалу.

Поэтому надо сформулировать эти правила.

Читайте в следующих выпусках:

Авто-всё – Набор правил предельной автоматизации – Существуют ли они? – Как ими пользоваться?

История развития интерфейсов – Становятся ли компьютеры ближе к человеку?

Авто-форма – Миф или реальность? – Можно ли делать интерфейсы с помощью одной команды?

Предсказание будущего – Известный программист даёт прогнозы по развитию языков программирования – Не слишком ли много он на себя взял?