Что такое дедукция?

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

Пример дедуктивного рассуждения в логике

Дедукция известна со времен Аристотеля. Именно Аристотель рассматривал умозаключения с посылками и выводом.

Пример дедуктивного умозаключения:

Все люди смертны.
Сократ человек.
Следовательно, Сократ смертен.

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

Применение дедуктивных рассуждений в повседневной жизни

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



Представим, как бы рассуждал сыщик. Допустим мы находимся вне города и видим человека, который несёт рыбу.

Исходное знание человек несет рыбу. Далее наше рассуждение выглядит так. Мы можем предположить, что, первое, человек купил эту рыбу в магазине. Но магазина рядом нет, так что скорее всего он взял рыбу у кого-то или поймал ее сам. Если человек поймал рыбу сам, то тогда у него должно быть удочки с собой. Но удочки у него нет. Тогда, возможно, удочка осталась на берегу или у него вовсе не было удочки. Если у этого человека нет удочки вовсе, то он взял рыбу у кого-то. Сыщику достаточно будет посмотреть, нет ли на берегу удочки. Если она есть то этот человек сам выловил рыбу. Если ее нет, то человек взял у кого-то эту рыбу.
Это пример дедуктивного рассуждения: есть исходное общее знание, и далее мы рассматриваем частности и детали.

Пример дедуктивного рассуждения при принятии решения

У Андрея сейчас уровень английского языка чуть ниже среднего. Он хочет достичь среднего уровня английского языка (B1) через 3 месяца. Рассмотрим рассуждения Андрея.
Если я буду заниматься самостоятельно, то мне нужно будет самому искать учебные материалы, упражнения и выполнять задания без проверки преподавателя. Тогда я должен буду запланировать 3 часа в день на занятия английским, чтобы через 3 месяца достичь уровня B1.

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

Заниматься самостоятельно или заниматься с преподавателем

Заниматься самостоятельно

Запланировать 3 часа на занятия английским языком в день.
Я достигну уровня B1 через 3 месяца.

Заниматься с преподавателем

Запланировать 2 часа в день на занятия английским языком.
Я достигну уровня B1 через 3 месяца.

Я достигну уровня B1 через 3 месяца.

Как дедуктивный метод помогает в жизни?

1. Цель определяется заранее.
2. Рассматриваем варианты того, как вы ее можете достигнуть.
3. На принятие решения не оказывают влияние эмоции.
4. На принятие решения не оказывают влияния советы третьих лиц.
5. Вы сами выбираете направление, которое вам позволит прийти к цели.
6. Вы можете выбрать наиболее экономичное (в денежном или время затратном плане) решение.

Применение дедуктивного метода в преподавании и аналитической работе

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



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

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

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

Применение дедуктивного метода в когнитивно-поведенческой психологии

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



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

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

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

Недостатки дедуктивного подхода

Рассмотрим на примере использования этого метода в преподавании иностранного языка.

1. Начинать урок с презентации грамматики может быть трудоемким и сложным для некоторых студентов, особенно начального уровня. Они могут не знать специфической терминологии для объяснения грамматики. Кроме того, они могут не понимать некоторые более простые грамматические конструкции.
2. Объяснение грамматики переводит центр внимания на преподавателя, тем самым уменьшая количество времени, которое можно использовать на взаимодействие студентов друг с другом. Тем самым, не уделяется основное время урока на отработку навыков общения и использование языка в речи.
3. Объяснение не так хорошо воспринимается, как другие формы презентации материала, как например наглядная демонстрация.
4. Такой подход может внушить студенту мысль, что знание языка это просто знание некоторого набора правил.

Дедуктивный метод имеет множество преимуществ, рассмотрим некоторые из них.

Преимущества дедуктивного метода

1. Он сразу достигает поставленной цели, и поэтому может быть экономным в плане финансовых затрат. Многие правила, в особенности правила грамматической формы, может быть просто и быстро объяснено, затем выявляться из примеров. Это дает больше времени на практику и применение правил.
2. Дедуктивный метод признает знания и зрелость студентов, а также роль когнитивных процессов в освоении языка.
3. Он оправдывает ожидания многих студентов от процесса обучения, в особенности тех студентов, у которых аналитический стиль изучения нового материала.
4. Он позволяет преподавателям иметь дело с различными особенностями языка в процессе урока вместо того, чтобы предполагать заранее те вопросы, которые могут возникнуть и готовиться к ним до урока.

Литература:

Thornbury S. How to Teach Grammar. Pearson Education Limited, 1999
Johan van Benthem, Hans van Ditmarsch, Jan van Eijck, Jan Jaspars. Logic in Action, 2016
Фотографии взяты из открытого источника www.pexels.com

Грубо говоря, очевидно, что некоторые виды форматирования лучше других.
Стив Макконелл, Совершенный код.

Эта статья об особенностях человеческого зрения и о том, как знание этих особенностей может помочь нам улучшить объективную удобочитаемость наших программ.

Содержание

• Вступление
• Особенности зрения человека
• Как мы читаем обычные тексты
• Понимание программ
  
  • Когнитивные модели понимания программ
  • Концепции и терминология
  • Модель понимания от общего к частному
  • Понимание от частного к общему
  • Оппортунистическая и систематические стратегии
  • Специфика чтения текста программы
  • Роль идентификаторов
• Основные принципы форматирования
  
  • Формирование визуальной структуры
  • Длина строки
  • Имена
  • Пробелы
  • Расстановка фигурных скобок
• Заключение

Вступление

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

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

Соотношение времени чтения и написания кода превышает 10:1. Из-за столь высокого соотношения наш код должен легко читаться, даже если это затрудняет его написание.
Роберт Мартин, Чистый код: создание, анализ и рефакторинг.

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

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

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

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

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

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

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

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

Давайте посмотрим подробнее, на то, что нам известно о механизмах восприятия человеком зрительной информации, чтении текстов вообще и чтении и восприятии текстов программ.

Особенности зрения человека

Поле зрения

Поле зрения человека достаточно велико: 55 вверх, 60 вниз, 90 наружу (то есть суммарное поле зрения двумя глазами 180) и 60 внутрь. Однако внутри этого поля острота зрения и цветовосприятие распределены неравномерно: острота зрения порядка 1' достигается в области фовеа, формирующей ~2 центрального (фовеального) зрения, но она не так хороша в парафовеальной области (которая покрывает 5 в обе стороны от точки фиксации) и еще хуже на периферии.

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

