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

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

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

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

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

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

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

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

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

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

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

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

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

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