почему все не используют инструменты RAD? [закрытый]

Нет Silver Bullet .

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

Ни один инструмент RAD не может исправить ошибки, сделанные на ранней стадии в SDLC . На самом деле может произойти и обратное: разработчики, использующие эти инструменты, могут быстро создать код для плохой спецификации. Это создает иллюзию, что они продуктивны, хотя на самом деле создается не тот продукт.

Инструменты RAD не позволяют настраивать записи самостоятельно. Заказчик обычно говорит что-то вроде «Было бы неплохо, если бы он работал именно так», что было бы очень быстрым изменением, если бы вы его закодировали, но потребует от вас изучить инструмент, чтобы увидеть, возможно ли это изменение (и расстраивает клиент, если это не так).

Кроме того, у вас больше контроля над тем, что делается, и меньше вероятность того, что у вас будет странное поведение, вызванное неправильными предположениями. Также легче писать тесты.

Наконец, это совершенно новая вещь, которую нужно изучить,

Быстрая не всегда означает точность. Я могу вспомнить пример: если бы кто-то разрабатывал кардиостимулятор, я бы предпочел, чтобы они потратили 400 часов на его исправление, вместо того, чтобы разрабатывать его всего за 40 и рисковать потенциально катастрофическим результатом.

Не совсем так. Они могут повысить производительность для некоторых задач, но не для всех. И большинство IDE уже содержат множество инструментов для повышения производительности. Например, шаблоны кода и автозавершение кода. Поэтому я не думаю, что они могут выполнить 10-20 раз для всего проекта,

Нельзя доверять инструменту RAD в написании чистого, поддерживаемого кода. Просто убедитесь сами, используйте Visual Studio Designer, перетащите сетку данных и соединение с базой данных, а затем проверьте беспорядочный код, который он сгенерирует, если вам нужно настроить что-то, что не было предусмотрено разработчиками мастера, вы окажетесь в много неприятностей. Как теперь вы будете поддерживать код? Все так запутано и тесно связано.

Когда вы решаете использовать инструмент RAD, вы принимаете определенные жертвы:

• Глубокое знание кода / системы - это то, что очень трудно получить, когда вы сгенерировали большую часть своего кода или позволил инструменту RAD помочь.

• Гибкость может быть потеряна; некоторые инструменты отменяют любые внесенные человеком изменения и регенерируют код, как они умеют. Лично я считаю, что эти инструменты должны уметь определять, когда изменения были внесены человеком, и, по крайней мере, отказываться запускаться - человеческие изменения всегда должны иметь прецедент.

• Часто эти инструменты могут помочь в разработке новых мест, но оставляют чудовищное количество кода, который нужно поддерживать. Заявления об увеличении производительности от 10 до 20 раз, вероятно, измеряются строками кода, а не фактическими готовыми функциями.

Если у кого-то уже есть команда привыкла к определенным IDE, какова цена изменения этого? Я имею в виду, что если я перейду с Visual Studio 2008 на Clarion или WinDev, готов ли мой работодатель оплатить расходы, которые будут связаны с моим увеличением? У меня также возникает вопрос, сколько стоят эти инструменты и какие гарантии, если таковые имеются, могут быть предоставлены, что они будут работать не хуже заявленных.

Нет никакой серебряной пули, и утверждения о 20x и т. Д. Стоят недоверия.

Однако большая часть этого - восприятие, упомянутое в других ответах в этой ветке. Они варьируются от простых («не может быть правдой») до общих («сложно настроить») и до общих («создает беспорядочный код»). Чтобы действительно сравнить, вам нужно сравнить конкретную среду 3GL с конкретной средой 4GL. У обоих будут сильные и слабые стороны. Оба, вероятно, позволят вам создавать хорошие или плохие программы.

Самая большая граница - это фактор навыков. Чтобы получить максимальную отдачу от любого инструмента, нужны время и усилия. Неудивительно, что пользователи 4GL часто являются самыми большими сторонниками этого, поэтому очевидно, что что-то в них работает для многих людей. Но обычно они стоят дороже (покупать), имеют свои особенности и свои сильные и слабые стороны. Трудно заставить программистов переходить из одной среды в другую.