Рисунок 1. Поле зрения правого глаза человека. Оранжевое пятно место проекции слепого пятна глазного дна. (оригинал)

Амбьентное и фокальное зрение

В современной нейропсихологии существует представлении об амбьентной (от фр. ambiance = окружение) и фокальной зрительных системах. В то время как первая, эволюционно более древняя, ответственна за динамическую пространственную локализацию, вторая занимается идентификацией объектов.

Таблица. 1. Сравнительные признаки фокальной и амбьентной систем

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

Обследование окружения и выбор объектов для детальной обработки осуществляется с помощью движений головы и тела, на которые накладывается тонкий узор движений глаз. Наиболее известной их разновидностью являются саккады чрезвычайно быстрые (~500/сек) скачки баллистического типа, меняющие положение глаз в орбите и позволяющие выделять фрагменты сцены для последующей фиксации.

Рисунок2. Репродукция картины И. Е. Репина и запись движений глаз испытуемого.

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

Рисунок 3. Однородные и неоднородные супербуквы из экспериментов Дэвида Навона.

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

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

Законы перцептивной организации

Интересной особенностью нашего зрения является способность воспринимать группу объектов как единое целое. Так на изображении ниже мы видим собаку, а не просто хаотический набор пятен:

Рисунок 5. Далматинец

А здесь мы ясно различаем квадрат и круг:

Рисунок 6. Фигуры из точек.

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

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

Рисунок 7. Треугольники, меняющие ориентацию.

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

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

Рисунок 8. Варианты организации точек в фигуру.

Гештальтпсихологи также сформулировали 6 принципов перцептивной организации. В соответствии с этими принципами объекты, которые

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

скорее будут восприняты как единое целое, или фигура, а не как разрозненные элементы среды, или фон.

Рисунок 9. Примеры сходства по близости, цвету и размеру.

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

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

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

Асимметрия зрительного поля

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

Так, в сценическом искусстве известно, что существует разница между левой и правой половиной сцены: как только поднимается занавес в начале акта, зрители начинают смотреть в левую сторону сцены. Левая сторона сцены считается более сильной. В группе из двух или трех актеров тот, кто стоит с левой стороны, будет в данной сцене доминировать. Аналогично, зритель воспринимает рисунок, как если бы он свое внимание сосредоточил на левой стороне. Субъективно он отождествляет себя с левой стороной, и все, что появляется в этой части картины, имеет большое значение. Таким образом, кроме естественной точки равновесия в центре визуальной сцены, формируется дополнительный центр в ее левой части.

Как мы читаем обычные тексты

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

Рисунок 10. Типичная картина движений глаз при чтении

Между саккадами наши глаза остаются относительно неподвижными на время фиксаций (fixations) (около 200 300 мс). В течение этого периода мы распознаем видимую часть текста и планируем, куда совершить следующий cкачок.

Порядка 1015% времени читающие переводят свой взгляд назад в тексте (regressions), чтобы повторно прочитать то, что уже было прочитано. С возрастанием трудности текста увеличивается продолжительность фиксаций и частота регрессий, а длина саккад уменьшается.

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

Во время фиксации мы получаем информацию из области видимости, называемой областью восприятия (perceptual span). Размер этой области относительно невелик: в случае алфавитных орфографий (напр. для европейских языков) она начинается от начала фиксированного слова, но не более, чем на 3-4 буквы слева от точки фиксации, и распространяется приблизительно на 14-15 размеров букв вправо от этой точки (суммарно 17-19 букв).

Область идентификации (identification span), то есть область видимости, необходимая для идентификации фиксированного слова, меньше, чем область восприятия и, как правило, не превышает 7-8 размеров букв справа от фиксации (суммарно порядка 10-12 букв).

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

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

В большинстве случаев чтение замедляется (в среднем на 30%) при отсутствии информации о промежутках (между словами). Это вызвано нарушением процессов идентификации слова и перемещения взгляда. Наоборот, добавление информации о промежутках облегчает чтение. Так, существуют данные, показывающие, что при разделении слов в тексте на тайском языке (для людей, которые никогда прежде не читали такие тексты с разделением слов пробелами), чтение осуществляется более эффективно. Аналогично облегчается и чтение длинных составных слов на немецком языке при разбивке их на простые слова с помощью пробелов, несмотря на то, что такое разбиение грамматически некорректно и не встречается в обычном чтении.

Информация о длине слова также играет явную роль в определении того, где должна располагаться точка фиксации. Хотя присутствует некоторая вариативность в том, где внутри слова останавливается взгляд, как правило первая фиксация на слове осуществляется в предпочитаемой точке взгляда (preferred viewing location), где-то на расстоянии 1/4 длины слова от его начала. Когда промежуток между текущим и следующим словами попадает в парафовеальную область, первая фиксация на следующем слове происходит ближе к предпочитаемой точке, чем когда этот промежуток оказывается за ее пределами.

Несмотря на то, что в среднем позиция первой фиксации на слове лежит между началом слова и его серединой, эта позиция может меняться в зависимости от расстояния до предыдущей точки фиксации. Например, если расстояние до целевого слова большое (8-10 размеров букв), положение следующей фиксации сдвигается влево. Соответственно, если расстояние мало (2-3 размера букв), положение фиксации сдвигается вправо.

Позиция первой (и возможно единственной) фиксации на слове лежит между началом и серединой слова для слов длиной 4-10 буквы. Однако для более длинных слов наблюдается тенденция делать первую фиксацию ближе к началу слова и затем вторую ближе к концу слова.

Информационная плотность (или морфологическая структура) слова влияет на продолжительность фиксаций на каждой части слова. Например, было замечено, что если слово было возможно распознать по первым 6 буквам (слова были в среднем длиной около 12 букв), то в общем случае, после первой фиксации в первой половине слова, взгляд переходил к следующему слову; в случаях, когда фиксация во второй части все же осуществлялась, то она была очень короткой. Однако в случае, когда слово могло быть распознано только по его окончанию, первая фиксация была короткой, а вторая, на конце слова, более длинной.

Таблица 2. Приблизительные средние значения продолжительности фиксаций и длин саккад при чтении и поиске

При исследовании визуального поиска установлено, что когда цель находилась в области с небольшим эксцентриситетом (отклонением от центра сцены), она обнаруживалась точно, с использованием одной саккады; когда цель располагалась ближе к периферии, наблюдались саккады в ложных направлениях (до 40% по времени). При сложных задачах поиска глаза изначально направлялись к центру сцены и затем к центрам рекурсивно меньших групп объектов до тех пор, пока цель не была найдена.

