В этом блоге я совсем недавно упомянул о RAD. При поверхностном взгляде на эту методологию можно упустить ключевую деталь. Без нее окажется, что почти все сайты создаются по RAD.
-- Как расшифровывается «RAD»?
-- Rapid application development.
-- Быстрая разработка приложений?
-- Да.
-- Сайт за два месяца — это ведь быстро?
-- Достаточно быстро.
-- Так значит все, кто делает сайт быстрее двух месяцев — RAD-разработчики. При этом большинство из них об этом даже не догадывается. Можно подсказать им использование звучной аббревиатуры в маркетинговых целях. Ха-ха!
Так где же зерно?
Идею с итерационным изготовлением прототипов легко вписать в любой проект: всё равно заказчику показывается несколько версий сайта. «Квалифицированная команда» и «толковый менеджмент» — также расплывчатые составляющие RAD.
Ключевой вопрос: «Почему сайт разрабатывается так быстро?»
Программисты быстро печатают? Работают по четырнадцать часов в сутки? А может, время экономится на стадии проектирования за счет ее исключения из процесса? Это всё не RAD.
По-моему самым ощутимым элементом RAD является активное использование специализированных инструментов. Понятие «RAD tools» тесно связано с «CASE tools», но не уверен, что это одно и то же.
Идеальная сторона методологии предполагает рисование диаграмм и разработку правил, из которых генерируются прототипы ПО. А потом полученный код лишь тонко настраивается. То есть всё проектируется настолько детально, что даже программа способна сгенерировать приложение по составленному описанию.
На практике генерация приложений из набора диаграмм сильно ограничена объективными причинами. Например, качественного CASE-софта мало, и он дорого стоит. Чтобы им пользоваться, нужно серьезно учиться. Да и работает он не всегда, как заявлено. Но дело движется в лучшую сторону.
В скором времени планирую рассказать о некоторых инструментах. В результате попробую собрать комплекс RAD tools для разработки сайтов.
А пока советую почитать статью «Rapid Application Development» на blueink.biz. Из нее можно, например, узнать о том, что такое «time boxing».
Дмитрий Сергеев, 26 лет, разрабатываю сайты на Drupal, управляю интернет-проектами
Комментарии
Reno Jimmy, 19.02.2007 09:40
Не всё так плохо с генерацией приложений. Тот же PowerDesigner из логической модели данных умеет делать физическую модель (схему таблиц бд), а потом и генерирует sql-запросы для экспорта структуры.
Получается, нарисовали модель предметной области, а программа из нашего рисунка делает бд. Конечно, сгенерированный sql иногда не учитывает особенности конкретных субд и запросы приходится править ручками, но эффект ощутим.
Дмитрий Сергеев, 19.02.2007 18:01
Хочется чего-то большего. Например, генерации форм для добавления, редактирования и удаления записей. Да еще чтобы их можно было настраивать и можно было бы настраивать связи "многие ко многим".
И чтобы всё это само собой собиралось в администраторскую панель. Из views собирались бы страницы сайта, да чтобы выборки были взаимозависимыми :)
Dead Krolik, 27.02.2007 16:51
Это конечно здорово - RAD и всякие умные штуки вроде CASE. Но взглянем трезво - мы же сайты делаем, а не авианосцы. Весь RAD для сайтостроительства сводится к правильной CMS или CMF. Т.е. некой базе, на основе которой все остальное и строится. При чем строится по законам именно данной CMS, а не правильным мыслям в голове у сайтостроителя.
Дмитрий Сергеев, 27.02.2007 19:15
Да, мне тоже нравятся всякие умные штуки вроде RAD и CASE :) Может что-нибудь и пригодится.
К тому же далеко не все сайты можно собрать на базе CMF, не говоря уже о CMS. Даже в масштабных проектах вроде Drupal нередко отсутствуют очень нужные компоненты.
Иногда разработчикам удобнее взять какой-нибудь web application framework. Или даже пользоваться генераторами кода.
По-моему, всё же не будущий сайт определяется возможностями CMS, а как-то наоборот. То есть, мы сначала предъявляем требования к системе, а потом смотрим, как лучше сделать: взять готовую платформу или набор инструментов уровнем пониже возможностями побогаче, или вообще написать своими силами.
А RAD скорее посвящена организации процесса разработки в целом, нежели программированию.
Dead Krolik, 27.02.2007 21:22
>Может что-нибудь и пригодится.
В сайтостроении вряд ли. Рынок такой. Заказчикам не нужны умные мысли, им нужен товар. И чаще всего пофигу как и на чем это сделано. Внедрение всяких технологий - это удорожение процесса разработки, следствием чего является выбрасывание из зоны конкуренции.
>Даже в масштабных проектах вроде Drupal нередко отсутствуют очень нужные компоненты.
Прикол не в том, что они отсутствуют, а в том, что те что присутствуют не надо создавать с нуля.
>сначала предъявляем требования к системе, а потом смотрим, как лучше сделать: взять готовую платформу или набор инструментов уровнем пониже возможностями побогаче, или вообще написать своими силами.
Если действительно существует поток создания сайтов или чего-то подобного то платформа выбирается раз и навсегда. Иначе выбор платформы каждый раз - это удорожание процесса.
Дмитрий Сергеев, 27.02.2007 22:02
Скажем, приходит заказчик. И ему нужно, чтобы на форуме могли писать незарегистрированные пользователи. А студия "на потоке" всем ставит Ваниллу. Штука в том, что архитектура этой BBS не позволяет анонимным пользователям писать сообщения. И как-то это исправить достаточно проблематично.
У студии есть выбор: убедить клиента отказаться от «глупой» идеи или подобрать другой форумный движок. Первое может плохо кончиться, второе требует времени.
Проблемы не возникнет, если разработчики эрудированны и на деле знают штук пять BBS. Если не развивать кругозор, а концентрироваться на конвейере, эффективность вырастет, но интересных клиентов можно упустить. К тому же работать «на потоке» может быть скучновато.
Персонал должен учиться, иначе в одно прекрасное утро конкурентные преимущества будут упущены.
Звучит красиво, но в действительности можно просто нанять программистов «получше» и работать «на потоке». И всё будет хорошо.
Но почему-то мне кажется, что хорошие специалисты привыкли постоянно учиться и экспериментировать. Сдерживать их может быть тяжело. А, значит, на конвейере будут работать середнячки.
Такие вот построения. Не думаю, что рынок уже настолько сформировался и затраты на изучение новых технологий столь значительны, чтобы настолько серьезно говорить о конкурентных преимуществах в этой сфере.
Dead Krolik, 28.02.2007 20:19
Я бы не стал вместе соединять работу и изучение новых технологий. Это должно быть, но цель - это бизнес. А новые технологии должны приниматься только после тщательного изучения и если они принесут больший доход.
Дмитрий Сергеев, 28.02.2007 22:33
Не совмещать обучение сотрудников с работой могут позволить себе только крупные компании.
Содержать экспертов, которые будут «тщательно изучать» новые технологии и делать выводы о целесообразности тоже дорогое удовольствие.
Поэтому как-то всё это совмещается. Пропорции разные, но, думаю, «чистых конвейерных рабочих» в веб-разработке немного. Хотя согласен, что обучать начинающих на реальных проектах в ущерб заказчику по меньшей мере неэтично. И рискованно к тому же.