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

■ Архитектура приложения и соответствующие диаграммы состояний. Эта информация отражает технические аспекты плана. Для мобильных приложений этот раздел должен содержать соответствующие диаграммы состояний, описывающие дискретные состояния, в которых может находиться приложение, и связь этих состояний с объемами памяти и ресурсов, которые будут в ней храниться. (Далее об этом будет говориться более подробно.) Такой раздел фактически играет роль соглашения между всеми участниками группы разработчиков, в котором они обязуются придерживаться в своих реализациях установленных в нем требований. Если вы выступаете в роли единственного разработчика, то этот документ даст вам возможность оставаться честным перед самим собой; у каждого, кому довелось хотя бы однажды самостоятельно разрабатывать крупный проект, наверняка иногда возникало желание срезать тот или иной угол, чтобы добиться работоспособности средства, пусть даже это и будет в ущерб разумным принципам проектирования. Срезать углы гораздо сложнее, если перед вашими глазами находится соглашение, в котором указано, что вы должны в явной виде формулировать все свои предложения по ускорению работы над проектом. Этот раздел не должен быть чрезмерно длинным или сложным, ибо в противном случае выполнять его требования будет трудно, и им будут просто пренебрегать. В нем должно быть сформулировано, что необходимо сделать для того, чтобы проект удерживался в организационном русле, и, что еще важнее, в нем должны оперативно учитываться любые согласованные изменения проекта.

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

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

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

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

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