пятница, января 06, 2006

Подходы к разработке сложных 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. В него остается верить :)

Комментариев 6:

Anonymous Майкл Клишин сообщает:

На самом деле 200 000 строк -- это шиза даже для Java / Cpp. Тут разочароваться омжно во всем на свете, если система сильно сцеплена или на планирование забили совсем (как вариант -- провели его бездарно).

Вот что бы сказали на подобное AS1-приверженцы, мне интересно:) Хотя как ни крути, для RIA и 20 000 строк -- не повседневное явление. Я думаю, ты согласишься.

06 января, 2006 20:04  
Blogger Constantiner сообщает:

Но, так получилось, что мне приходится участвовать в AS2-проектах, где по-любому число строк превышает 20 000. А проектирование таких систем... Я, все-таки, придерживаюсь идеологии XP: на начальном этапе ты выбираешь технологию, анализируешь основные требования (то есть те, которые составляют суть системы) и, соотвественно, делишь систему на подсистемы. Вот, собственно, и все проектирование. А дальше рефакторинг рулит. Но на практике квалификации современных российских AS2-разработчиков на это не хватает, а идеология старшего(ведущего) программиста все равно не рулит (один человек не сможет адекватно вести 5-6-10 человек. Надеяться, что во Flash-разработку придут люди с опытом из мира, например, Java - сложно. Слишком большая разница в зарплатах. Так что приходится постоянно быть на передовой :)

06 января, 2006 20:27  
Anonymous Fix сообщает:

Готов подписаться под каждым словом в этом топике. Я веду проект, который сейчас насчитывает 310 классов. Приложение осбирается из 1-кадровый кусков. Графическую часть компилирую во Flash IDE, классы вкомпиливаю потом при помощи MTASC. Чистые библиотеки классов компилирую вообще без участия Flash - только MTASC.
Насчет писания своих UI компонентов почти полностью согласен - времени (денег) на написание своих уходит куча и в итоге они чаще всего заточены узко под конкретное приложение (для скорости реализуется только требуемый в данный момент функционал) и потом часто приходится возвращаться к их доработке.
Но стандартные компоненты хороши для быстрого создания стандартных интерфейсов, а если нужно реализовать что-нибудь необычное.. не всегда получается закастомизировать стандартный компонент как хочется.

ЗЫ: Ну ты и темп взял - а говорил, что редко постить будешь :))

09 января, 2006 11:43  
Blogger Constantiner сообщает:

2fix
Что-то я не встречал еще задачи невозможности закастомизировать стандартные компоненты как мне хотелось :) Хотя, конечно, многие видя приложения с кастомизированными компонентами тут же спрашивают про то, что это я сам писал компоненты, и когда я говорю, что стандартные v2 - не верят :)

09 января, 2006 12:05  
Anonymous Andriy Panas сообщает:

Очень хорошо все отмечено, я со всеми пунктами согласен. У нас в компанни тоже поддерживается большой проект, тоже на АС2 (1400 файлов сейчас: ~100 MXML и 1300 AS классов), но мы используем Flex 1.5.

Мы используем свой фреймоворк, можна сказать конкурент ARP и Сairnigorm.

Фреймворк вырос на плечах Сairnigorm.

26 января, 2006 12:52  
Blogger Constantiner сообщает:

2Andriy Panas
Везет вам! Мечтаю найти заказчика на Flex :)

26 января, 2006 21:06  

Отправить комментарий

Ссылки на пост:

Создать ссылку

Вернуться на главную