Следует также отметить, что производительность — понятие субъективное. Бесполезно доказывать кому-то, что приложение работает нормально, если ваш оппонент утверждает, что с его точки зрения оно работает слишком медленно. Это все равно как если бы вы пытались убедить того, кто совершает пробную поездку на старомодном "универсале", что двигатель и коробка передач в этой машине почти такие же, как в спортивном автомобиле, и что следует обращать внимание не на внешний вид, а на объективные характеристики. Если покупателю автомобиль кажется тихоходным, то таковым он его и будет воспринимать. Понятие "высокой" производительности связано не с быстродействием отдельных частей, а с субъективной оценкой поведения всей системы в целом.
Важность планомерного подхода
Томас Эдисон, который сам был человеком не слабым в изобретательстве, как-то сказал: "Гений — это один процент вдохновения и девяносто девять процентов пота". Достижение высокой производительности — это 80 процентов кропотливой работы и 20 процентов творчества. Соблюдение определенной дисциплины в процессе разработки приложения позволит своевременно обнаруживать появление проблем, обусловленных низкой производительностью, и не даст вам возможности игнорировать их или отложить их решение на более поздний период работы. Всегда существует соблазн не обращать на проблемы производительности никакого внимания; само по себе устранение проблем упомянутого рода не обогащает приложение никакими новыми средствами, так что эта работа считается не особенно интересной. Вместе с тем, если вы хотите преуспеть в разработке мобильного приложения, к которой приступаете, то систематическое решение проблем производительности играет в этом ключевую роль. Стиль работы, основанный на планировании, позволит вам не только выявить проблемы производительности на самых ранних стадиях разработки, но и найти соответствующие решения еще до того, как указанные проблемы успеют прочно вплестись в канву вашего проекта. С большинством этих проблем вы сможете справиться путем подходящей адаптации идей, изложенных в этой главе, а также реализации собственных идей, которые появятся у вас в процессе дальнейшей работы над проектом. Если с аналогичными ситуациями вы ранее не сталкивались, случайный проблеск творческого озарения может подсказать вам новое решение, которое до сих пор никому в голову не приходило, что позволит вам вдохнуть в свой проект новую жизнь. Самое главное — это придерживаться определенной самодисциплины, заставляющей вас не закрывать глаза на проблемы производительности, которые неизбежно возникнут, а заниматься ими до тех пор, пока они не будут разрешены. Когда Томас Эдисон испытывал нити накала для изобретенной им лампочки, ему пришлось перепробовать сотни различных материалов, прежде чем он смог остановиться на том, который обеспечивал наилучшее сочетание светимости и срока службы нити. Точно так же обстоит дело и с производительностью: получение нужного результата требует постоянного тестирования приложения и оценки качества его функционирования. Как показывает пример Эдисона, целеустремленность, настойчивость и творческий дух окупают себя сторицей.
Определите обязательные характеристики сценариев рабочих сеансов пользователя
Вы должны подготовить список, определяющий ключевые сценарии рабочих сеансов пользователя. Некоторые из этих сценариев могут носить общий характер, например:
■ При любых обстоятельствах пользователь не должен оставаться без визуального подтверждения того, что работа выполняется, на протяжении промежутков времени длительностью более 0,5 секунды.
■ При любых обстоятельствах для получения пользователем возможности прекратить выполнение затянувшейся текущей операции должно требоваться не более 4 секунд.
Другие сценарии могут быть более конкретными:
■ На запуск нового сеанса шахматной игры должно уходить не более 1 секунды.
■ Для доступа к информации о заказах клиентов должно требоваться не более 3 секунд.
Включите эти сценарии в главный документ проекта. Независимо от того, работаете ли вы индивидуально или в составе группы, письменное напоминание о том, какие условия работы с приложением должны быть созданы для пользователя, никогда не помешает. Возможно, со временем в этот список будут внесены изменения, учитывающие обнаруженные в ходе тестирования приложения ранее неизвестные обстоятельства, однако преимущества, предоставляемые наличием явно сформированного списка ключевых сценариев, сосредоточенных в одном документе еще до начала разработки проекта, окупят затраченные на это усилия.
Читать дальше