Понимание программ

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

Когнитивные модели понимания программ

Концепции и терминология

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

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

Маяк (beacon) это характерный элемент кода, который служит признаком присутствия в нем некоторой структуры. Например, имя процедуры может указывать на реализацию определенной функции.

Правила написания программ (rules of programming discourse) охватывают принятые соглашения, такие как стандарты кодирования и реализации алгоритмов. Эти правила формируют определенные ожидания в сознании программиста.

Модель понимания от общего к частному

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

Понимание от частного к общему

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

Оппортунистическая и систематические стратегии

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

Специфика чтения текста программы

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

Сравнительное исследование линейности чтения программ новичками и экспертами показало, что и те и другие читают код менее линейно, чем обычные тексты. Более того, эксперты читают код менее линейно, чем новички. Авторы предполагают, что навыки нелинейного чтения увеличиваются с опытом.

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

Рисунок 11. Траектории движения глаз двух программистов-экспертов при чтении одного и того же кода.

Перед этими программистами были поставлены разные задачи: так, от первого (рис. слева) ожидали получить ответ, чему равно rect2.area(), второго предупредили, что ему будет задан вопрос относительно алгоритма с возможностью выбрать ответ из списка возможных.

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

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

Второй же испытуемый, по словам экспериментаторов, читал код медленно и методически.

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

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

Авторы описывают следующие базовые типы движений глаз, составляющие более сложные стратегии чтения кода:

Таблица 3. Базовые типы движений глаз при чтении кода.

Роль идентификаторов

Идентификаторы в коде программы часто выполняют роль маяков для планов программирования, поддерживающих ментальные модели более высокого уровня. Идентификаторы составляют примерно 70% исходного кода.

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

Идентификаторы, которые нарушают некоторые правила, приводят к более низкому качеству кода (больше ошибок).

Использование более длинных имен снижает правильность и требует больше времени для запоминания.

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

Рисунок 12. Части траекторий движения глаз при корректном опознании underscore и camelCase идентификаторов, состоящих из трех слов

Основные принципы форматирования

Формирование визуальной структуры

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

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

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

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

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

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

Рассмотрим следующий пример:

Для оценки визуальной структуры проведем тест, аналогичный тесту с прищуриванием (squint test), используемому разработчиками пользовательского интерфейса. Алан Купер в своей книге описывает этот тест так:

Закройте один глаз и посмотрите на экран прищуренным вторым глазом. Обратите внимание на то, какие элементы слишком выпирают, какие стали нечеткими, а какие объединились в группы. Эта процедура часто вскрывает не замеченные ранее проблемы в композиции интерфейса.

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

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

Разбивка по вертикали позволяет исправить этот недостаток:

Результат теста:

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

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

Отступы служат для формирования визуального представления иерархии в структуре программы между элементами, находящимися на разных строках.

Давайте посмотрим на следующий код:

Список аргументов представлен в виде колонки и имеет отступ относительно первой строки. Достаточно ли этого отступа для того, чтобы правильно отобразить логическую структуру программы? Очевидно, что нет.

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

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

При сканировании текста, такое расположение провоцирует движение глаз от результирующей переменной success сразу к столбцу списка аргументов и только потом регрессию к имени функции.

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

Чтобы правильно отобразить логическую структуру этого кода в его визуальное представление, необходимо, чтобы список аргументов имел отступ не относительно начала строки, а относительно начала имени функции:

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

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

Видно, что имя функции и список аргументов формируют сильно связанную область. Однако при использовании двух пробелов для отступа подчиненность списка аргументов относительно имени функции выглядит недостаточно выразительно. Использование четырех пробелов помогает решить эту проблему:

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

Однострочное форматирование

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

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

Выравнивание пар метка: значение

Этот вариант выглядит лучше в том смысле, что в нем спецификация имени метода и список аргументов явно отделены друг от друга. Уже несколько проще поиск в списке аргументов, поскольку каждая пара располагается на отдельной строке и метки выровнены по левому краю.

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

В данном случае можно попробовать исправить последний недостаток, сместив список аргументов влево:

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

Вариант 1: метки и аргументы выровнены влево по отдельности

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

Вариант 2: внутреннее выравнивание

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

Для примера с reticulateSplines код в этом варианте оформления будет выглядеть следующим образом:

Выравнивание является мощным средством оптимизации визуального представления кода, за счет формирования компактных групп в горизонтальном направлении.

Разберем следующий код:

В принципе, каждое отдельное объявление протокола выглядит достаточно удобочитаемым. Однако сказать такое обо всем тексте нельзя: общая структура невыразительна, в ней отсутсвуют явно выраженные массы, которые могли бы притянуть взгляд. В результате в глазах рябит, и есть ощущение монотонности. Чтобы воспринять этот код его можно только читать последовательно и полностью: protocol DataBaseDependent ServiceDependent var dataBase DataBase get set, protocol LocalConfigDependent

Переформатируем его так, чтобы каждое объявление занимало одну строку и выровняем:

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

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

В этом смысле нельзя назвать удачными с точки зрения читаемости конструкции вида:

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

Длина строки

Отсутствие жесткого ограничения справа, не означает, что ограничения нет вообще. Многовековой опыт книгопечатания, и десятилетия опыта, наработанного веб-дизайнерами, сходятся к тому, что оптимальная длина строки, обеспечивающей комфортное чтение составляет приблизительно 45-75 символов.

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

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

• Длинную строку трудно охватить широким взглядом.
• Оценка структуры выражения затруднена из-за того, что эта структура размазана по строке и не формирует явно выраженных компактных визуальных областей.
• Из-за неявно выраженной структуры и увеличения эксцентриситета затрудняется поиск.
• Из-за увеличения расстояния затрудняются переходы от конца строки к началу следующей, и соответственно замедляется чтение.
• Если отодвинуться от монитора с целью уменьшения углового размера строки, чтобы нивелировать некоторые указанные выше проблемы, это затруднит чтение за счет уменьшения размера букв и расстояний между ними. При этом это размер области идентификации и распознавания и размер саккад, измеряемых в буквах, не изменится. То есть, чтение замедлится.
• Большие мониторы не всегда доступны или текст программы может отображаться в области с гораздо меньшей шириной. При этом строка или не помещается в области видимости и требует прокрутки, либо строка разбивается на несколько строк и это, как правило, разрушает структуру программы во всей области видимости.

