Как мы разрабатываем веб-приложения

Пока фреймворк находится в альфа-версии, и готовых полезных приложений всего одно-два, процесс разработки приложений для фреймворка имеет характер исследовательской дейтельности. Работа очень увлекательна, но в определенном смысле мучительна. Решение большинства текущих задач по фреймворку сводится к поиску паттернов, которые впоследствии будут применятся или рекомендоваться к применению в других приложениях. Например, приложение «Сайт» с дизайн-редактором, который должен подойти и для «Блога», и для шаблонов email-уведомлений, и для будущего Shop-Script; приложение «Блог» с плагин-структурой, архитектура которой должна подойти для многих других приложений; приложение «Поддержка», на котором отрабатывается системный механизм рабочих процессов (workflow); API, актуальный практически для любого приложения Вебасиста и т.п. Требуется много пробовать и принимать довольно ответственные решения, поэтому выпускать новые приложение не получается так быстро, как бы нам этого хотелось (например, как были сделаны «Списки дел»).

Расскажу немного о том, как мы разрабатываем приложения, из каких этапов состоит разработка. Опыт нашей команды в разработке веб-приложений насчитывает уже более десяти лет. В разное время мы пробовали всяческие подходы к веб-проектам: и писали с нуля, и на основе готовых решений, делали проекты для хостирования у себя, для хостирования где бы то ни было, и с подробными техзаданиями, и с зарисовками только на листочках. При разработке мы никогда жестко не придерживались каких-либо методологий разработки, таких как agile или waterfall, и не придерживаемся сейчас. Процесс у нас ближе, пожалуй, к agile, но не является таковым в чистом виде. Это отдельная тема, и о ней как-нибудь в другой раз — сейчас же расскажу о этапах, из которых состоит разработка каждого приложения на основе фреймворка Вебасист.

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


1. Проектирование и дизайн.
   
   Этап, на котором все идеи из головы постановщика задачи должны быть сформулированы в виде готового макета приложения. Подчеркну: готового макета приложения. Результат этого этапа — готовый HTML-макет всех ключевых экранов приложения, который передается разработчику на следующий этап (этап программирования).


   
   Мы не пишем никаких подробных техзаданий. Иногда делаем короткие PDF-файлы с описанием отдельных мыслей, но стараемся обходится и без этих файлов. Техзадание, фактически, готовится в виде макета интерфейса, по которому потом сразу ведется программирование. HTML-макет сделать быстрее, чем описывать то же самое словами. На макете сразу можно опробовать разные варианты оформления, затраты на корректировки минимальны. Также удобно коллективно обсудить, как будет выглядеть приложение.
   
   
Кроме бумажных эскизов приложения мы стараемся не делать ничего, что заведомо придется выкинуть.

   
   
2. Программирование и тестирование.
   
   
Тут ничего нового: разработка структуры БД, программирование, трекер заданий, задачи, тестирование, задачи, тестирование.

   
   
3. Внедрение.
   
   

Это своего рода «краш-тест» приложения: выпускаем приложение только для себя, начинаем пользоваться приложением внутри компании, в личных целях, устанавливаем друзьям. Пользуются приложением и разработчики, и те, кто не участвовал в разработке, поэтому на этапе внедрения становятся очевидными практически все моменты, которые были сделаны плохо или необдуманно. Как правило, даже для довольно сложных приложений хватает двух-трех недель, чтобы провести полноценное внедрение, а это здорово экономит время, которое бы так ушло на исправление недоработок и выпуск патчей.
   
   На самом деле, вообще мало кто из разработчиков отводит время на то, чтобы внедрить свой продукт для себя и попробовать попользоваться им — вместо этого стараются побыстрее выпуститься, а уж пользователи потестируют. Я с таким подходом не согласен принципиально, и поэтому считаю третий этап внутреннего внедрения нашим «секретным оружием».


   
   Публичное «бета-тестирование» мы пока не делаем, но когда это потребуется, обязательно внедрим и такую практику.
   
   Внедрение заканчивается, когда все основные вопросы улажены, и когда чувствуешь, что после публичного выпуска можно будет продолжить заниматься дальнейшим развитием приложения, а не исправленим недоработок.
   
   

Так чего особенного и нового в таком делении на этапы разработки? Нового, пожалуй, ничего. Особенного — тут стоит выделить два ключевых момента: это наличие всех трех этапов и их независимость.

Во-первых, наличие этапов. Без этапа программирования, конечно, не обходится никакая разработка, поэтому стоит говорить только о первом и третьем. Основной секрет заключается в том, что каждый из этапов должен быть и быть полноценным. Большинство команд разработчиков в погоне за временем экономят на проектировании и внедрении, то есть, фактически, пропускают или сокращают первый и третий этапы (серьезно) — «дизайн прикрутим во время разработки», «выпустим, а пользователи сообщат об ошибках». В этом кроется большое упущение, потому что приводит к тому, что на весь проект уходит, наоборот, больше времени. Мы это ощущали на себе много раз.

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

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

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