В крупных организациях также есть много существующего кода, который нужно обслуживать. Если у вас есть команды разработчиков, трудно привести аргументы в пользу замены целой команды программистов с одного инструмента на другой. Даже если вы это сделаете, в команде не будет опытных пользователей, процесс обучения будет медленным и трудным. Опять же, это верно независимо от языка или среды.

Экономика также играет большую роль. Компаниям нравится быть в мейнстриме. Даже если стоит дороже. Им нравится идея, что отряды программистов могут писать код на «текущем» языке. Программисты - это товар, который приходит и уходит, и при необходимости их можно заменить. В мире полно программистов на C, Java, C # и т. Д. Выбор «маленького» языка приводит к бесконечным политическим проблемам, решения должны быть обоснованы и так далее. Это старый синдром «никого не уволили за покупку IBM». В конце концов, если деньги не имеют значения, тогда есть другие соображения, которые (политически) имеют большее значение.

Неудивительно, что большинство пользователей таких продуктов, как Clarion и Windev, являются либо независимыми программистами, либо членами очень небольших компании. В таких ситуациях повседневная экономика имеет большее значение, чем использование новейших инструментов или заполнение резюме. Представьте себе мир, в котором вам платят только при выходе программы. Внезапно чистая продуктивность стала иметь значение, и самое главное - сделать работу, чтобы вы могли есть.

Поскольку наемным работником работает намного больше людей, чем на себя, неудивительно, что большинству программистов не нужно напрямую беспокоиться о заработке. Если вы получаете зарплату независимо от того, чем пользуетесь, то можете плыть по течению. Если эта рухнет, то будет еще много рабочих мест. Таким образом, основные инструменты остаются основными, а все остальное игнорируется.

Тот факт, что многие из предубеждений, упомянутых в других ответах здесь, ложны, на самом деле не имеет значения. Восприятие - это все, и в двоичном мире правильного и неправильного, какой бы язык вы ни использовали сейчас, он является «правильным», а все остальное - «неправильным».

Если вы получаете зарплату независимо от того, чем пользуетесь, то можете плыть по течению. Если эта рухнет, то будет еще много рабочих мест. Таким образом, основные инструменты остаются основными, а все остальное игнорируется.

Тот факт, что многие из предубеждений, упомянутых в других ответах здесь, ложны, на самом деле не имеет значения. Восприятие - это все, и в двоичном мире правильного и неправильного, какой бы язык вы ни использовали сейчас, он является «правильным», а все остальное - «неправильным».

Если вы получаете зарплату независимо от того, чем пользуетесь, то можете плыть по течению. Если эта рухнет, то будет еще много рабочих мест. Таким образом, основные инструменты остаются основными, а все остальное игнорируется.

Тот факт, что многие из предубеждений, упомянутых в других ответах здесь, ложны, на самом деле не имеет значения. Восприятие - это все, и в двоичном мире правильного и неправильного, какой бы язык вы ни использовали сейчас, он является «правильным», а все остальное - «неправильным».

Восприятие - это все, и в двоичном мире правильного и неправильного, какой бы язык вы ни использовали сейчас, он является «правильным», а все остальное - «неправильным».

Восприятие - это все, и в двоичном мире правильного и неправильного, какой бы язык вы ни использовали сейчас, он является «правильным», а все остальное - «неправильным».

Я верю, что RAD Tools не дает гибкости при работе с кодом. Однако, если какой-либо конкретный инструмент RAD экономит 60-70 процентов времени разработки, стоит потратить на него время. Сегодняшние дни Квалифицированные разработчики пользуются пиковым спросом. Это приводит к увеличению коэффициентов истирания. Надежные разработчики увольняются только из-за 5/10% прибавки к зарплате. Это сильно влияет на девелоперские компании. Тот, кто сделал большую часть развития, внезапно уходит. Это серьезно сказывается на графике завершения проекта. RAD Tools делает организацию менее зависимой от опытных разработчиков. Самое главное, большинство клиентов меньше всего волнует, КАКИЕ технологии вы используете для разработки. Они счастливы, если их функциональные требования выполняются.

Все сказано и сделано, инструменты RAD будут иметь растущий спрос в текущем сценарии, когда истощение является высоким. Большинство проектов вылетают из графика именно из-за этой зависимости. Читатели могут отличаться.