По ряду объективных причин не всегда можно избежать длинных строк (например, из-за использования длинных идентификаторов, которые мы не в силах изменить). Также в случаях, когда нас не интересует структура выражения (например, при выводе отладочного сообщения в лог программы), использование длинной строки может оказаться даже предпочтительнее структурирования длинного выражения разбивкой его на несколько строк, так как делает этот код менее значимым с точки зрения амбьентного зрения.

В общем же случае, длинные строки, как и длинные идентификаторы, это признак плохой читаемости кода.

Имена

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

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

В идеале, мы хотим распознавать имя с первого взгляда (при первой фиксации). Это значит, что первую оценку оптимальной длины можно заложить как размер области идентификации, то есть 10-12 символов. Особенностью текстов программ, как уже писалось выше является то, что набор допустимых слов в них ограничен, поэтому велика вероятность, что даже в случае более длинного имени мы сможем впоследствии распознавать его по первой части, так что в принципе, даже при длине больше 12 символов нам потребуется лишь одна фиксация. Мы, однако хотим, чтобы при этом это имя помещалось в размер области распознавания (17-19 символов) и оставался некоторый запас, таким образом, чтобы наш мозг имел возможность оптимально спланировать следующую саккаду. Если мы возьмем 4 символа от конца области распознавания, то получим оценку в 13-15 символов.

Допуская в редких случаях две фиксации с угадыванием мы получим оценку в 20-24 символа (13-15 из предыдущей оценки + 7-9 на саккаду внутри слова) .

Взяв середины отрезков полученных оценок получим следующую таблицу:

Таблица 4. Оценки максимальной длины имени.

Эти рекомендации достаточно хорошо согласуются с теми границами, которые приводит в своей книге Стив Макконнелл: 10-16 и 8-20. Теперь мы можем как-то объяснить их.

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

За редким исключением не имеет смысла использовать в именах какие-либо префиксы, описывающие некоторые общие характеристики (например тип) или для различения классов, являющихся частью вашего приложения. Префиксы маскируют смысловую часть имени, в их присутствии позиция первой фиксации на слове при чтении сдвигается влево от оптимальной, они требуют определенных усилий на дополнительный анализ слова. В некоторых случаях они могут изменять значение имени (kBytesPerSec это килобайты в секунду или константа BytesPerSec?).

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

Пробелы

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

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

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

Еще один пример:

После разделения на две группы, добавления пробелов и выравнивания:

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

В случае, когда совокупная длина идентификаторов не превышает размера области распознавания, это требование не является настолько критическим, поскольку все выражение может быть сразу охвачено одним взглядом:

Расстановка фигурных скобок.

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

Далее я буду условно называть эти стили Allman и One Truce Brace Style (1TBS) по названиям наиболее популярных стилей, которые используют соответствующие правила расстановки скобок.

Расположение открывающей скобки в начале отдельной строки в стиле Allman обладает следующими преимуществами:

• Скобка всегда располагается в левой части визуальной области, т. е. в области наибольшего внимания, и при сканировании кода (в котором преобладают вертикальные движения глаз) всегда так или иначе попадают в область фокального зрения. В стиле 1TBS открывающие скобки часто оказываются в правой области кода и попадают лишь в область периферийного зрения, что значительно затрудняет их обнаружение. Другими словами, то что в первом случае происходит естественно и как бы само по себе, в втором требует дополнительных и специальных усилий.
• Облегчено сопоставление открывающей и закрывающей скобок и, соответственно, определение границ обрамленного ими блока кода. Поиск парной скобки требует лишь вертикального перемещения взгляда, на пути его следования от одной скобки к другой нет никакого текста, и поиск происходит в известном направлении до первого символа.
  Действительно, всегда, когда мы видим в тексте закрывающую скобку на отдельной строке, мы знаем, что парная ей открывающая находится выше, а это значит, что основным и естественным направлением поиска её будет поиск вверх.
  При использовании 1TBS, поиск в общем случае требует больших усилий за счет того, что он осуществляется в широком секторе, причем взгляд проходит через текст, который надо анализировать, и который часто содержит вложенные пары фигурных скобок, визуально конкурирующие с целевой.
• Скобка расположена в начале строки, именно там, где мы ожидаем увидеть начало чего бы то ни было, и естественным образом обозначает начало блока кода. В стиле 1TBS из-за своего положения в конце строки открывающая скобка часто перестает играть роль явного визуального маркера начала блока. Более того, в некоторых случаях (напр. повторяющиеся конструкции }else if) закрывающая скобка предыдущего блока оказывается в начале строки, содержащей конструкцию, предваряющую новый блок, и тем самым визуально связывается с началом этого блока. Таким образом, её формальное и визуальное значения перестают соответствовать друг другу.
• Расположение скобок на отдельных строках, естественным образом добавляет вертикальные пробелы между синтаксической конструкцией перед открывающей скобкой и обрамленным блоком кода, что, в большинстве случаев, лучше отражает структуру всей конструкции.
• Горизонтальная позиция открывающей скобки в стиле Allman однозначно определяет уровень вложенности, к которому она относится. В 1TBS эта информация отсутствует, так как расположение открывающей скобки в основном определяется лишь длиной строки, расположенной перед ней.

Недостатки 1TBS приводит к тому, что открывающая фигурная скобка перестает в полной мере участвовать в формировании визуального представления кода, стиль провоцирует программиста не разделять блоки кода внутри скобок и окружающие их элементы пустыми строками, и в результате текст программы часто выглядит как один плохо структурированный массивный кусок:

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

Переформатирование этого кода с использованием стиля Allman позволяет получить более приемлемый результат:

Несмотря на то, что в большинстве случаев Allman объективно выигрывает у 1TBS, иногда 1TBS оказывается предпочтительнее. Как правило, это связано с тем, что в таких случаях дополнительное вертикальное пространство, образуемое за счет расположения скобок на отдельных строках в стиле Allman, приводит к тому, что вся конструкция становится визуально разрозненной, теряет свой внутренний ритм и перестает восприниматься как единое целое. И в то же время, при использовании 1TBS, либо смещение открывающей скобки невелико и не оказывает значимого влияние на восприятие кода, либо её обнаружение непринципиально (например, в случае конструкции if, когда и условие, и блок кода занимают по одной строке).

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

Возникает вопрос: в каких случаях допустимо использовать 1TBS? Здесь можно предложить следующие ограничения:

