Гуе-визардо-мышедизайнерская разработка софта

[metaclass]

А вот скажите, как вы относитесь к инструментам, в которых для подключения, например, к БД, нужно пройти 5-10 экранов визарда? Ну или там поработать полчасика в неудобном мышедизайнере.
С одной стороны, для начинающих это сильно снижает порог входа - нажимаешь "сделать чо нибудь", оно задает кучу вопросов и это чо нибудь делает. С другой стороны - внутренности либ для подобных инструментов чуть более чем всегда совершенно не
пригодны для обычной разработки - "чтобы создать что-то из кода, надо выполнить страницу неадекватных вуду заклинаний".
Я подобные вещи стараюсь не использовать, благо, разработчики все делают для того, чтобы это было неудобно и медленно для сколько-нибудь сложных задач и подобное ретроградство и луддизм находят понимание среди коллег, особенно тех, кто ничем, кроме текста и его редакторов, принципиально не пользуется.

Comments

[dizel-by.livejournal.com]

Я за любые визарды хочу убивать, например. За некоторые — с особой жестокостью. И да, я не пользуюсь ничем, кроме текста и его редакторов =))

[bydlorus.livejournal.com]

Так, за одним исключением - Restore Database в MSSQL. Вот не знаю почему.

[falcrum.livejournal.com]

Хочется спросить и тебя, и топикстартера: вы с БД, в которых не один десяток таблиц, работаете как - храня схему в голове?

[dizel-by.livejournal.com]

Ну да, а что? Структура правильно спроектированной БД помещается в гойлову, даже если там 100500 таблиц :)

[dizel-by.livejournal.com]

MSSQL не нужен просто

[bydlorus.livejournal.com]

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

[metaclass.livejournal.com]

Ну у меня чо-то порялка 400 таблиц в 4 оперденях.
Держу в SQL скриптах, которые под контролем версий. То, что разрабатываю в данный момент - закэшировано в голове.
Новые подсистемы - в кодогенераторе, который в свою очередь, модели хранит в БД. Думаю - оставлять в реляционной БД или переделать хранилище на текстовую БД, чтобы лучше дружило с контролем версий.

[w00dy.livejournal.com]

там жеж в визарде есть кнопочка "показать sql". Впрочем я тоже предпочитаю потыкать визард, так проще и быстрее.

[w00dy.livejournal.com]

Зачем такое говно использоваться? Я ещё понимаю один раз пройти можно, чтобы понять что оно там генерит и сделать аналогично вручную, но на постоянной основе на какое-то садо-мазо похоже.

[berezovsky.livejournal.com]

Программно конфигурировал иис, попал в психиатрическую клинику, в данный момент находится на реабилитации.
В одной известной Корпорации приходилось работать с софтинкой для создания PDF-документов.
Там было два режима работы. Хочешь - пиши XML, хочешь - тыкайся в кнопки дизайнера.
Сначала документы рисовали полностью вручную, потом полуавтоматически.
То есть общая структура документа была фиксирована, а сточки огромной отчётной таблицы генерировалась
из SAP/ABAP системы с помощью тех же фрагментов XML.
Так вот, если надо было что-то поправить, проще было залезть в разметку, переписать кусок,
и только потом смотреть, как это будет выглядеть, прости-господи-нерусское-слоо, отрендеренное.
Потому что, мать его, дизайнер, содержал столько глюков, что складывалось впечатление,
что его особо никто никогда не тестировал. Как посочувствовали в чатике, что-то типа "мерзкая штука".
Не помню точно, но один из типичных багов примерно такой был. Надо нарисовать, скажем, поле для емейла.
У него там четыре стороны, верхнее, правое, нижнее и левое. Чтобы это выглядело сносно,
нужно было выставить со всех сторон одинаковые поля. Для этого в дизайнере было пять контролов.
Для левого, верхнего, правого нижнего и общее - "All". Вот когда вводишь цифру в "All" (или стрелочками меняешь),
ожидаешь, что в остальных четырёх будет такая же цифра. А вот хуй - в трёх местах меняются, в одном остаётся старая.
Или меняются только в двух местах, причём случайным образом. Например, только верхнее и правое. Или верхнее и левое.
Как это можно было умудриться сделать, не представляю. Пытаешься исправить цифры руками -
меняются в соседних местах от балды. Бешено плюёшься и лезешь в XML.
Это ладно, ребята быстро понимали и могли сделать. А девочка-тестер даже в мышедизайнере всего не осиливала.

