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

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

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

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

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

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

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

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

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

■ Можно ли исключить или сократить периоды задержек путем технической доработки проекта?

■ Можно ли обрабатывать задержки, вызывая заставки или отображая курсоры ожидания, уведомляющие пользователя о том, что выполнение приложения продолжается?

■ Можно ли передать выполнение задачи фоновому потоку, чтобы обеспечить сохранение пользовательским интерфейсом постоянной способности к отклику?

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