Подходы к разработке сложных Flash-приложений

Jonathan Boutelle, разрабатывавший поисковую службу с механизмом визуального анализа MindCanvas, клиент которой реализован на базе Flash-технологии, делится своими соображениями по поводу разработки сложных Flash_клиентов (21 пакет, 188 классов, 20 000 строк кода). Наша фирма как раз занимается сейчас не менее объемными проектами и потому я могу тоже судить о правильности выводов, приведенных Джонатаном.

В ранней статье он приводит несколько принципов:

• Не использовать таймлайн. Все приложение должно быть в одном фрэйме. Джонатан признается, что в консультации с парнями из Макромедии он выяснил, что концепция Screen'ов, появившаяся во Flash MX 2004 есть не более чем первая, несовершенная, попытка создания девелоперской среды. Flex Джонатан не рассматривает (понятно, что Flex 1.x не является средством разработки клиента - скорее некий серверный инструмент, чем уже является Flex 2, который еще не подлежит промышленному использованию). Только используемые в приложении графические элементы, созданные визуальными дизайнерами и не содержащие кода, могут иметь таймлайн. Сразу скажу, что компромиссный подход, когда фрэймы во fla-файле отображают некоторые «состояния» приложения, рассматривается, но признается неудобоваримым с точки зрения разработки, поддержки и тестирования. Подход отказа от таймлайна гарантирует более длительный начальный этап разработки, зато меньше проблем в будущем. От себя могу добавить, что я нахожу более-менее приемлимыми оба варианта (радикальный и компромиссный), но именно в связи с отсутствием идеального (Flex 2, I'm waiting for you! :)


• Не больше одной строчки кода на весь fla-файл. Это довольно логическое требование, вытекающее из предыдущего. Возможно, идеален Flex'овый подход, при котором вообще ни одной строчки - только класс, навешанный на главный контейнер. Имея опыт отладки крупных приложений, в которых код раскидан по кадрам, могу сказать, что зачастую проще выкинуть такие приложения на помойку. Ибо кроме автора в них разобраться никто не сможет.


• Использование существующих и опробованных процессов разработки. Тут нет вопросов. Использование систем контроля версий (мы используем Subversion, чего и вам желаем), инструментов сборки (ANT - не используем, но планируем), модульное тестирование (ASUnit, тоже планируем), системы багтрэкинга (Bugzilla, например, используемая нами). Это опробованные в других областях и языках разработки методики, которые пока не слишком опробованы в ActionScript разработке. Думаю, что именно в этих областях следует сконцентрировать достаточно плотное внимание русскоязычному Flash-сообществу.


• Не кастрируйте дизайнеров :) Это подразумевает, что не стоит злоупотреблять программной анимацией там, где гораздо лече и уместнее использовать таймлайн. Программист не лезет в таймлайн - это епархия дизайнеров. На отрисованные ими графические элементы (мувиклипы) вешаются классы. Здесь, конечно, могут возникнуть сложные моменты коммуникации, но на что существует грамотный менеджемент? :)


• Используйте паттерны, дарованные Богом. Это момент очевидный и тема для отдельного большого разговора.


• Сначала код, потом визуальная часть. Предполагается, что сначала пишется код для всех графических элементов, а уже потом дизайнеры осуществляют дизайн, который «оживляет» данный код. Думаю, что это полезная практика, ибо часто выходит так, что дизайнеры, как люди «творческие» в понимании обыденном, мало заботятся о представлении результатов на практике. А тупые и прагматичные разработчики имеют об этом бОльшее представление :)


• Не разрабатывайте того, что вы можете купить, взять или украсть :) Джонатан говорит, что двигаться вверх можно лишь встав кому-нибудь на плечи. Код, сделанный кем-то, опробованный и протестированный, лучше, чем написанный вами в короткий срок. Или как минимум дешевле. Про «украсть» Джонатан приукрасил конечно, но мысль очень правильная. Я на практике убеждался, что написание собственных UI-компонент вместо использования компонент от Macromedia выходит дороже, поддерживается из твоего же кошелька и содержит уж точно не меньшее количество багов, чем те, за которые уже заплачено. То же самое касательно структур данных, механизмов ведения лога итд. касательно библиотеки as2lib. Понятно, что в этой библиотеке код перерос несколько версий, прошел некоторую апробацию, нежели тот, что написан вами вчера ночью и который выдаст кучу багов в ночь перед сдачей вашего проекта.


• Пользуйтесь строгой типизацией. Если вы не указываете тип в вашем коде, это, фактически, означает, что вы его не знаете. Но его не знает и компилятор. Его не знает тот, кто будет работать с вашим кодом завтра. И если в коде будет баг, связанный с неверным представлением о типах, то вам не поможет ни компилятор на этапе компиляции, вы и сами долго будете иной раз мучиться силясь понять, что же здесь имелось ввиду. Поэтому наличие правила «Всегда указывайте тип» лучше правила «Указывайте тип там, где необходимо». Это, по моему глубокому мнению, касается в том числе и эскизного программирования. Если человек не указывает тип в этом случае, то такое поведение говорит лишь о том, что человек указывает его иногда лишь вопреки своим правилам (либо он работает в ужасном IDE навроде Flash IDE, где лаконичность - залог быстрого письма).

От себя бы хотел добавить лишь правила, декларированные в рамках XP: коллективное владение кодом (и, как следствие, соглашения по кодированию в рамках комманды), простота, коммуникация, обратная связь, итеративный подход.

Джонатан считает, что Flash IDE используется только в двух случаях: дизайнерами и для компиляции проекта. Но жалуется на невыносимо долгое время компиляции. В качестве решения предлагается оснастить разработчиков более мощными компьютерами (поддерживаю!). Комментаторы, конечно же, указали на существование mtasc. Но это уже тема отдельного разговора: osFlash. Так или иначе, я тоже вижу перспективным использование mtasc, хотя это сопряжено с риском (связанным с поддержкой, совместимостью итд.).

Заслуживает интереса мнение одного из комментаторов (Pranav), описывающего разработку ERP-клиента на Flash, где было создано около 200 000 строк AS2-кода. Были взяты Java-разработчики и переучены на ActionScript. Проект начался с энтузиазмом, но впоследствии все пришли к выводу, к которому я тоже в свое время пришел: у Flash ActionScript нет будущего как языка программирования. Но луч надежды - это ActionScript 3. В него остается верить :)