• Открывающая скобка располагается на той же строке, что и начало синтаксической конструкции, частью которой она является.
• Скобка не замаскирована большой массой кода непосредственно примыкающего к ней (в основном сверху).
• Она располагается в левой области текста (области наибольшего внимания).
• Смещение скобки по горизонтали не должно быть большим, так что скобка оказывается в области распознавания (14-15 размеров букв).
• Блок, ограниченный скобками, не содержит вложенных блоков таких, что скобки, ограничивающие эти вложенные блоки, расположены близко к открывающей скобке основного блока и визуально конкурируют с ней.

Таким образом, выбор способа расстановки скобок должен осуществляться в каждом конкретном случае, а формальное следование жестким правилам расстановки рано или поздно приводит к неудовлетворительному результату. Наиболее оптимальным вариантом видится комбинация стилей Allman (как основного) и 1TBS (как вспомогательного, используемого в редких случаях) .

Заключение

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

Основную стратегию оптимизации удобочитаемости можно сформулировать как стремление к более эффективному использованию амбьентого зрения и снижения нагрузки на фокальное.

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

В своей книге о типографике Роберт Брингхерст пишет:

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

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

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

---

) Eye Movements in Reading and Information Processing: 20 Years of Research. Keith Rayner University of Massachusetts at Amherst
) Eye Movements in Code Reading: Relaxing the Linear Order. Roman Bednarik, Bonita Sharif
) Theories, tools and research methods in program comprehension: Past, Present and Future. Margaret-Anne Storey
) An Eye Tracking Study on camelCase and under_score Identifier Styles. Bonita Sharif and Jonathan I. Maletic Department of Computer Science Kent State University
) Achieving Software Quality through Source Code Readability, Phillip Relf
) Relating Identifier Naming Flaws and Code Quality: An Empirical Study. Simon Butler
) Грегори Р.Л. Глаз и Мозг. М.: Прогресс, 1970
) Дэвид Хантер Хьюбел. Глаз, мозг, зрение. Мир, 1970
) Величковский Б.М. Когнитивная наука. Основы психологии познания. Academia, Смысл, 2006
) Рудольф Арнхейм. Искусство и визуальное восприятие. М.: Архитектура-С, 2012
) Ярбус А.Я. Роль глаз в процессе зрения. М.: Наука, 1965
) Eye movements in programming education: analysing the experts gaze. Simon. University of Newcastle, Australia
) Роберт Брингхерст. Основы стиля в типографике. М.: Дмитрий Аронов, 2006
) Макконнелл С. Совершенный код. М.: Русская редакция, 2010
) Saccade size in reading depends upon character spaces and not visual angle. Robert E. Morrison, Keith Rayner, 1981
) Роберт Солсо. Когнитивная психология. СПб: Питер, 2002/2006
) ОСТ 29.12494. Издания книжные для взрослых читателей.

) Алан Купер. Алан Купер об интерфейсе. Основы проектирования взаимодействия. Пер. с англ. СПб.: Символ

Содержание

Введение. О чем эта статья
Цели и дисклеймеры
Часть 1. Хороший продукт
Часть 2. Пользовательский опыт (UX). Что это?
Часть 3. Архитектура выбора
Часть 4. Архитектор выбора
Часть 5. Когнитивные искажения и Пользовательский опыт
Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)
Часть 6. Наши дни
Часть 7. Не только искажения
Часть 8. Эпилог
Часть 9. Материал, качественно дополняющий эту статью

Введение. О чем эта статья

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

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

В какой-то момент своей жизни я перепрофилировался из технического специалиста в IT-сфере, коим я проработал около 6 лет (LAN/WAN/DevOps/InfoSec), в Product Manager-а. Моей основной деятельностью на этой должности является анализ ожиданий и принятых решений пользователей с целью создания более комфортного и желанного продукта.

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

Цели и дисклеймеры

Изложенный здесь материал лучше всего будет понятен опытным специалистам в IT-сфере, занимающимися разработкой и дизайном ПО на регулярной основе. Тем не менее, пользу от этого материала почерпнет любой читатель вне зависимости от рода деятельности.
Цели, которыми я задаюсь в этой статье выглядят так:

• показать четкие доказательства важности глубоких знаний в психологии для работы в качестве менеджера по продукту;
• дать определение понятию UX (Пользовательский опыт) с позиции психологии и поделиться наиважнейшим источником знаний для создания качественного UX;
• показать механизм оценки грамотности продакт менеджеров (и не только);
• побудить инвесторов больше инвестировать в продукты, в основе которых лежит когнитивная психология и поведенческая экономика;
• предоставить продакт менеджерам дополнительные аргументы в поддержку их идей, которые, часто являясь верными, увы, блокируются техническими специалистами из-за непонимания полной картины и технического склада ума;
• показать с другого угла скучные исследования, которые пылятся на полках библиотек, акцентируя чрезвычайную важность этих материалов для будущего разработки ПО;
• побудить психологов и экономистов взглянуть в сторону продакт менеджмента как возможной опции смены карьерного направления. Мир IT нуждается в вас гораздо больше, чем в диванных аналитиках и псведо-менеджерах с MBA и PMP.

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

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

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

Часть 1. Хороший продукт

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

Итак, чуть выше я убрал вопросы про рынки, конкурентов и целесообразность продукта, потому что я исхожу из того, что качественный продукт это, прежде всего, продукт без внутренних противоречий. Такой продукт идеально связан как идеологическими его составляющими (история создания, его миссия, все использованные изображения, текстовые и печатные материалы используемые для его разработки и продвижения и прочее), так и техническими (back end, пользовательский интерфейс, элементы взаимодействия и дизайн, бизнес цвета, инструкции для работы службы поддержки клиентов, tone of voice of the company и много другого).

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

• неудачный тайминг (изменилась коньюнктура на рынке, люди еще не осознали всю серьезность проблемы, решаемой продуктом и т.п.);
• человеческий фактор (утечки внутри компании, уборщица, опрокинувшая ведро рядом с серверами в день релиза и т.п.);
• слабые управленческие навыки руководства (основатели компании слишком поздно начали обсуждать распределение прибыли, что создало конфликты; чрезмерный нажим на команду разработчиков повлек массовые увольнения и сорвал переговоры об инвестировании и пр.)
• банальное невезение, важность которого повально игнорируется как новичками, так и экспертами в бизнесе (Черные Лебеди Н. Нассима Талеба).

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

Часть 2. Пользовательский Опыт (UX). Что это?

