пятница, 9 июля 2010 г.

Synchronet.ru

Недавно компания «Синхро системс», в которой я работаю ведущим Flash-разработчиком, объявила о запуске своего нового продукта Synchronet.ru.

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

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

Управлять всем  этим функциональным великолепием пользователь может в окне браузера, при помощи клиента, разработанного на базе платформы Adobe Flash. Собственно, я как раз и занимался разработкой этого клиента. Работал я не один, а в сотрудничестве с еще двумя Flash-разработчиками. С этими товарищами приятно работать, за что я им искренне благодарен.

Вообще, процесс разработки получился весьма интересным как с технологической, так и с методологической точки зрения. Например, наряду с каскадным планированием в процесс органично вплелись элементы eXtreme Programming. Что бы там не говорил Кент Бек (Kent Beck), XP с успехом можно внедрять частично, не загоняя весь процесс в рамки этой концепции.

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

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

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

Как я уже говорил, технологическая сторона проекта тоже оказалась очень интересной. Разрабатывать Flash-клиент я решил на основе фреймворка PureMVC MultiCore и совершенно об этом не жалею. Да, PureMVC имеет особенность, которую условно можно посчитать недостатком – работая с ним необходимо писать, на первый взгляд, избыточное количество кода. Грубо говоря, то, что можно прототипировать за пару часов, в базисе PureMVC может раскладываться пару дней. Но это является серьезной проблемой лишь на первый взгляд. Достоинства фреймворка начинаешь понимать, когда требования к функционалу начинают активно изменяться и дополняться. Ты не задумываешься, как правильнее ввести новый функционал или изменить уже имеющийся, сколько кода придется переписать, как удержать в голове все внутренние зависимости кода, как объяснить коллеге, чего ты тут понаписал и т.д. Ты просто программируешь согласно концепции, которую диктует PureMVC и пребываешь в полной уверенности в том, что все будет хорошо.

Поскольку клиентская и серверная части разрабатываются параллельно, иногда возникает ситуация, когда на сервере пока отсутствует интерфейс, необходимый для отладки функционала, который в данный момент разрабатывается на клиенте. В таких ситуациях мы используем mock-объекты на основе пакета ASMock, имитирующие полноценные PureMVC-прокси, которые ведут себя так, словно они взаимодействуют с сервером. Конечно, можно было обойтись без ASMock и написать заглушки вручную, но mock-объекты проще программировать и они располагают к модульному тестированию, необходимость в котором вот-вот назреет.

С точки зрения UI, мы, по большей части, обошлись стандартными компонентами Adobe Flex, изредка вворачивая элементы FlexLib или что-то уж совсем оригинальное. А вот наш дизайнер периодически нас озадачивал. Дело в том, что его фантазия никак не увязана с техническими ограничениями скинирования во Flex. Так что иногда мы использовали пакет Degrafa, а в особо клинических случаях – психологическое давление на дизайнера.

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