Почему не все используют инструменты RAD?

Ответ 1

Поскольку

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

Ответ 2

Нет Серебряная марка.

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

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

Ответ 3

Нет серебряной пули, а претензии 20x и т.д. стоят соли.

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

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

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

Ответ 10

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

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