Как проектировать: Создание архитектуры программы или как проектировать табуретку / Хабр

Содержание

Создание архитектуры программы или как проектировать табуретку / Хабр

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

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

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

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

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

Гибкость системы. Любое приложение приходится менять со временем — изменяются требования, добавляются новые. Чем быстрее и удобнее можно внести изменения в существующий функционал, чем меньше проблем и ошибок это вызовет — тем гибче и конкурентоспособнее система. Поэтому в процессе разработки старайтесь оценивать то, что получается, на предмет того, как вам это потом, возможно, придется менять. Спросите у себя: «А что будет, если текущее архитектурное решение окажется неверным?», «Какое количество кода подвергнется при этом изменениям?». Изменение одного фрагмента системы не должно влиять на ее другие фрагменты. По возможности, архитектурные решения не должны «вырубаться в камне», и последствия архитектурных ошибок должны быть в разумной степени ограничены. «Хорошая архитектура позволяет ОТКЛАДЫВАТЬ принятие ключевых решений» (Боб Мартин) и минимизирует «цену» ошибок.

Расширяемость системы. Возможность добавлять в систему новые сущности и функции, не нарушая ее основной структуры. На начальном этапе в систему имеет смысл закладывать лишь основной и самый необходимый функционал (принцип YAGNI — you ain’t gonna need it, «Вам это не понадобится») Но при этом архитектура должна позволять легко наращивать дополнительный функционал по мере необходимости. Причем так, чтобы внесение наиболее вероятных изменений требовало наименьших усилии.

