Короче говоря, я пытаюсь найти стек процессов / технологий для разработки веб-приложений, который легко / быстро / гибок для создания прототипов, но имеет четкий путь обновления до надежной производственной платформы.
Я прошу прощения за длинное описание ниже, но проблема между технологией и процессом, и я не могу найти простой / короткий способ выразить это.И да, я прочитал статью «Хорошая субъективная, плохая субъективная».
В настоящее время мы используем Java EE со всеми ударами и свистками (гибкая, непрерывная интеграция, отслеживание проблем, модульное тестирование, hibernate / spring / stripes / jqueryстек ...).Мы также используем гибкий процесс определения / анализа проектов с параллельным сбором функций, созданием макетов GUI (слава Balsamiq Mockups) и последующим прототипом статических HTML-страниц.Во время разработки мы часто выполняем промежуточные сборки с отзывами клиентов.Поэтому, как только мы дойдем до фазы тестирования, функциональность на 90% намечена, и все, что нужно, - это исправление некоторых ошибок и окончательная доработка.
Для наших традиционных клиентов, например банков и фармацевтических препаратов, вышеуказанный стек процессов / технологий работаеткак очарование.
В последнее время, однако, мы разрабатываем для интернет-стартапов.В этом случае процесс совсем другой.Мы начнем с некоторых базовых макетов, а затем создадим первый очень сырой прототип (множество статических страниц + некоторая базовая функциональность для покрытия основных сценариев).Затем мы начинаем разработку полноценного приложения.
Критический шаг здесь! Когда приложение выходит в открытый доступ, маркетологи / бизнесмены получают отзывы от ранних пташек, наблюдают за конкуренцией, они делают своивыводы и хочу изменить приложение. A LOT! Но на данный момент мы больше не находимся в режиме прототипа, у нас есть хорошее надежное приложение Java EE производственного качества со встроенными сотнями модульных тестов. Мы можем его развивать, но это, безусловно,не легок и не проворен.
1) Со стороны процесса мы пытались придать спецификации все доступные визуальные и формальные инструменты, но тщетно;никто не может исправить спецификацию до того, как рынок скажет.
2) Мы попробовали более «гибкие» среды, такие как RubyOnRails и PHP.
2.a) Для качества на уровне производства все ещекажется немного неделя по сравнению с Java EE (да, я знаю, что некоторые из наиболее важных сервисов / приложений написаны на PHP)
2.b) Если мы используем их «гибко», ониотлично подходит для создания прототипов, но затем мы получаем код, который трудно повысить до качества продукции.
2.c) Если мы реализуем все лучшие практики (многоуровневое, модульное тестирование ...), сложность становитсясравним со сложностью стандартной Java EE, которая у нас уже есть.
3) Когда приложение запускается в эксплуатацию, оно должно быть отшлифовано и надежно, поэтому создание простого прототипа не вариант.
4) Если мы предлагаем сделать одноразовый прототип, клиент отказывается рассматривать его как одноразовый и просит довести его до качества продукции (не желая платить за разработку с нуля).
Итак, bКроме того, мы ставим «качество» (предполагаемую структуру, надежность) слишком рано в процессе, когда оно не нужно и когда оно мешает изменениям и гибкости.
Есть идеи?