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