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

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

Балансировка пользователей и ресурсов

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

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

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

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

SAGE Timeslips

Начнем с примера. Давайте посмотрим на теоретический отчет об ошибке:

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

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

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

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

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

Что вызывает эти моменты?

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

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

Как сделать ваше устройство функциональным

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

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

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

Потребности многих перевешивают потребности немногих

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

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

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

Применение к реализации

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

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

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

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

Первоначально опубликовано на https://somedudesays.com 3 мая 2020 г.