Так как на данный момент понятие UX гораздо чаще относят к UI дизайну, моим оппонентом в обсуждении данного вопроса будет Джо Натоли. Джо ветеран-дизайнер с опытом работы более 30 лет, один из самых популярных в мире IT экспертов по UXD (User Experience Design), автор ряда книг, а также самых популярных видео-курсов по UX на Udemy. Натоли провел более тридцати лет консультируя по вопросам дизайна пользовательского опыта (UXD) компании из списка Fortune 100, 500 и правительственные организации. На своем вебсайте он называет себя User Experience Evangelist, значит, я могу ссылаться на его утверждения, высказанные публично в его книгах и видеоуроках.

В одном из своих уроков, где господин Натоли объясняет понятие User Experience, он ссылается на Питера Мерхольца:

Питер Мерхольц, который является деловым партнером Джесси Джеймса Гарретта (автора термина Пользовательский опыт и книги Элементы пользовательского опыта Библии UX всех времен), говорит, что пользовательский интерфейс (UI) является компонентом пользовательского опыта. Но есть гораздо больше, и это гораздо большее включает в себя вещи, которые имеют отношение к когнитивной науке. Это связано с людьми: что они хотят, что им нужно, что они хотят использовать и почему они реагируют на вещи так, как они реагируют.

Другой UXD эксперт Билл ДэРушэ (Старший продакт менеджер / Workflow Experience Lead at Zendesk). В обсуждении UXD говорит следующее: Для UXD даже не нужен экран. UXD это любое взаимодействие с любым продуктом, любым элементом, любой системой .

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

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

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

Итак, практически все UXD эксперты сходятся во мнении, что UX это понятие, выходящее широко за рамки интерфейсов. Их общее мнение сводится к тому, что UX это фактический опыт, получаемый пользователем при его интеракции с продуктом/компанией.

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

Часть 3. Архитектура Выбора

Понятие архитектура выбора популяризировалось после совместного труда Ричарда Талера и Касса Санстейна над Теорией Подталкивания. Вместе они написали книгу Подталкивание (англ. Nudge Theory), которая позволила множеству разных специалистов, ответственных за создание выбора для пользователей, взглянуть на свою работу под новым углом. Чтобы читатель понимал значимость вышеуказанных персон, приведу здесь их краткое описание:

Касс Санстейн со-автор теории подталкивания. После выхода книги Подталкивание президент Обама предложил Санстейну место в Отделе информации и регуляторной политики. Это дало исследователю широкие возможности внедрять идеи психологии и поведенческой экономики в работу правительственных учреждений. 10 сентября 2009 года Санстейн был назначен на пост главы OIRA, которое является частью Административно-бюджетного управления Администрации президента. OIRA осуществляет надзор за реализацией государственной политики и рассматривает проекты нормативных актов. Пост главы OIRA считается одним из наиболее влиятельных, учитывая его возможность влиять на тексты принимаемых законов. СМИ неофициально называют этот пост regulatory czar. OIRA Санстейн возглавлял до 21 августа 2012 года.

В августе 2013 года Санстейн вошел в состав комиссии по надзору за АНБ (англ. Review Group on Intelligence and Communications Technology). Кроме него в комиссии еще два бывших работника Белого Дома: крупейший специалист по контртерроризму и кибервойнам Ричард Алан Кларк и бывший заместитель директора ЦРУ.

Ричард Талер автор Теории Подталкивания, лауреат премии по экономике памяти Альфреда Нобеля 2017 года за вклад в область поведенческой экономики. При правительстве Великобритании было создано новое подразделение, чья цель применять принципы поведенческой науки к решению государственных задач. Официальное название подразделения Группа поведенческого инсайта, но чаще и в правительстве, и за его пределами ее называют Группа подталкивания. Талер является одним из советников этой группы.

Итак, эти господа много лет работали над теорией, в которой тщательно описали как можно подтолкнуть человека к определенному выбору, используя когнитивные искажения (о них мы поговорим совсем скоро). Идея и описанные методы настолько понравились руководствам разных стран (не только США и Англии), что были созданы специальные гос.подразделения с целью редактирования законопроектов для подталкивания граждан к более здоровому образу жизни и более здоровой пище не ограничивая их в выборе.

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

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



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

Часть 4. Архитектор Выбора

Понятие Архитектор выбора ввели Санстейн и Талер, описав его следующим образом:
Архитектор выбора это тот, кто отвечает за организацию контекста, в котором человек принимает решения.

Талер и Санстейн доказывали эффективность подталкивания на примере принятия решений при разработке законопроектов. В таком контексте, работа архитектора выбора крайне сложна, так как на него налагаются колоссальные юридические и моральные ограничения.

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

В такой компании несложно понять, кто является архитектором выбора. Это тот, кто занимается организацией контекста, в котором человек (пользователь) принимает решения в приложении, либо просто Product Manager.

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

Часть 5. Когнитивные Искажения и Пользовательский Опыт

Итак, мы дошли до основного материала статьи.

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

Для структурирования материала я использовал Кодекс когнитивных искажений, категоризированный и структурированный Бастером Бэнсоном в 2016м году (по ссылке выше дизайн Джона Манукяна III). Помимо новой формы презентации искажений, к каждому из них я добавил пример использования в разработке программного обеспечения, а в некоторых случаях- в управлении командой. Были учтены самые современные практики по управлению командами и компаниями (PMP, PMI ACP), а также разработке продукта.

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

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

Итак, как верно заметил Бастер Бенсон, суть изложенных когнитивных искажений в том, чтобы помочь нам решить 4 проблемы:

• Работа с большим объемом данных. Когда много информации;
• Расплывчатость, недостаточность данных. Когда не хватает смысла;
• Недостаточно времени. Когда быстро реагируем;
• Разные приоритеты по информации. Когда запоминаем и вспоминаем.

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

#1 Эвристика доступности [P]
Процесс, при котором человек оценивает частоту или вероятность события по легкости, с которой примеры или случаи приходят на ум, т.е. легче вспоминаются.

В разработке приложений понимание этого искажения необходимо для последовательного проектирования интерфейсов, дизайна контента и коммуникации с пользователем. Если действие, которое нам нужно, чтобы пользователь совершил, ассоциируется у него с чем-либо негативным (особенно, если это освещается или освещалось в СМИ не так давно), вероятность того, что действие будет совершено сильно снижается. Понимание этого позволяет проектировать контент (текст, изображения и т.д.), так, чтобы он ассоциировался у человека только с тем, что нам нужно. Это же искажение позволяет нам задуматься над текущей коньюнктурой в мире и на рынке, чтобы выбрать наиболее удобную тональность наших сообщений.

