Важная задача, которую необходимо уметь решать на начальных стадиях IT-проекта: быстрое прототипирование требуемой функциональности. В настоящее время акцент делается на работу аналитиков, реже, технических архитекторов. Они пытаются понять нужды заказчика, затем производят некоторое количество документации и описаний. Хорошо, если эти специальсты владеют UML в достаточной степени. Но, даже если это так, и производимые аналитиком диаграммы не противоречивы и соответствуют стандартам, заказчик, в большинстве случаев, не имеет возможности проверить и в полной мере понять всех идей аналитика/архитектора.
Гораздо лучше будет ситуация, если разработчики проекта предоставят заказчику работающий прототип системы/приложения. Это не очень простая задача, так как разработчики привлекаются на достаточно поздних стадиях проекта, когда всем кажется, что стороны знают, как и что должно быть спроектировано и реализовано в проекте. При этом, у заказчика и разработчика в голове могут быть совершенно разные идеи. Далее, когда проект переходит в практическую стадию, эти разночтения могут приводить к весьма неприятным коллизиям и взаимному недовольству. Имея под рукой работающий прототип, можно решить большинство вопросов с заказчиком на ранней стадии проекта.
Итак, осталось только решить, как строить подобный прототип, с чего начать. При огромном разнообразии IT-практиков на рынке труда , людей, умеющих быстро построить действующее приложение, годное для демонстрации ответственным людям на принимающей стороне, - не так уж много.
Проблема здесь состоит в том, что при имеющемся разнообразии средств разработки ПО, очень немногие из них дают возможность произвести произвольный программный продукт по укороченному производственному циклу. Здесь и проблемы "тяжелых" баз данных, и сложные (как в J2EE) циклы сборки/распространения ПО.
на протяжении многих лет я занимался разработкой софта. Вопросы производительности здесь весьма болезненны. С годами, ситуация, похоже, улучшается незначительно. Все новые и новые попытки выпуска бесплатных или коммерческих инструментальных средств ведут к усложнению продуктов, циклов разработки/сопровождения. Создаются многочисленные новые принципы, спецификации, затем, весьма быстро нарушаются и заменяются новым и новым.
Зацепиться за что-то более или менее стабильное, поступательно развивающееся в этом хаотическом мире - задача разработчика.Изучив продук глубоко, научившись строить на нем системы, или системки в зависимости от нужд проекта, разработчик может весьма повысить собственную производительность и принести ощутимую пользу проекту.
На текущий момент мне видится следующая комбинация продуктов (это сугубо Java- мир, я не касаюсь .NET, так как не являюсь специалистом в этой области).
Итак,
Пользовательский интерфейс: Grails on Groovy. Текущая версия: Groovy - 1.3.7. IDE: Eclipse based STS версии 2.7.1
База данных: пока неопределенно.
Серверная часть, симуляция распределенной системы и messaging facilities : Camel.
Для поддержки асинхронных сообщений использовать ActiveMQ.
Задача на ближайшее время: используя вышеназванные средства, построить электронный магазин с удаленным (distributed) складом и приветливым пользовательским web- интерфейсом.
