Более гибкая альтернатива Java EE

Question

Вкратце, я пытаюсь найти стек процесса/технологии для разработки веб-приложений, который является простым/быстрым/гибким для прототипа, но имеет ясный путь обновления к надежной продукции Платформа.

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

В настоящее время мы используем Java EE со всеми ударами и свистами (гибкая, непрерывная интеграция, отслеживание проблем, модульное тестирование, спящий режим/весна/полосы/стек jquery ...). Мы также используем гибкий процесс определения/анализа проектов с сбором функций параллельно с макетами графического интерфейса (kudos to Balsamiq Mockups) и прототипом статических страниц HTML. Во время разработки мы часто проводим промежуточные сборки с отзывами клиентов. Поэтому, как только мы дойдем до этапа тестирования, функциональность составляет 90% от цели, и все это необходимо для исправления некоторых ошибок и окончательной пользы.

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

В последнее время мы разрабатываем для интернет-стартапов. В этом случае процесс совсем другой. Мы начинаем с некоторых базовых макетов, затем создается первый очень простой прототип (множество статических страниц + некоторые базовые функции для покрытия основных сценариев). Затем мы начинаем разработку приложения с полной версией.

Критический шаг здесь! Когда приложение публикуется, ребята из отдела маркетинга/бизнеса получают отзывы от ранних птиц, наблюдают за конкуренцией, делают свои выводы и хотят изменить приложение. МНОГО! Но на этом этапе мы больше не находимся в режиме прототипа, у нас есть хорошее надежное, качественное приложение Java EE для производства с встроенным встроенным тестом. Мы можем его развить, но это, конечно, нелегко и нелегко.

1) На стороне процесса мы попытались приглушить спецификацию со всеми доступными визуальными и формальными инструментами, но напрасно; никто не может исправить спецификации до того, как рынок говорит.

2) Мы попробовали более «гибкие» среды, такие как RubyOnRails и PHP.

2.а) За качество производства сорта, те до сих пор, кажется, немного недели по сравнению с Java EE (да, я знаю, что некоторые из наиболее важных услуг/приложений написаны на PHP)

2. б) Если мы используем их «гибким» способом, они отлично подходят для прототипирования, но тогда мы получаем код, который трудно поднять к качеству продукции.

2.c) Если мы реализуем все лучшие практики (расслоение, модульное тестирование ...), сложность становится сопоставимой со стандартной сложностью Java EE, которую мы уже имеем.

3) Когда приложение выходит в эфир, оно должно быть отполировано и надежно, поэтому простой прототип не является вариантом.

4) Если мы предложим создать прототип прототипа, клиент откажется рассматривать его как выброс и просит привести его к качеству производства (не желая оплачивать разработку с нуля).

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

Любые идеи?

Answer 1

Станьте гибким.

Серьезно, вам также нужно посмотреть на себя и на команду, а не только на «стек технологий».

Многие из вас стояли, где вы находитесь, просто совершите прыжок и возьмите «гибкую» альтернативу.

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

Возможно, вам не нужна альтернатива, вам просто нужно глубоко вникать в ваши текущие проблемы и исправить их. Разве это не то, что мы должны делать? Улучшить наше мастерство?

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