Другой пример: биткоины и разного рода ICO. Тема криптовалют так часто негативно форсировалась в СМИ, что в какой-то момент инвесторы просто решили избегать всего, что с этим связано, не вдаваясь в детали. Простые же пользователи поняли, что их ослепленность повышенной волатилностью этих рынков не привела ни к чему хорошему. Хайп по этой теме сошел на нет, а множество действительно качественных блокчейн-проектов столкнулись с серъезными сложностями в развитии из-за сильно искаженной репутации всего, что ассоциируется с блокчейном, биткоином и крипто в целом.

Последний пример это то, что я выбрал тему проектирования ПО и блокчейн технологий для описания эвристики доступности. Первая тема очевидна для меня в силу моей профессии (product manager), вторая же тема просто с легкостью пришла мне на ум, когда я задал себе вопрос: Какое направление в IT было полно хайпа, а потом быстро сошло на нет?.

#4 Эффект знакомства с объектом [P]
Психологический феномен выражения симпатии к объекту только на основании имеющегося знакомства с ним. Чем чаще человек видит кого-то, тем приятнее и привлекательнее ему кажется этот человек.

Важно подчеркнуть, что речь идет не только о людях, а об объектах вообще.
Предположим, у нас есть успешное приложение, которое мы хотим продвинуть в Испании. Если мы используем в наших цифровых промо-материалах описание нашего приложения в цветах Испанского флага (ненавязчиво, конечно), это даст ощущение знакомого у испаноязычных читателей. Другой пример мы размещаем очень блеклое, монохромное изображение Саграда Фамилия на фон белой страницы, на которой на испанском описываются преимущества нашего приложения. Если в текст добавить величественные, высокопарные слова вкупэ с фоновым изображением, они вполне дадут эффект знакомства и повысят вероятность конвертации потенциальных пользователей в фактических.

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

#6 Забывание без подсказок [P]
Является неспособностью вспомнить воспоминание из-за отсутствия стимулов или сигналов, которые присутствовали во время кодирования памяти.

В контексте приложения мы можем использовать наши знания об этом искажении с целью напоминаний пользователю о том, что он может сделать с системой.

Приведу простой пример на онлайн тотализаторе, где множество пользователей делают ставки. Очевидно, что средний пользователь как выигрывает, так и проигрывает. В интересах бизнеса правильно будет поддержать такого пользователя в тот сложный момент, когда он все проиграл. Так как в сознании игрока, который пережил серию поражений одни поражения, система может напомнить ему о целом ряде побед по некоему паттерну, оживив в нем всю ту серию хороших воспоминаний, которые он испытал. Это может быть сделано ненавязчиво, сообщением типа Уважаемый %username%, мы просто хотели напомнить вам о невероятно успешной серии ваших побед, продлившейся три дня подряд на играх %game_names%. Навязчиво? Возможно. Изменим сообщение на Вы попали в топ 20% наших игроков, благодаря вашей серии побед в %game_name%!. Уже не так навязчиво, это уже статистика . Конечно, делать это не этично с точки зрения морали. Поэтому букмекерские конторы и казино, работающие под лицензиями Malta Gaming Authority (MGA), Кюрасао и других, заранее соглашаются, что не будут подталкивать игроков к острым азартным действиям. В любом случае, приведенный пример наглядно иллюстрирует как можно извлечь пользу для бизнеса, зная о такой простой ошибке нашего мозга.

#11 Ошибка базового процента [P]
Это ошибка в мышлении, когда сталкиваясь с общей информацией о частоте некоторого события (базовый процент) и специфической информацией об этом событии, человек имеет склонность игнорировать первое и фокусироваться на втором. Например: люди верят показаниям теста, сигнализирующем о наличии редкой болезни, сразу, не принимая во внимание, что редкая болезнь, вообще говоря, редкая. Либо другой пример: страх террористов и полетов на самолете. Суть в том, что наш мозг склонен преувеличивать частный случай в ущерб статистике.

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

Вы собираетесь запустить процесс дефрагментации диска. С вероятностью 99% операция пройдет успешно.

Вы собираетесь запустить процесс дефрагментации диска. Есть 1% вероятности, что жесткий диск будет уничтожен, а ваши данные безвозвратно потеряны.

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

Когда люди видят 15,800 хвалебных отзывов и 50 крайне негативных отзывов в перемешку с ними, они склонны считать продукт менее ценным, непропорционально тому факту, что негативных отзывов меньше 0.1%.

#13 Эффект юмора [P]
Смешные вещи легче запомнить, чем не юмористические, что может быть объяснено увеличенным временем когнитивной обработки, чтобы понять юмор, или эмоциональным возбуждением, вызванным юмором.

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

Здесь очень важно понять, что речь идет о запоминании юморных вещей, но не о позитивном отношении к ним. Так, если в процессе работы над важным действием (заполнение формы, сохранение данных), пользователь попадает на страницу ошибки (500 (Internal server error), 502 (Bad gateway), 503 (Service unavailable), 504 (Gateway timeout) ), то юмор типа Хо хо! Наши пираты работают над ошибкой и скоро все будет восстановлено! будет не к месту. В этом случае юмор будет замечен, запомнен, и, вероятнее всего, вызовет гнев пользователя так, что это событие запомнится лучше. Если подобное событие произойдет несколько раз за месяц, в соответствии с эвристикой доступности, в следующий раз подумав о качестве нашего продукта пользователь с высокой вероятностью даст негативную оценку. Даже если в 99% случаев приложение справлялось с задачей (ошибка базового процента).

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

#21 Ошибка различения [P]
Это тенденция рассматривать два варианта как более отличительные при оценке их одновременно, чем при оценке их отдельно.

Понимание этой ошибки дает нам возможность по-разному подходить к разработке информационной структуры для нашего приложения. К примеру, если мы хотим, чтобы пользователь четко видел отличия одного сервисного плана от другого, мы можем поместить сервисные планы в ряд с указанием характеристик и цены каждого (вы видели такое на многих вебсайтах в разделе Цена). Если же нам нужно, чтобы пользователь считал наши сервисные планы почти одинаковыми (не важно по какой причине), тогда мы можем вместо размещения их горизонтально в таблице, разместить их вертикально друг под другом. Это не позволит пользователю одновременно оценивать отличия сервисных планов, т.к. придется скролить страницу, и тем самым повысится вероятность того, что мы добъемся своей цели. Эта ошибка также является одной из причин, по которой онлайн тотализаторы и разного рода казино не показывают сумму депозита, выигрыши и проигрыши на одной странице. Это удобно для пользователя, но не отвечает бизнес целям проекта, т.к. пользователь будет придавать бОльшее значение различиям между победами и поражениями. При этом не важно, чему он придаст бОльшее значение. Сам факт того, что у пользователя появятся чувства и мысли, которые не поддаются контролю, создаст риски для бизнеса.