[falcrum.livejournal.com]

Ну да, "а потом этими же губами она будет целовать моих детей?" (с) В смысле, ну так нефиг тогда возмущаться, что никто не может тебя подменить хотя бы на время хотя бы на куске работы: не пробовал затянуть эти же sql-скрипты в bpwin какой - на предмет наглядности данных и связей промежду ними? Хотя от "опердени аж в 100 таблиц" я ржу в голос...

[metaclass.livejournal.com]

Пробовал. Нахрен такую наглядность.

[falcrum.livejournal.com]

Обоснуй.

[metaclass.livejournal.com]

Мне проще работать с однозначным представлением графов в виде текста, нежели в виде картинок. На картинках приходится скрывать часть информации, чтобы оно было читабельным.
Основную работу все равно приходится вести в тексте (контроль версий, сборка, итд). Два эквивалентных представления (внутренний формат ER/UML софтов и SQL-скрипты) создают лишнюю работу по преобразованию и могут привести к противоречиям.

[jakobz.livejournal.com]

В SQL Server есть диаграммы, в них можно прям потыкать всякие "добавить колонку", драг-н-дропом связи навести. Потом в ней же нажать "generate script", и с ним уже дальше что-то делать - миграцию данных туда дописать, в SVN какой положить как diff-скрипт.

Я пользовался когда надо сделать что-то посложнее добавления колонки. Ну и диаграммы просто сами по себе полезны таки.

[berezovsky.livejournal.com]

Отсутствует контроль над ситуацией.
Никогда не знаешь, что лишнего туда генератор напихает и заебёшься сравнивать каждый раз.
А когда каждый символ написан тобой, точно знаешь, чего ждать.
Если нужно видеть схему, почти любая мышедизайнер умеет реверс инжиниринг, как из базы, так и из скрипта.

[jakobz.livejournal.com]

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

[berezovsky.livejournal.com]

В винформс есть возможность для каждой локали свою вёрстку делать.

[jakobz.livejournal.com]

Так оно и делает реверс. Все что хранится дополнительно для схемы - это тупо координаты табличек.

Оно на удивление нормально генерирует скрипты. Которые потом уже живут в виде текста - ревьювятся, тестируются, выкладываются в контроль версий, откуда их потом CI прогоняет по тестовым и боевым базам.

[jakobz.livejournal.com]

А можно еще для каждой локали сделать бранч, например :)

Нафиг это не надо. Надо нормальные контролы для layout-а, в которые кладутся все эти textbox-ы. И тогда все это будет нормально растягиваться как надо. А дизайнер убрать, чтобы не было соблазна не включая голову руками по пикселям расставить, и получать нелокализуемые и нересайзящиеся хрени.

Даже в html-е это получается, хотя в нем только весьма ущербные таблицы, да div-ы столбиком или в ряд.

[berezovsky.livejournal.com]

Э-э-э, ты имеешь в виду, что CI лезет в репозиторий, берёт скрипт и прогоняет его по всем продакшенам?

[berezovsky.livejournal.com]

Ну да, в WPF это и сделали, только легче от этого не стало.

[jakobz.livejournal.com]

UI в MSSQL - это же туши свет какой ад. Мастера особенно. MSSQL уже с инсталятора тебя погружает в этот ихний волшебный мир.

[jakobz.livejournal.com]

А что ты используешь для представления базы в виде текста?

Просто в source control-е же этого нет ничего обычно - там diff-скрипты лежат от нулевой версии, которые чтобы получить текущее положение дел надо еще накатить.

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

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

[jakobz.livejournal.com]

CI (точнее спец. утилитка) лезет в репозиторий, смотрит что в нем нового относительно спец. таблички в базе, и накатывает скрипты в хронологическом порядке на:
- по коммиту - на базу-болванку, чисто отфильтровать сразу скрипты, которые падают
- по коммиту - на trunk-систему
- на системы девелоперов когда они забирают себе свежий код
- по кнопке/расписанию на QA/UAT-систему
- по кнопке на Staging-систему, куда скидывается база с прода
- по кнопке на прод

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