lex_kravetski: (Default)

Перед прочтением данной статьи рекомендуется прочитать предыдущие по теме.

 

Ломанёмся, как говорится, с места в карьер.

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

Чтобы лучше понимать, о чём речь, возьмём какой-то условно-синтетический объект для примера. Ну, положим, некоторые сведения о человеке. Объект выглядит примерно так:

Объект )

Тут, конечно, всё предельно просто и прямолинейно, однако всё ведь примерно так и делается. Реальные переменные спрятаны от посторонних глаз, вместо них используются геттеры и сеттеры (То бишь, методы, названия которых начинаются с «get» и «set», а далее содержат имя реальной переменной. Для булевских пропертей иногда вместо «get» используется префикс «is»). Сам объект настолько шаблонен, что скорее всего создавался просто генератором кода.

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

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

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

Итак, есть объект. Рано или поздно нам захочется дать пользователю возможность его заполнять. Поскольку мы не звери, заполнение для пользователя будет дано в виде графического диалога. И выглядеть он будет как-то так:

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

Прикинем, прикинем )

 

Всё про авто-всё

lex_kravetski: (Default)

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

Я делал интерфейсы на Билдере, на MFC, на WinAPI, на Swing, на SWT/RCP и даже на самопальной двумерной библиотеке, содержавшей всего три команды: нарисовать линию, вывести текст и нарисовать прямоугольник с текстурой. Ну и псевдо-интерфейсы а ля «командная строка» тоже имели место быть. Где-то бывало проще, где-то тяжелее, однако в общем и целом постоянно обнаруживалась необходимость в тысячах ненужных по сути строк кода – кем-то уже написанных или тех, которые предполагалось написать мне, но всё равно по сути не нужных.

При разработке интерфейсов программисты до сих пор пишут мегабайты одинакового кода. Того, который уже много раз написан другими. Объединение уже написанного в библиотеки всё более и более высокого уровня не исправляет положение – всё равно на уровне выше библиотеки пишутся мегабайты ненужного.

Тут наверно следует разобраться с тем, что я понимаю под словом «не нужный». Ведь как ни крути, а код интерфейса – нужный код. Без него вроде как ничего не заработает. И оно во многом верно – писать ненужный код нужно. 

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

Однако для более глубокого понимания сути проблемы предлагаю взглянуть на историю развития интерфейсов. Нет, не столько их самых со стороны пользователя, сколько со стороны программиста. Для пользователя-то не так уж и многое поменялось. Для него перемен было ровно три: командная строка, в которую что-то там печаталось, псевдографический интерфейс (таблички, составленные из символов) и современный уже графический-оконный. Для программистов же этапов было гораздо больше и перемены куда как более заметны.

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

Итак, посмотрим.

 

Типа старт: бумажки с дырочками

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

Тут интересно вот что: хранились ли в те времена на перфокартах программы или данные? На первый взгляд, вроде как данные. Вроде как перфокарта для ткацкого станка содержала закодированный узор, что на наш, современный взгляд – совершенно точно данные. Но вот ткацкий станок ничего, кроме описания узора, с перфокарты прочитать не может, поэтому данные для него одновременно и программа же.

Это – важно. Идея о разделении данных и программы для их обработки появилась не сразу. Достаточно долгое время программа и данные были единым, неразделимым целым. Более того, отголоски подобного подхода мы до сих пор наблюдаем. Например, если студенту предложить написать программу для численного решения уравнения

2x2 + 3x – 10 = 0

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

Подозреваю, ровно таким же способом – путём получения негативного опыта – концепция отделения данных от программы для их обработки появилась и у человечества.

Что там греха таить, таким образом появились вообще все идеи.

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

По сравнению с повторным переписыванием алгоритма под каждый новый набор данных, да ещё и таким переписыванием, при котором параметры в численном виде разбросаны по коду (то есть, ошибиться при исправлении – как нечего делать), означенное разделение – очевидный прорыв. Я бы даже сказал, радикальный.

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

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

А что там дальше было? )

 

Желание

Создавать интерфейс, используя логически необходимый минимум команд. То есть, тот минимум, который не вычисляется алгоритмически из общих соображений. Какой он? Скажу неожиданную вещь: в общем случае команда нужна одна – «зафигарить». Остальные – это уже тонкая настройка.

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

 

Всё про авто-всё

 

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

