Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

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

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

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

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

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

Другие сценарии могут быть более конкретными:

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

■ Для доступа к информации о заказах клиентов должно требоваться не более 3 секунд.

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

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

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

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