Основные концепции

1.4. Среда для быстрой разработки

Окинув беглым взглядом платформу, давайте обратимся к стилю программирования, который называется быстрой разработкой, и посмотрим, из чего он состоит.

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

Сама платформа Mozilla не относится к такого рода проектам. Это проект с открытыми исходными кодами, для которого экспертные оценки, инновации и стратегия развития архитектуры важны не меньше, чем возможность быстро получить готовый продукт. Более того, платформу можно использовать во встроенном программном обеспечении (записанном в ПЗУ), но эта тема, увы, в книге не рассматривается. Основные ограничения для такого ПО: объем скомпилированного кода, надежность и меньшая нужда в техническом обслуживании. Для таких приложений быстрота разработки некритична.

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

1.4.1. Меньшие затраты времени, тот же эффект

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

Не стоит тратить годы на разработку совершенной архитектуры. Лучше создать что-нибудь реально работающее.

1.4.2. Визуальные прототипы

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

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

1.4.3. Вертикальные решения

Быстрая разработка используется для создания продуктов специального применения, не универсальных; неважно, будет это каталог для музея или программа анализа состояния фондов. Такие продукты называются вертикальными решениями. В этих случаях обычно не нужно делать приложение настолько гибким, чтобы его можно было приспособить и для выполнения задач другого класса. Это может быть будущей целью и только если продукт уже рабочий. Поэтому незачем настаивать на использовании универсального инструментария и языков более низкого уровня вроде C++, Perl или Tcl/Tk. Вместо этого лучше пользоваться специализированными средствами, подходящими для решения конкретной задачи. Mozilla как раз предназначена для использования в вертикальных решениях разных видов.

В проектах быстрой разработки стоит использовать узкоспециализированные средства - универсальные не всегда лучше.

1.4.4. Программное обеспечение готовое и собственной разработки

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

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

1.4.5. Тестирование отдельных компонентов

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

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

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

1.5. Эффективные проекты по быстрой разработке приложений для Mozilla

Mozilla может быть эффективным средством разработки, но здесь есть один подвох: нужную для этого информацию удастся получить не сразу. Для понимания исходного кода Mozilla требуется очень много времени. База даных ошибок Mozilla - настоящие джунгли, в которых можно потеряться, а на сайте mozilla.org старая и новая документация смешиваются без проверки на точность или адекватность. Попытки разобраться во всем этом могут поколебать решимость использовать Mozilla. Вот несколько советов, которые помогут сочетать использование Mozilla со всеми достоинствами быстрой разработки и быстро получить эффективный результат.

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

Время от времени придется заглядывать в файлы других приложений chrome, чтобы посмотреть, как данную проблему решали другие люди. Если требуется эффективный поиск по chrome, следует скачать архив с исходными кодами Mozilla и проиндексировать его программой вроде glimpseindex(1) для UNIX или проиндексировать распакованные файлы из chrome.

Во время создания интерфейсов с помощью XUL не стоит быть перфекционистом. Сидеть и подгонять размеры окон буквально по пикселам - неправильный подход. Достаточно будет приблизительного наброска, уточнения, а косметические поправки стоит делать только в самом конце. Не нужно бороться с инструментами собственного изготовления; надо просто использовать их оптимальным образом. Например, если вам не нравится тег <grid>, но больше ничего не подходит, просто используйте <grid> и забудьте об этом на время. Всегда держите консоль JavaScript открытой, но не пишите код на JavaScript, пока заказчик не увидит созданные вами графические интерфейсы на XUL.

При создании рабочего прототипа или экспериментировании не старайтесь слишком часто обращать внимание на XPCOM. Большая часть данных может быть обработана после отправки данных HTML-формы на web- сервер. Не следует усложнять приложение или пытаться освоить и задействовать все объекты XPCOM. Все они все равно никогда не пригодятся. При отсутствии собственного сервера для запуска отдельной программы можно пользоваться методом execute(). Не волнуйтесь, если ваше приложение не выглядит как картинка, все равно вы сможете потом привести его в порядок.

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

Лучше всего сохранить копию текущего кода и пытаться удалять из него части, пока не станет ясно, в чем причина проблемы. Затем следует заглянуть в книгу или отправить вопрос в подходящую конференцию. Если это не поможет решить проблему, в конце концов, у вас появится эффективный тест для Bugzilla и, возможно, кто-то быстро откликнется на сообщение об ошибке. Вполне вероятно, что незначительное изменение кода исправит положение. Так как проверка корректности документов в Mozilla не слишком эффективна и структура самой платформы плохо документирована, не всегда будет сразу очевидно, почему такое небольшое изменение привело к исчезновению проблемы. Этому всегда есть рациональное объяснение, но чтобы найти его, может понадобиться много времени. А нам нужно двигаться дальше.

Страстным поклонникам открытых исходных кодов не следует думать, что работа над самой платформой Mozilla будет быстрой. Это не что иное, как работа над обычным довольно большим проектом на C/C++. Вы сможете продвигаться в разработке, но не так быстро, чтобы изменения были заметны ежедневно - вероятнее всего, их влияние скажется не раньше, чем через месяц. Это хобби, которое займет ваше внимание надолго и будет отнимать много времени, если, конечно, это не ваша работа. На основе Mozilla можно быстро создавать новые приложения, но разработка самой платформы не так проста.