«Он связывал нас не спрашивая» – Пострадавшие от Авто-маньяка делятся впечатлениями с редакцией

Что делать, если поменялся провайдер? – На вопросы отвечает широко известный в узких кругах программист

Конверсия: благо или преступление? – Это смотря с какой стороны посмотреть!

«Свет мой зеркальце, скажи» – Вся правда об отражениях

lex_kravetski: (Default)

В прошлой статье говорилось про общую постановку проблемы. Теперь пришло время обсудить её общее решение.

 

Терминология

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

После своего изготовления продукт поступает от производителя к потребителю, который не обязательно будет конечным потребителем. Вполне возможно, что потребитель воспользуется продуктом как инструментом или компонентом для производства. Инструмент – это то, с помощью чего делают. Компонент – то, из чего делают.

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

 

Законы предельной автоматизации

1. Любой продукт делается для людей.

2. Использующий продукт как компонент ничем не хуже того, кто использует его как инструмент.

3. То, что может быть автоматизировано, должно быть автоматизировано.

4. Наиболее распространённое действие должно требовать минимального количества усилий со стороны потребителя. В идеале – ни одного.

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

6. Каждое действие должно предусматривать значения параметров по умолчанию, если это в принципе возможно.

7. Значения параметров по умолчанию следует пытаться угадать, исходя из контекста и других, уже заданных параметров.

8. Чем более распространено действие, тем меньших знаний о продукте со стороны потребителя оно должно требовать.

 

Разъяснения законов

1. Любой продукт делается для людей.

Первый закон – это основной постулат предельной автоматизации. Он задаёт цель всему процессу и одновременно обосновывает его важность. Действительно, зачастую разработчики забывают, что сделанный ими продукт, он не просто так, а для использования его другими людьми. Так программист считает, что он пишет программу для компьютера. Рабочий – что он делает деталь для автомобиля. Педагог – что он пишет учебник для школы.

Всё так, программа для компьютера и учебник для школы. Однако самое главное, что всё это – для людей. Пользоваться программой будет человек, а не компьютер. Компьютер будет её только исполнять. Учебник будут читать школьники, а роль школы в том, чтобы этот учебник распространить. И так далее.

Когда производитель забывает о мысли «продукт – для человека», продукт очень часто получается к употреблению не годным. Хотя формальному своему определению он может вполне соответствовать. То есть, программу таки компьютер исполнить сможет.

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

 

2. Использующий продукт как компонент ничем не хуже того, кто использует его как инструмент.

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

Такой подход часто исповедуется разработчиками программных библиотек. Библиотека – компонент программы, а не конечный продукт, из-за этого кажется, что библиотеку причёсывать не надо. А если использующему библиотеку она кажется неудобной, то это только потому, что «ламер не разобрался». Со временем программисты к такому подходу привыкают и машинально переносят его на конечного пользователя тоже. «Это же только конченные дебилы не знают, что когда вон в тех дебрях настроек стоит вот эта галочка, то мой мощный текстовый процессор игнорирует нажатия всех клавиш». «Даже барану должно быть понятно, что для открытия файла при запуске моей программы из консоли надо ввести –opnfl /a –mode rd-wr dt=cur». «В инструкции же всё написано – на 2053-ей странице в левом нижнем углу».

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

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

При изготовлении продукта следует думать не только о конечных пользователях. Каждый следующий работник производственного конвейера – тоже пользователь. И он ничем не хуже конечного потребителя.

Э, а остальные шесть законов?! )

 

Всё про Авто-всё

 

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

Кинг-конг, Годзилла или Авто-форма – Кто кого заборет в честном бою?

От чёрного прямоугольника к нагромождению штрихов и красок – Как разработчики интерфейсов переплюнули сюрреалистов

«Я умею читать объекты» – Интервью с Авто-формой

Британские учёные разработали кнопку «зафигарить» – Миллионы дизайнеров ожидают увольнения

lex_kravetski: (Default)

 

Про название

 

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

 

 

Введение

 

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

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

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

 

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

 

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

 

 

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

 

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

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

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

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

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

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

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

 

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

 

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

 

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

 

Ещё жалоб в студию! )

 

 

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

 

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

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

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

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

Profile

lex_kravetski: (Default)
lex_kravetski

April 2017

S M T W T F S
      1
2 345678
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 22nd, 2017 06:57 pm
Powered by Dreamwidth Studios