Книга: Программирование мобильных устройств на платформе .NET Compact Framework
При необходимости вернитесь к шагам 0, 1, 2 и 3
При необходимости вернитесь к шагам 0, 1, 2 и 3
Современная разработка является итеративным процессом. Это особенно справедливо в отношении разработки приложений для мобильных устройств. Исходя из своей квалификации и опыта, вы принимаете первоначальные решения, которые кажутся вам наилучшими, и при необходимости впоследствии пересматриваете их. Наличие опыта проектирования приложений для мобильных устройств поможет вам принять лучшие решения, но никогда не сделает их идеальными. Всегда вкрадется какая-нибудь непредвиденная проблема, которая вынудит вас заново пересмотреть свой проект и внести в него небольшие уточнения или, как это часто случается, радикальные изменения. Значительное место в оставшейся части книги отводится тому, чтобы научить вас с самого начала принимать наилучшие решения и одновременно привить необходимые технические навыки, которые позволят оставить открытыми двери для пересмотра проекта, если это потребуется.
Хороший проект мобильного программного обеспечения должен в обязательном порядке предусматривать обнаружение проблем, появления которых вам не избежать, уже на самых ранних стадиях разработки и ориентировать на создание кода, обладающего достаточно модульной и гибкой структурой, чтобы при необходимости в него можно было внести изменения, не рискуя безнадежно запутаться.
Приступив к проектированию и тестированию коммуникационной модели, вы можете обнаружить, что в проекте были допущены существенные просчеты. Может оказаться, что расходуемый объем памяти слишком велик, а это означает, что либо количество данных, одновременно хранящихся в памяти, слишком большое, либо их хранение организовано недостаточно эффективно. Вероятнее всего, изменение модели данных окажет влияние на коммуникационную модель, управляющую тем, как именно будет осуществляться обмен данными с долговременным хранилищем. В свою очередь, внесение изменений в модель данных и коммуникационную модель может повлечь за собой необходимость пересмотра пользовательского интерфейса. Возможно, при внесении этих изменений вам придется учесть тот факт, что количество данных, одновременно находящихся в памяти в любой момент времени, превышает то, которое допускалось ранее, или же что для обеспечения желаемой степени интерактивности пользовательского интерфейса способ извлечения данных должен быть изменен по сравнению с первоначально предполагаемым. Наконец, в ходе этого процесса вы можете обнаружить, что некоторые из целей приложения, предусмотренные проектом, должны быть изменены. Возможен и другой вариант, когда в результате использования и тестирования приложения обнаруживается, что состав его проектных целей должен быть расширен. Современная разработка приложений носит итеративный характер. Поскольку мобильные устройства представляют собой новый и еще не до конца исследованный мир, они потребуют еще большего итерирования.
Рис. 4.5. Пересмотрите предыдущие шаги проекта, если это необходимо для устранения проблем производительности
В попытках согласовать между собой результаты, получаемые на различных стадиях разработки, легко потеряться где-то посередине и начать писать код, значительная доля которого, связывающая его отдельные части между собой, будет походить на запутанный клубок спагетти, а необходимые проектные изменения будут выглядеть как заплаты. Вы должны избегать подобного соблазна и использовать собственные контрольные этапы, которые помогут вам сохранить целостность процесса проектирования. В явном виде определите критерии завершения таких этапов, что позволит рационализировать процесс проектирования. По завершении контрольного этапа разработки вы должны дать ответы на следующие вопросы:
? Остаются ли в силе намеченные вами первоначальные ключевые сценарии и набор возможностей приложения или они должны быть переопределены?
? Способен ли пользовательский интерфейс точно представлять указанные сценарии, и дает ли он пользователям возможность выполнять наиболее распространенные операции при минимальном количестве манипуляций вручную? Сохраняет ли пользовательский интерфейс способность в любой момент реагировать на действия пользователя? Соответствует ли пользовательский интерфейс форм-фактору устройства, являющегося целевым?
? Работоспособна ли базовая модель данных, в соответствии с которой объекты загружаются в память и выгружаются из нее? Обеспечивает ли она масштабирование до тех реальных объемов данных, с которыми столкнутся ваши пользователи? Будет ли эта модель вести себя достаточно стабильно в процессе того, как пользователь своими действиями заставит приложение побывать во всех возможные состояниях, запросит дополнительные данные или запустит приложение, предоставив ему возможность выполняться непрерывно в течение многих недель?
? Удовлетворяет ли коммуникационная модель мобильного приложения вашим требованиям? Используете ли вы наивысший из уровней абстракции API- интерфейсов и форматов файлов, который является для вас приемлемым?
В основе всех ваших проектных решений должна лежать философия, в которой во главу угла ставится достижение высокой производительности приложения. Если какой-либо из пунктов проекта вашего приложения не в состоянии обеспечить выполнение этого требования, прекратите дальнейшее написание кода! Прекратите написание кода! Прекратите написание кода! Затем немедленно займитесь выяснением того, какие именно факторы приводят к снижению производительности, и, прежде чем двигаться дальше, решите связанные с этим проблемы. Это замечание играет важную роль на любой стадии проекта, но его необходимо обязательно учитывать на завершающей стадии и во всех контрольных точках проекта, которые вы для него определили. По мере приближения процесса разработки приложения к своему завершению внесение изменений должно требоваться реже, да и делать это уже будет труднее, поскольку между написанными к этому времени модулями кода установятся всевозможные зависимости. Предусмотрите в своих планах, что на ранних стадиях проекта вы будете множество раз возвращаться к критическому пересмотру принятых ранее решений и вносить изменения, тогда как по мере прохождения вашим проектом контрольных точек и приближения кода к его окончательному виду необходимость в таких изменениях будет постепенно уменьшаться.
- Шаг 0: прежде чем приступать к работе, определите сферу применения вашего приложения
- Шаг 1: начните с анализа проблем производительности и никогда не упускайте их из виду
- Шаг 2: спроектируйте подходящий пользовательский интерфейс
- Шаг 3: выберите подходящие модели данных и памяти
- Шаг 4: выберите подходящую модель коммуникации и модель ввода-вывода
- При необходимости вернитесь к шагам 0, 1, 2 и 3
- Шаг 5: пакетирование приложения для его установки
- Можно ли избавиться от необходимости использовать двойной щелчок кнопкой мыши при открытии папки?
- Рост необходимости создания голубых океанов
- 15.4.1.3. При необходимости переставляйте код
- Решайте задачи в определенной очередности; не бойтесь при необходимости возвращаться назад
- Продажи по шагам
- Как убедить коллег в необходимости разработки ценностных предложений
- Признаки необходимости выделения функции
- Программа внедрения по шагам
- Реактивные изменения: только при необходимости
- Разбор техники по шагам с комментариями
- Теперь по шагам!
- Сокращение необходимости в общественных благах