Индейские хитрости проектировщика ПО. Выпуск 1
А на сегодня у меня есть для вас следующие мысли:
Документирование переменных
При разработке действительно больших и сложных приложений вы наверняка столкнетесь с необходимостью использовать переменные. Например для определения типа пользователя, если у вас интерфейс отличается для каждого из них, можно создать соответствующую переменную и привязать к ее значению отображаемый функционал.
Бывает так, что переменных становится много и открыв проект через некоторое время вам придется снова вспоминать, что же они обозначают.
Для того чтобы избежать этих мучительных воспоминаний я использую простой трюк. Каждый раз когда я завожу переменную (речь конечно по большей части о глобальных переменных 'Global Variables'), я записываю ее название и возможные значения на отдельный мастер, который, как правило, называю 'Variables'. Рядом пишу пояснения для себя, что конкретно делает переменная, где я ее задействовал и пояснения к ее значениям. Это сильно помогает когда нужно быстро вспомнить какие переменные уже задействованы и как они работают. Да да, по факту, банальное комментирование кода.
Структурирование функционала
Если мы говорим о разработке сложных приложений, то как правило мы говорим об огромном количестве функционала. Функционал этот может дублироваться на разных экранах, отображаться с небольшими изменениями и без них. Но в любом случае, независимо от желания проектировщика, почти всегда есть необходимость внесения правок. И конечно правки хочется вносить максимально быстро и максимально просто. Для облегчения такой работы очень удобно пользоваться мастер-страницами, но я рассматриваю их не только в качестве мастеров, но и в качестве контейнеров которые помогают содержать виджеты в структурированном виде и, как следствие, в быстром доступе. Я поступаю следующим образом — максимальное количество функционала делаю изначально мастерами и организовываю в дереве мастеров отдельную категорию с четкой иерархией.
Это подход очень удобен по нескольким причинам:
Не нужно закапываться вглубь прототипа/динамических панелей и их состояний для того чтобы поменять надпись на кнопке. Достаточно просто найти нужный мастер. (Например: карточка клиента будет лежать в папке Main\Clients\Tools).
Мастер это мастер, не нужно будет делать одно и то же несколько раз на разных экранах.
Структура мастеров позволяет лучше контролировать ваш проект. Сразу видно что сделано, чего не хватает, быстро перекидывать виджеты между экранами и лучше контролировать единообразие ваших решений.
В целом такой подход отнимет у вас чуть больше времени на этапе разработки прототипа, но открыв свой прототип через полгода вы скажете себе спасибо.
To do
Еще один ход который я часто использую в работе это документирование предстоящей работы прямо на экране на котором предстоит эту работу сделать. Я просто пишу текстом что планирую сделать по данному экрану и по мере выполнения удаляю. Если за один раз все сделать не получается я загоняю все в одну группу и скрываю (например если нужно показать прототип кому то), а когда возвращаюсь к этому экрану мне не нужно лезть в требования, что бы посмотреть что я еще не сделал. Это очень сильно экономит время. Иногда, когда текста недостаточно, в группе могут появляться картинки (например если я увидел где нибудь решение которое может мне подойти) или ссылки и т.д. Звучит достаточно просто и логично, но я почему то еще не встречал проектировщиков которые поступают подобным образом. А жаль.
Имитация внешних факторов
Часто бывает так, что на интерфейс влияют внешние факторы которые, не зависят от действий пользователя или зависят опосредованно, но которые, тем не менее, должны быть проработаны и отображены в прототипе. Приведу пример. Необходимо спроектировать, как поведет себя система при изменении температуры какого нибудь физического компонента. Можно нарисовать большой гайд с отдельными экранами для достижения каждого порога нагрева, можно написать прямо в теле прототипа пояснения и там же сделать всплывающее окно со всеми иконками и предупреждениями, а можно пойти немного более логичным путем. Можно просто взять и запрототипировать виджет который будет содержать триггеры по которым интерфейс будет меняться. То есть прямо в прототипе поставить кнопку «Имитация температурных колебаний» который будет состоять из триггеров «Достижение первого предела», «Достижение второго предела» и т.д. При тестировании вам скажут спасибо. Все в одном месте, все меняется, можно наглядно посмотреть поведение системы.
То же самое мы можем проделывать и со сценарными развилками которые не зависят от пользователя. Например: мы хотим имитировать отправку формы на сервер, но в одном не зависящем от пользователя случае форма отправится, а в другом нет. В таких случаях я просто показываю максимально отличный по дизайну виджет (с текстом что это не системное окно и нужно только для имитации работы системы, чисто на всякий случай) в котором даю возможность выбора пути. Таким образом сохраняется целостность прототипа и связи между экранами остаются прямыми и понятными.
За сим пилотный выпуск считаю возможным завершить. Буду рад если статья оказалась вам полезной и еще больше обрадуюсь если и вы в комментариях поделитесь своими индейскими хитростями. А на сегодня у меня все. До новых встреч.
