Повышение производительности использования инструментов CASE для разработки

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

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

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

Я думаю, что хорошо использовать такие решения для ускорения процесса, но мне интересно, почему эти программы не так популярны, как VS.Net, J2EE, Ruby, Python и т. Д., Если они утверждают, что повышают производительность лучше, чем инструменты, которые я указал?

17.08.2008 07:08:41
4 ОТВЕТА
РЕШЕНИЕ

Мы используем инструмент CASE в моей нынешней компании для генерации кода и пытаемся от него отказаться.

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

Эти основные недостатки:

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

  2. Разработчики зависят от инструмента и «забывают», как писать код.

1
17.08.2008 15:21:50

Просто пара вопросов для вас:

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

Я не могу представить, что есть CASE, где я мог бы сначала написать тест, а затем использовать CASE для генерации кода, который мне нужен. Я бы предпочел придерживаться resharper, который может легко выполнять мои повседневные задачи и сохранять полный контроль над моим кодом.

0
17.08.2008 15:32:34

Первоначально проект, над которым я работаю, был разработан вместе с Oracle Development Suite для создания веб-приложения.

Со временем (более 5 лет) требования клиентов стали более сложными, чем первоначально предполагалось, и экраны было нелегко обслуживать. Таким образом, команда неофициально решила начать создавать пользовательские (вручную кодированные) экраны в веб-PL / SQL, а не создавать их с помощью инструментов Oracle Development Suite CASE (Oracle Designer).

Компонент Oracle Report Builder в Development Suite все еще используется командой, поскольку он, похоже, «выполняет работу» своевременно. В общем, разработчики, использующие инструмент Report Builder, не очень удобны в написании кода.

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

0
17.08.2008 22:17:46

К сожалению, инструмент Magic не генерирует код, а также не может реализовать шаблон проектирования. Я не могу контролировать причину кода, как я уже говорил, у него нет кода для изменения. Суть в том, что это может каким-то образом ускорить производительность, но у него нет возможности использовать CVS, а также шаблоны, и я не могу контролировать все детали.

Я согласен с Гэри, когда он говорит: «Кажется, что аспект производительности таких инструментов CASE сильно зависит от требований клиентов и наборов навыков разработчика / обучения / фона», но я также не могу согласиться с Klelky;

Эти основные недостатки: 1. Мы не можем выполнять автоматическое слияние, что делает практически невозможным параллельную разработку для одного компонента. 2. Разработчики зависят от инструмента и «забывают», как писать код вручную.

Спасибо

0
20.08.2008 13:25:53