Требование, чтобы архитектура системы обладала гибкостью и расширяемостью (то есть была способна к изменениям и эволюции) является настолько важным, что оно даже сформулировано в виде отдельного принципа — «Принципа открытости/закрытости» (Open-Closed Principle — второй из пяти принципов SOLID): Программные сущности (классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации.

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

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

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

Тестируемость. Код, который легче тестировать, будет содержать меньше ошибок и надежнее работать. Но тесты не только улучшают качество кода. Многие разработчики приходят к выводу, что требование «хорошей тестируемости» является также направляющей силой, автоматически ведущей к хорошему дизайну, и одновременно одним из важнейших критериев, позволяющих оценить его качество: «Используйте принцип «тестируемости» класса в качестве «лакмусовой бумажки» хорошего дизайна класса. Даже если вы не напишите ни строчки тестового кода, ответ на этот вопрос в 90% случаев поможет понять, насколько все «хорошо» или «плохо» с его дизайном» (Идеальная архитектура).

Существует целая методология разработки программ на основе тестов, которая так и называется — Разработка через тестирование (Test-Driven Development, TDD).

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

Хорошо структурированный, читаемый и понятный код. Сопровождаемость. Над программой, как правило, работает множество людей — одни уходят, приходят новые. После написания сопровождать программу тоже, как правило, приходится людям, не участвовавшем в ее разработке. Поэтому хорошая архитектура должна давать возможность относительно легко и быстро разобраться в системе новым людям. Проект должен быть хорошо структурирован, не содержать дублирования, иметь хорошо оформленный код и желательно документацию. И по возможности в системе лучше применять стандартные, общепринятые решения привычные для программистов. Чем экзотичнее система, тем сложнее ее понять другим (Принцип наименьшего удивления — Principle of least astonishment. Обычно, он используется в отношении пользовательского интерфейса, но применим и к написанию кода).

Ну и для полноты критерии плохого дизайна:

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

При внесении изменений неожиданно ломаются другие части системы. (Хрупкость, Fragility).

Код тяжело использовать повторно в другом приложении, поскольку его слишком тяжело «выпутать» из текущего приложения. (Неподвижность, Immobility).

Не смотря на разнообразие критериев, все же главной при разработке больших систем считается задача снижения сложности. А для снижения сложности ничего, кроме деления на части, пока не придумано. Иногда это называют принципом «разделяй и властвуй» (divide et impera), но по сути речь идет об иерархической декомпозиции. Сложная система должна строится из небольшого количества более простых подсистем, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части не будут достаточно просты для непосредственного понимания и создания.

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

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

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

Масштабируемость (Scalability)

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

Ремонтопригодность (Maintainability)

изменение одного модуля не требует изменения других модулей

Заменимость модулей (Swappability)

модуль легко заменить на другой

Возможность тестирования (Unit Testing)

модуль можно отсоединить от всех остальных и протестировать / починить

Переиспользование (Reusability)

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

Сопровождаемость (Maintenance)

разбитую на модули программу легче понимать и сопровождать

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

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

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

Таким образом, хорошая архитектура это, прежде всего, модульная/блочная архитектура. Чтобы получить хорошую архитектуру надо знать, как правильно делать декомпозицию системы. А значит, необходимо понимать — какая декомпозиция считается «правильной» и каким образом ее лучше проводить?

1. Иерархическая

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

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

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

Типичными модулями первого уровня (полученными в результате первого деления системы на наиболее крупные составные части) как раз и являются — «бизнес-логика», «пользовательский интерфейс», «доступ к БД», «связь с конкретным оборудованием или ОС».

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

2. Функциональная

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

Модуль = Функция + Данные, необходимые для ее выполнения.

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

Модуль — это не произвольный кусок кода, а отдельная функционально осмысленная и законченная программная единица (подпрограмма), которая обеспечивает решение некоторой задачи и в идеале может работать самостоятельно или в другом окружении и быть переиспользуемой. Модуль должен быть некой «целостностью, способной к относительной самостоятельности в поведении и развитии» (Кристофер Александер).

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

3. High Cohesion + Low Coupling

Самым же главным критерием качества декомпозиции является то, насколько модули сфокусированы на решение своих задач и независимы. Обычно это формулируют следующим образом: «Модули, полученные в результате декомпозиции, должны быть максимально сопряженны внутри (high internal cohesion) и минимально связанны друг с другом (low external coupling).«

High Cohesion, высокая сопряженность или «сплоченность» внутри модуля, говорит о том, модуль сфокусирован на решении одной узкой проблемы, а не занимается выполнением разнородных функций или несвязанных между собой обязанностей. (Сопряженность — cohesion, характеризует степень, в которой задачи, выполняемые модулем, связаны друг с другом )
Следствием High Cohesion является принцип единственной ответственности (Single Responsibility Principle — первый из пяти принципов SOLID), согласно которому любой объект/модуль должен иметь лишь одну обязанность и соответственно не должно быть больше одной причины для его изменения.

Low Coupling, слабая связанность, означает что модули, на которые разбивается система, должны быть, по возможности, независимы или слабо связанны друг с другом. Они должны иметь возможность взаимодействовать, но при этом как можно меньше знать друг о друге (принцип минимального знания).
Это значит, что при правильном проектировании, при изменении одного модуля, не придется править другие или эти изменения будут минимальными. Чем слабее связанность, тем легче писать/понимать/расширять/чинить программу.

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

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

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

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

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

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

Делая декомпозицию системы желательно проверять ее качество задавая себе вопросы: «Какую функцию выполняет каждый модуль?«, “Насколько модули легко тестировать?”, “Возможно ли использовать модули самостоятельно или в другом окружении?”, “Как сильно изменения в одном модуле отразятся на остальных?”

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

Для наглядности, картинка из неплохой статьи «Decoupling of Object-Oriented Systems», иллюстрирующая основные моменты, о которых будет идти речь.

1. Интерфейсы. Фасад

Главным, что позволяет уменьшать связанность системы, являются конечно же Интерфейсы (и стоящий за ними принцип Инкапсуляция + Абстракция + Полиморфизм):

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

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

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

Благодаря интерфейсам и полиморфизму, как раз и достигается возможность модифицировать и расширять код, без изменения того, что уже написано (Open-Closed Principle). До тех пор, пока взаимодействие модулей описано исключительно в виде интерфейсов, и не завязано на конкретные реализации, мы имеем возможность абсолютно «безболезненно» для системы заменить один модуль на любой другой, реализующий тот же самый интерфейс, а также добавить новый и тем самым расширить функциональность. Это как в конструкторе или «плагинной архитектуре» (plugin architecture) — интерфейс служит своего рода коннектором, куда может быть подключен любой модуль с подходящим разъемом. Гибкость конструктора обеспечивается тем, что мы можем просто заменить одни модули/«детали» на другие, с такими же разъемами (с тем же интерфейсом), а также добавить сколько угодно новых деталей (при этом уже существующие детали никак не изменяются и не переделываются). Подробнее про Open-Closed Principle и про то, как он может быть реализован можно почитать тут + хорошая статья на английском.

Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство. Они дают возможность модулям взаимодействовать и при этом ничего не знать о внутренней структуре друг друга, тем самым в полной мере реализуя принцип минимального знания, являющейся основой слабой связанности. Причем, чем в более общей/абстрактной форме определены интерфейсы и чем меньше ограничений они накладывают на взаимодействие, тем гибче система. Отсюда фактически следует еще один из принципов SOLID — Принцип разделения интерфейса (Interface Segregation Principle), который выступает против «толстых интерфейсов» и говорит, что большие, объемные интерфейсы надо разбивать на более маленькие и специфические, чтобы клиенты маленьких интерфейсов (зависящие модули) знали только о методах, которые необходимы им в работе. Формулируется он следующим образом: «Клиенты не должны зависеть от методов (знать о методах), которые они не используют» или “Много специализированных интерфейсов лучше, чем один универсальный”.

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

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

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

Замечание: Хотя большинство программистов понимают важность интерфейсов при проектировании классов (объектов), складывается впечатление, что идея необходимости использовать интерфейсы также и на уровне модулей только зарождается. Мне встретилось очень мало статей и проектов, где интерфейсы бы применялись для ослабления связанности между модулями/слоями и соответственно использовался бы паттерн «Фасад». Кто, например, видел «Фасад» на схемах уже упоминавшегося «архитектурного шаблона» Модель-Вид-Контроллер, или хотя бы слышал его упоминание среди паттернов, входящих в состав MVC (наряду с Observer и Composite)? А ведь он там должен быть, поскольку Модель это не класс, это модуль, причем центральный. И у создателя MVC Трюгве Реенскауга он, конечно же, был (смотрим «The Model-View-Controller (MVC ). Its Past and Present», только учитываем, что это писалось в 1973 году и то, что мы сейчас называем Представлением — Presentaition/UI тогда называлось Editior). Странным образом «Фасад» потерялся на многие годы и вновь обнаружить его мне удалось лишь недавно, в основном, в обобщенном варианте MVC от Microsoft («Microsoft Application Architecture Guide»). Вот соответствующие слайды:

А разработчикам, к сожалению, приходится заново «переоткрывать» идею, что к объектам Модели, отвечающей за бизнес-логику приложения, нужно обращаться не напрямую а через интерфейс, то есть «Фасад», как например, в этой статье, откуда для полноты картины взят еще один слайд:

2. Dependency Inversion. Корректное создание и получение зависимостей

Формально, требование, чтобы модули не содержали ссылок на конкретные реализации, а все зависимости и взаимодействие между ними строились исключительно на основе абстракций, то есть интерфейсов, выражается принципом Инвертирования зависимостей (Dependency Inversion — последний из пяти принципов SOLID):

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

Абстракции не должны зависеть от деталей. Реализация должна зависеть от абстракции.

У этого принципа не самая очевидная формулировка, но суть его, как и было сказано, выражается правилом: «Все зависимости должны быть в виде интерфейсов». Подробно и очень хорошо принцип инвертирования зависимостей разбирается в статье Модульный дизайн или «что такое DIP, SRP, IoC, DI и т.п.». Статья из разряда must-read, лучшее, что доводилось читать по архитектуре ПО.

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

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

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

Ну а теперь разберем подробнее, как это делается на практике и каким образом модули могут корректно создавать и получать свои «зависимости», не нарушая принципа Dependency Inversion.

Итак, при проектировании модуля должны быть определены следующие ключевые вещи:

что модуль делает, какую функцию выполняет

что модулю нужно от его окружения, то есть с какими объектами/модулями ему придется иметь дело и

как он это будет получать

Крайне важно то, как модуль получает ссылки на объекты, которые он использует в своей работе. И тут возможны следующие варианты:

Модуль сам создает объекты необходимые ему для работы.
Но, как и было сказано, модуль не может это сделать напрямую — для создания необходимо вызвать конструктор конкретного типа, и в результате модуль будет зависеть не от интерфейса, а от конкретной реализации. Решить проблему в данном случае позволяет шаблон Фабричный Метод (Factory Method).
«Суть заключается в том, что вместо непосредственного инстанцирования объекта через new, мы предоставляем классу-клиенту некоторый интерфейс для создания объектов. Поскольку такой интерфейс при правильном дизайне всегда может быть переопределён, мы получаем определённую гибкость при использовании низкоуровневых модулей в модулях высокого уровня».
В случаях, когда нужно создавать группы или семейства взаимосвязанных объектов, вместо Фабричного Метода используется Абстрактная Фабрика (Abstract factory).

Модуль берет необходимые объекты у того, у кого они уже есть (обычно это некоторый, известный всем репозиторий, в котором уже лежит все, что только может понадобиться для работы программы).
Этот подход реализуется шаблоном Локатор Сервисов (Service Locator), основная идея которого заключается в том, что в программе имеется объект, знающий, как получить все зависимости (сервисы), которые могут потребоваться.
Главное отличие от фабрик в том, что Service Locator не создаёт объекты, а фактически уже содержит в себе инстанцированные объекты (или знает где/как их получить, а если и создает, то только один раз при первом обращении). Фабрика при каждом обращении создает новый объект, который вы получаете в полную собственность и можете делать с ним что хотите. Локатор же сервисов выдает ссылки на одни и те же, уже существующие объекты. Поэтому с объектами, выданными Service Locator, нужно быть очень осторожным, так как одновременно с вами ими может пользоваться кто-то еще.
Объекты в Service Locator могут быть добавлены напрямую, через конфигурационный файл, да и вообще любым удобным программисту способом. Сам Service Locator может быть статическим классом с набором статических методов, синглетоном или интерфейсом и передаваться требуемым классам через конструктор или метод.
Вообще говоря, Service Locator иногда называют антипаттерном и не рекомендуют использовать (главным образом потому, что он создает неявные связности и дает лишь видимость хорошего дизайна). Подробно можно почитать у Марка Симана:
Service Locator is an Anti-Pattern
Abstract Factory or Service Locator?

Модуль вообще не заботиться о «добывании» зависимостей. Он лишь определяет, что ему нужно для работы, а все необходимые зависимости ему поставляются («впрыскиваются») из вне кем-то другим.
Это так и называется — Внедрение Зависимостей (Dependency Injection). Обычно требуемые зависимости передаются либо в качестве параметров конструктора (Constructor Injection), либо через методы класса (Setter injection).
Такой подход инвертирует процесс создания зависимости — вместо самого модуля создание зависимостей контролирует кто-то извне. Модуль из активного элемента, становится пассивным — не он делает, а для него делают. Такое изменение направления действия называется Инверсия Контроля (Inversion of Control), или Принцип Голливуда — «Не звоните нам, мы сами вам позвоним».
Это самое гибкое решение, дающее модулям наибольшую автономность. Можно сказать, что только оно в полной мере реализует «Принцип единственной ответственности» — модуль должен быть полностью сфокусирован на том, чтобы хорошо выполнять свою функцию и не заботиться ни о чем другом. Обеспечение его всем необходимым для работы это отдельная задача, которой должен заниматься соответствующий «специалист» (обычно управлением зависимостями и их внедрениями занимается некий контейнер — IoC-контейнер).
По сути, здесь все как в жизни: в хорошо организованной компании программисты программируют, а столы, компьютеры и все необходимое им для работы покупает и обеспечивает кладовщик. Или, если использовать метафору программы как конструктора — модуль не должен думать о проводах, сборкой конструктора занимается кто-то другой, а не сами детали.

Более подробно и с примерами о способах создания и получения зависимостей можно почитать, например, в этой статье (только надо иметь ввиду, что хотя автор пишет о Dependency Inversion, он использует термин Inversion of Control; возможно потому, что в русской википедии содержится ошибка и этим терминам даны одинаковые определения). А принцип Inversion of Control (вместе с Dependency Injection и Service Locator) детально разбирается Мартином Фаулером и есть переводы обеих его статей: «Inversion of Control Containers and the Dependency Injection pattern» и “Inversion of Control”.

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

3. Замена прямых зависимостей на обмен сообщениями

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

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

Наблюдатель (Observer). Применяется в случае зависимости «один-ко-многим», когда множество модулей зависят от состояния одного — основного. Использует механизм рассылки, который заключается в том, что основной модуль просто осуществляет рассылку одинаковых сообщений всем своим подписчикам, а модули, заинтересованные в этой информации, реализуют интерфейс «подписчика» и подписываются на рассылку. Находит широкое применение в системах с пользовательским интерфейсом, позволяя ядру приложения (модели) оставаться независимым и при этом информировать связанные с ним интерфейсы о том что произошли какие-то изменения и нужно обновиться.
Организация взаимодействия посредством рассылки сообщений имеет дополнительный «бонус» — необязательность существования «подписчиков» на «опубликованные» (т.е. рассылаемые) сообщения. Качественно спроектированная подобная система допускает добавление/удаление модулей в любое время.

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

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

4. Замена прямых зависимостей на синхронизацию через общее ядро

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

Ядро-посредник может как знать о модулях-клиентах и управлять ими (пример — архитектура apache ), так и может быть полностью, или почти полностью, независимым и ничего о клиентах не знать. В сущности именно этот подход реализован в «шаблоне» Модель-Вид-Контроллер (MVC), где с одной Моделью (являющейся ядром приложение и общим хранилищем данных) могут взаимодействовать множество Пользовательских Интерфейсов, которые работают синхронно и при этом не знают друг о друге, а Модель не знает о них. Ничто не мешает подключить к общей модели и синхронизировать таким образом не только интерфейсы, но и другие вспомогательные модули.

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

5. Закон Деметры (law of Demeter)

Закон Деметры запрещает использование неявных зависимостей: «Объект A не должен иметь возможность получить непосредственный доступ к объекту C, если у объекта A есть доступ к объекту B и у объекта B есть доступ к объекту C«. Java-пример.

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

Закон Деметры реализует уже упоминавшийся «принцип минимального знания», являющейся основой слабой связанности и заключающийся в том, что объект/модуль должен знать как можно меньше деталей о структуре и свойствах других объектов/модулей и вообще чего угодно, включая собственные подкомпоненты. Аналогия из жизни: Если Вы хотите, чтобы собака побежала, глупо командовать ее лапами, лучше отдать команду собаке, а она уже разберётся со своими лапами сама.

6. Композиция вместо наследования

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

Могу только посоветовать в данном контексте обратить внимание на шаблон Делегат (Delegation/Delegate) и пришедший из игр шаблон Компонет (Component), который подробно описан в книге «Game Programming Patterns» (соответствующая глава из этой книги на английском и ее перевод).

Статьи в интернете:

Замечательный ресурс — Архитектура приложений с открытым исходным кодом, где «авторы четырех дюжин приложений с открытым исходным кодом рассказывают о структуре созданных ими программ и о том, как эти программы создавались. Каковы их основные компоненты? Как они взаимодействуют? И что открыли для себя их создатели в процессе разработки? В ответах на эти вопросы авторы статей, собранных в данных книгах, дают вам уникальную возможность проникнуть в то, как они творят«. Одна из статей полностью была опубликована на хабре — «Масштабируемая веб-архитектура и распределенные системы».

Интересные решения и идеи можно найти в материалах, посвященных разработке игр. Game Programming Patterns — большой сайт с подробным описанием многих шаблонов и примерами их применения к задаче создания игр (оказывается, есть уже его перевод — «Шаблоны игрового программирования», спасибо strannik_k за ссылку). Возможно будет полезна также статья «Гибкая и масштабируемая архитектура для компьютерных игр» (и ее оригинал. Нужно только иметь ввиду что автор почему-то композицию называет шаблоном «Наблюдатель»).

По поводу паттернов проектирования:

Есть еще принципы/паттерны GRASP, описанные Крэгом Лэрманом в книге «Применение UML 2.0 и шаблонов проектирования», но они больше запутывают чем проясняют. Краткий обзор и обсуждение на хабре (самое ценное в комментариях).

Ну и конечно же книги:

7 советов, которые помогут проектировать быстрее

И почему скорость важна.

Осторожно, спойлеры! Речь не идет о том, чтобы иметь лучшее оборудование, выпить коктейль из Red bull и кофе или узнать все горячие клавиши ваших любимых инструментов дизайна (хотя последний вариант не повредит).

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

Но сначала давайте поймем, почему вам нужно быть быстрым.

Почему?

Дизайнерам часто нужно время. Время, чтобы найти вдохновение, подумать, исследовать, провести мозговой штурм, помедитировать, проверить Dribbble, пролистать пару статей на Medium (но только взглянуть на картинки и прочитать названия)… Вы понимаете, всё это часть творческого процесса.

Как дизайнер, я не могу с этим поспорить.

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

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

По сути, если у вас жесткий дедлайн, скорость работы вам поможет.

Вы не спешите? Вы не медлите?

Ну, что же… Повезло вам!

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

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

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

Теперь давайте перейдем к советам.

1. Определите свою цель

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

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

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

2. Не ждите вдохновения

Нет такого понятия, как «творческий блок», вы не можете все время проектировать отличные вещи, но вы можете создать что-то, просто начните работать.

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

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

Эта история / эксперимент из книги Art & Fear прекрасно иллюстрирует этот момент. Если вкратце: учитель объявил своему классу, что они будут разделены на две группы, одна будет оцениваться исключительно по качеству, другая – по количеству. Когда дело дошло до оценки работ, то оказалось, что работы наивысшего качества были сделаны группой, которая должна была оцениваться по количеству.

Это означает, что количество ведет к качеству, поэтому вместо того, чтобы ждать, пока лучшая идея упадет с неба, ? ПРОСТО ? НАЧНИТЕ ? РАБОТАТЬ.

Это приводит нас к следующему шагу.

3. Делайте эскизы, эскизы и еще раз эскизы!

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

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

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

4. Поделитесь своим прогрессом

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

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

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

5. Слушайте

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

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

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

6. Проектируйте поэтапно

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

Это будет во многом зависеть от того, над чем вы работаете, но вот общие рекомендации:

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

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

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

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

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

7. Делайте перерывы

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

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

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

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

Вкратце…

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

Тем временем, в реальном мире…

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

Моя отправная точка

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

Итак, я начал с …

1. Определения цели

Я определил цели иллюстраций, в основном они заключались в следующем:

1 – В некотором смысле, они должны соответствовать сообщению / тексту.
2 – Они должны следовать логическому и непрерывному сценарию.
3 – Если пользователи не читают текст и смотрят только на визуальные эффекты, они все равно получают сообщение (насколько это возможно).
4 – В целом, они должны рассказать историю, связанную с приложением.

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

После этого…

2. и 3. Я не ждал вдохновения, а сразу начал делать наброски

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

3 этапа зарисовки первой иллюстрации

Мой подход – создать 5 иллюстраций и посмотреть, как они могут работать вместе. Сначала сделать ОЧЕНЬ грубые наброски, а затем довести их до более изысканных эскизов.

К концу утра у меня были все 5 экранов на уровне третьего эскиза выше, и в этот момент я бы мог перейти прямо в Illustrator, чтобы сделать все иллюстрации, но я решил …

4. Поделиться работой

Наброски всего сценария

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

Как видите, я…

6. Проектировал поэтапно

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

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

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

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

Первое предложение для стиля иллюстрации

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

После того, как я поделился работой еще раз, я получил фидбек, который я заслуживал, так что…

5. Я слушал

И вот таким был результат:

Первая итерация стиля иллюстрации

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

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

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

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

Мелочи, которые занимают много времени

Наш персонаж получил более стройное тело и больше волос на голове. Мы также добавили немного пара на иконку кофе. ☕️

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

Осталось упомянуть еще одну вещь, потому что в течение той недели я путешествовал и провел несколько встреч, которые я не мог пропустить, я был «вынужден»…

7. Делать перерывы

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

Есть немного лишнего времени? Используйте его!

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

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

Я учел это с самого начала при создании иллюстраций.

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

Чтобы донести это до разработчиков, я создал в Principle очень простой прототип.

Прототип, созданный в Principle

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

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

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

Фактическая реализация

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

Это был длинный рассказ, поэтому, если вы дочитали, вы заслужили …

Еще один дополнительный совет…

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

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

Поэтому установите ограничение по времени и после этого ПРИСТУПАЙТЕ К РАБОТЕ!

На этом все. Я надеюсь, вам понравилась статья. Если вы считаете ее полезной или интересной, ставьте лайки и поделитесь ею с коллегами.

Свободно пишите автору в Twitter или LinkedIn.

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

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

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

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

Стив Джобс однажды сказал, что 3,5-дюймовый экран – это «идеальный размер для потребителей», а большие экраны – это глупость.

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

90% продаваемых сегодня смартфонов имеют дисплеи размером более 5 дюймов.

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

Например, приложение CNN было одним из немногих, кто получил ранний доступ к iPhone 5, представленному в 2012 году. Разработчики не только эстетически трансформировали его, но и создали удобный для восприятия визуально привлекательный опыт, выделив заголовки.

Из выступления Фила Шиллера на специальном мероприятии Apple в 2012 году

Из-за больших экранов страдает доступность

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

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

49% пользователей держат свои телефоны одной рукой, особенно, когда находяться в движении.

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

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

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

Исследования показывают, что в среднем пользователь проверяет свой телефон 58 раз в день, при этом 70% мобильных взаимодействий длятся менее 2 минут.

Мы используем наши телефоны в «короткие промежутки времени с рассеянным вниманием».

Команда исследователей из Simform наблюдала за поведением пользователей во время таких кратковременных сессий в различных сценариях:

Примеры вариантов использования телефона в коротких промежутках времени

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

Как проектировать дизайн с учетом коротких интервалов использования смартфона одной рукой?

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

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

Давайте взглянем на эволюцию интерфейса Spotify, чтобы получить представление о проблеме:

Старая навигация Spotify – гамбургер-меню

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

Spotify — Пользователи испытывали определенный уровень сложности и дискомфорта при взаимодействии с приложением

Это вынудило команду Spotify в 2016 году отказаться от гамбургер-меню и расположить основные функции (Home, Browse, Search, Radio и Library) в нижней части экрана, что привело к увеличению общего количества кликов на 9% и на 30% кликов по пунктам меню.

Используйте устоявшиеся UX-паттерны для общих сценариев использования, чтобы упростить использование приложения одной рукой

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

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

Мы разделяем наиболее распространенные модели поведения пользователей и UX-паттерны на шесть категорий:

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

1. Проектирование навигации по приложению одной рукой

Что это?

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

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

У хорошей навигации все важные разделы должны быть легко доступны.

Проблемы

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

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

Решение

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

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

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

1.1 В чем проблема гамбургер-меню?

Используйте всплывающее меню вместо полностраничного

К счастью, у нас есть способ решить эту проблему.

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

1.2 Мобильные UX-паттерны для всплывающих меню (Видео: Joox)

Расширьте панель вкладок, если у вас много контента

Руководство Human Interface Guidelines рекомендует размещать не более 5 функций в нижней панели навигации. Здесь вам пригодится опция «Больше» (3 точки). Расположенная в нижней панели, она может скрыть другие функции и раскрыть их одним нажатием.

1.3 Проектирование нижней панели навигации с возможностью расширения дополнительных параметров

Персонализированная панель вкладок для опытных пользователей

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

1.4 Персонализированная нижняя панель вкладок для быстрого доступа к функциям

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

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

1.5 Навигация на основе жестов для доступа к функциям приложения

Возврат и закрытие страницы также должны быть правильно спроектированы

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

1.6 Использование жестов для навигации по нескольким экранам (Видео: Zenly)

Паттерны для быстрого перехода к различным разделам приложения

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

Их можно организовать с помощью иерархии и UX-паттернов для повышения доступности, и простоты использования.

1.7 Плавающие вкладки и жесты для перехода между разделами

2. Паттерны основных действий одной рукой: создание, редактирование, публикация, добавление, удаление и другие