RAD-инструменты, такие как Clarion и WinDev, утверждают, что в разработке они будут в 10x-20 раз быстрее, и пользователи этих инструментов заявляют о себе. Если это так, почему так мало людей используют эти инструменты? если приложение будет сделано за 40 часов вместо 400, вы сделаете гораздо больше денег, верно?Почему не все используют инструменты RAD?
Поскольку
Rapid не всегда означает точное. Пример, который я могу придумать, если кто-то разрабатывает кардиостимулятор, я предпочел бы, чтобы они потратили 400 часов на правильное решение, вместо того, чтобы развивать его только в 40 и рисковать потенциальным рискованным результатом.
Не совсем верно. Они могут повысить производительность для некоторых задач, но не все. И большинство IDE уже содержат множество инструментов для повышения производительности. Например, шаблоны кода и завершение кода. Поэтому я не думаю, что они могут управлять от 10 до 20 раз для всего проекта по сравнению с другими современными инструментами.
RAD-инструменты не дают вам настраиваемости написания вещей самостоятельно. Клиент обычно говорит что-то вроде «Было бы неплохо, если бы он работал именно так», что было бы очень быстрым изменением, если бы вы его закодировали, но вам потребуется изучить инструмент, чтобы увидеть, возможно ли это изменение (и расстроить клиент, если нет).
Кроме того, у вас есть больший контроль над тем, что сделано, и с меньшей вероятностью иметь странное поведение, вызванное неправильными предположениями. Сложнее писать тесты.
Наконец, это совершенно новая вещь, которую нужно изучить, рискуя, что потраченное время не стоит (может быть, так будет, но я не хочу рисковать узнать что-то слишком специфическое, что я, возможно, не буду использовать).
По моему опыту, инструменты RAD и IDE удаляют некоторые из сложностей кодирования, но мало что могут сделать для ускорения проекта. Основные достижения в области производительности заходят гораздо раньше в процессе разработки программного обеспечения, в частности, в определении характера, размера и объема проблемы, создания оценок и управления рисками.
Инструмент RAD не может исправить ошибки, сделанные на ранней стадии в SDLC. На самом деле может возникнуть обратное: разработчики, использующие эти инструменты, могут быстро изгонять код из-за плохой спецификации. Это дает иллюзию того, что они производят, когда на самом деле строится неправильный продукт.
Ударь меня к цитатам Брукса! – PTBNL
Когда вы решите использовать инструмент RAD вы принимаете определенные жертвы:
Интимная знание кода/системы одна вещь, которая очень трудно иметь, когда вы сгенерировали большую часть кода или разрешено инструмент RAD, чтобы помочь.
Гибкость может быть утеряна; некоторые инструменты будут отменять любые антропогенные изменения и регенерировать код, как они знают, как это сделать. Лично я считаю, что эти инструменты должны быть в состоянии определить, когда изменения были сделаны человеком и, по крайней мере, отказаться от запуска - человеческие изменения всегда должны иметь прецедент.
Часто эти инструменты могут помочь с разработкой greenfield, но оставляют за собой чудовищное количество кода. Заявки на прирост производительности от 10x до 20x, вероятно, измеряются строками кода, а не фактической законченной функциональностью.
Если у вас уже есть команда, используемая для определенных IDE, какова стоимость ее изменения? Я имею в виду, если я перейду из Visual Studio 2008 в Clarion или WinDev, мой работодатель подготовлен к тому, чтобы справиться с расходами, которые я буду наращивать? Я также задаюсь вопросом, сколько стоят эти инструменты и какие гарантии, если кто-либо может дать, что они будут делать, а также заявлять.
Вы не можете доверять инструменту RAD для написания чистого, поддерживаемого кода. Посмотрите сами, используйте Visual Studio Designer, перетащите datagrid и соединение с базой данных, а затем проверьте беспорядочный код, который он будет генерировать, если вам нужно настроить что-то, что не было предусмотрено разработчиками мастера, вы окажетесь в куча проблем. Теперь, как вы будете поддерживать код? Все так грязно и тесно связано.
Нет серебряной пули, а претензии 20x и т. Д. Стоят зерна соли.
Однако большая его часть - это восприятия, упомянутые в других ответах в этой теме. Они отличаются от простого («не может быть правдой») на общий («трудно настроить») на общий («генерирует грязный код»). Чтобы действительно сравнить, вам нужно сравнить конкретную среду 3GL со специфической средой 4GL. У обоих будут сильные и слабые стороны. Оба варианта, вероятно, позволят вам создавать хорошие или плохие программы.
Самая большая граница - это коэффициент мастерства. Чтобы получить лучшее от любого инструмента, требуется время и силы. Неудивительно, что пользователи 4GL часто являются крупнейшими сторонниками этого, поэтому ясно, что что-то о них работает для многих людей. Но они обычно стоят больше (покупать), имеют свои особенности и свои сильные и слабые стороны. Заставить программистов конвертировать из одной среды в другую сложно.
В крупных организациях также существует много существующего кода для удовлетворения потребностей. Если у вас есть команды разработчиков, трудно сделать случай для изменения всей команды программистов с одного инструмента на другой. Даже если вы это сделали, без существующего опытного пользователя в команде, процесс обучения будет медленным и трудным. Опять же это верно независимо от языка или среды.
Экономика также играет большую роль. Такие компании, как безопасность в основном потоке. Даже если это стоит дороже. Им нравится идея, что эскадрильи программистов доступны для написания кода на «текущем» языке. Программисты - это товар, который, как ожидается, придет и уйдет, и может быть заменен, когда это необходимо. Мир полон программистов на C, Java, C# и т. Д. Выбор «малого» языка, хотя и приводит к бесконечным политическим проблемам, решения должны быть оправданы и так далее. Это старый «никто не уволен за покупку IBM».В конце дня, если деньги не являются объектом, тогда есть другие соображения, которые (политически) имеют значение.
Неудивительно, что большинство пользователей таких продуктов, как Clarion и Windev, являются либо независимыми программистами, либо членами очень небольших компаний. В этих ситуациях ежедневная экономика имеет значение больше, чем использование последнего инструмента или заполнение CV. Представьте себе мир, где вам платят только, когда программа отправляется. Внезапно сырая производительность имеет значение, и самое главное - это сделать работу, чтобы вы могли есть.
Поскольку в работе работает намного больше людей, чем работающих на себя, неудивительно, что большинству программистов не нужно беспокоиться о выплате. Если вы получаете зарплату независимо от того, что используете, тогда вы можете пойти с потоком. Там есть еще много рабочих мест, если этот идет. Таким образом, основные инструменты остаются основными, а все остальное игнорируется.
Тот факт, что многие из предубеждений, упомянутых в других ответах здесь, являются ложными, не имеет большого значения. Восприятие - это все и в бинарном мире правильного и неправильного, какой бы язык вы сейчас ни использовали, является «правильным», а остальные - «неправильным».
Вы можете использовать тот же аргумент, чтобы ответить, почему люди используют java или php вместо python. Реальность такова, что AI не существует, и эти инструменты просто сосут. Эти «независимые программисты» вообще не являются программистами. Когда вам нужно поставить качественный продукт, вы будете полагаться на код, созданный каким-то инструментом? Я использовал RAD в течение 3 лет и позвольте мне сказать вам: я бы предпочел даже C. – Alvaro
Я действительно верю, что RAD Tools не дает вам гибкой руки по коду. Однако, если какой-либо конкретный инструмент RAD экономит 60-70 процентов времени разработки, стоит потратить время на это. В настоящее время квалифицированные разработчики находятся на пике спроса. Это приводит к увеличению коэффициентов истирания. Надежные разработчики уходят в отставку только за 5/10% рейза в платных байках. Это сильно влияет на компании-разработчики. Тот, кто сделал большую часть развития, внезапно уходит. Это серьезно отразится на графике завершения проекта. RAD Tools делает организацию менее зависимой от квалифицированных разработчиков. Самое главное, что большинство клиентов наименее обеспокоены технологией WHAT, которую вы используете для разработки. Они счастливы, если соблюдаются их функциональные требования.
Все сказанное и сделанное, приборы RAD будут иметь все возрастающий спрос в настоящем сценарии, где истирание высока. Большинство проектов вытащили из графика только из-за этой зависимости. Читатели могут отличаться.
Это написано «вы». – 2009-11-02 08:47:50
Используйте рамки и ORM. Генерация кода не является гибкой и приводит к программному обеспечению низкого качества. Если вы соблюдаете стандарты (рельсы, джанго или даже весна), любой разработчик может понять и расширить ваш код – Alvaro
Потому что эта фигура почти наверняка является чрезмерно завышенной претензией? Потому что люди не верят в маркетинг BS? – skaffman
Полностью согласен, я не верю в этот маркетинг bs, btw ... Я в дискуссиях с людьми, которые часто заявляют об этом тоже ... Я бы хотел доказать, что они ошибаются ... Я считаю, что языки, такие как java, C# , php и многие другие гораздо более мощные, чем эти два примера. – Sorskoot
и так же быстро, если вы знаете, что делаете ... – Sorskoot