#36 Пренебрежение вероятностью [P]
Когнитивное искажение, согласно которому человек склонен к игнорированию малых вероятностей при принятии решений в условиях неопределенности. Небольшие риски обычно либо полностью игнорируются, либо сильно недооцениваются. Континуум между крайностями игнорируется. Как объясняет Рольф Добелли, причина, по которой это происходит, заключается в том, что мы не обладаем интуитивным пониманием риска и поэтому плохо различаем разные угрозы. По сути, чем более серьезна угроза и эмоциональнее тема (напр. Радиоактивность), тем менее обнадеживающим представляется снижение риска.

Использование этого искажения ежедневно приносит сотни миллионов долларов разным казино и тотализаторам по всему миру. Это искажение также является причиной, по которой мы склонны нажимать на Я принимаю условия лицензионного соглашения по факту его не прочитав. Понимание этого искажения позволяет компаниям доносить важную информацию до пользователей в такой форме, при которой он с высокой вероятностью проигнорируют риск. Либо, наоборот, мы можем подтолкнуть пользователя к нужным нам действиям используя специфические формулировки.

К примеру, зная что наши пользователи игнорируют вероятность полной потери данных, мы можем подтолкнуть их к созданию бэкапов сообщением вида Уважаемый %user_name%, в последний раз вы создавали бэкап ваших данных 571 день назад. Мы настоятельно рекомендуем создать бэкап чтобы избежать риска полной безвозвратной потери ваших данных.. Здесь мы ничего не говорим о вероятности потери. Она могла постоянно быть равной 0.1%, но написав сообщение с призывом к эмоциям (полной безвозвратной потери ваших данных) и конвертируя условные 19 месяцев в 571 день, мы с большей вероятностью добьемся действия пользователя (бэкап системы).

---

Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)

---

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

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

В завершении, я бы хотел рассказать об ошибке GI JOE задокументированной профессором Лори Сантос буквально несколько лет назад. Ошибка касается широко распространенного утверждения, что знать это уже пол дела, что, однако, не имеет научных оснований и является ложным утверждением. На самом деле, одного лишь знания недостаточно, чтобы изменить модель нашего поведения. Настоящие перемены невозможны без наших целенаправленных действий. Вы можете выучить наизусть все когнитивные искажения и механизм их работы, но, если вы не меняете модель своего поведения под полученными знаниями, ценность ваших знаний снижается. Более того, подобное знание не будет крепким, вам придется регулярно возвращаться к таблице и повторять написанное, чтобы не забыть. Если же вы не только поймете, но и предпримите определенные действия для усвоения материала, изменения вашего образа мыслей, вашей жизни, тогда самые лучшие решения по продукту, удивительным образом станут для вас крайне очевидными.

Часть 6. Наши дни

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

На данный момент, взглянув на рынок и на требования к продакт менеджерам лучших компаний, можно обнаружить описания и опросники, на которые ответит почти каждый, кто прошел PMI-ACP. По сути, отсутствие четкого понимания роли Product Manager-а приводит к тому, что на них вваливаются обязанности Project Managerов, Scrum Master-ов, и других.

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

Полагаю, с США дела обстоят лучше, т.к. развитие продакт менеджмента идет именно оттуда.

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

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

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

Часть 7. Не только искажения

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

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

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

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

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

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

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

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

Без внимания к деталям, невозможно добиться высокого качества.

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

Часть 8. Эпилог

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

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

Попробую объяснить иначе. Вне зависимости от идеологической составляющей вашей жизни, вашего стиля и публичного образа, вы можете в любой момент записаться на курсы по SCRUM, изучить этот фреймворк, почитать о нескольких других, понять идеи Agile и устроиться работать проект менеджером в какую-то компанию. Вы также можете пройти пару онлайн курсов и подтянуть ваши знания по front-end и back-end программированию, понять принципы работы баз данных, и это займет у вас буквально месяц. Еще за месяц вы можете сами выучить HTML и CSS, поиграть с разметкой, собрать несколько макетов и понять общую идею работы Javascript.

По сути, вы можете месяца за три собрать достаточно знаний для понимания технической составляющей проекта, и этого более чем хватит для начинающего продакт менеджера. Для понимания трендов вы можете скачать самые последние приложения, пройти по списку самых популярных онлайн платформ, зарегистрироваться на producthunt, betalist, techcrunch и всегда быть в курсе происходящего. Новостной информационный пробел легко восполнить регулярно читая Google News и hackernoon.

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

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

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

Завершить статью я хочу провокационной мыслью.

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

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

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

Большое спасибо за проявленный интерес.

Искренне надеюсь, что эта статья дала вам пищу для размышлений.

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

Также я всегда открыт для обсуждения новых идей. Чем амбициознее, тем лучше. Пишите.
Буду рад помочь всем, что в моих силах.

Часть 9. Материал, качественно дополняющий эту статью

• Даниел Канеман Думай медленно Решай быстро;
• Николас Нассим Талеб Черный Лебедь;
• Касс Санстейн и Ричард Талер Подталкивание;
• Ричард Дэвидсон Как эмоции управляют мозгом;
• Михай Чиксентмихайи Поток;
• Джим Коллинз От хорошего к великому;
• Jesse James Garrett The Elements of User Experience (2nd Edition);
• William Lidwell Universal Principles of Design;
• James Clear Atomic Habits;
• Erin Meyer The Culture Map;
• Joe Natoli UX Design Fundamentals Udemy Video;
• Joe Natoli UX & Web Design Master Course: Strategy, Design, Development Udemy Video;

Эта статья была написана в период объявленного карантина из-за пандемии коронавируса (COVID-19) в Армении, г. Ереван. Я очень рад, что статья оказалась полезна многим людям, которые успели ознакомиться с разными частями написанного материала в период моей работы над ней.

Оригинал статьи
Английская версия

По любым вопросам и предложениям пишите, буду рад помочь: alexanyanwolf@gmail.com / www.linkedin.com/in/alexanyan / www.facebook.com/AlexanyanWolf