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

[metaclass]

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

Comments

[falcrum.livejournal.com]

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

[dizel-by.livejournal.com]

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

[bydlorus.livejournal.com]

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

[metaclass.livejournal.com]

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

[falcrum.livejournal.com]

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

[metaclass.livejournal.com]

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

[falcrum.livejournal.com]

Обоснуй.

[metaclass.livejournal.com]

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

[jakobz.livejournal.com]

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

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

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

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

[fraks-nsk.livejournal.com]

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

Вообще-то база изначально в виде текста и существует, исходник так сказать.
Можно поставить вопрос иначе - а что используется для преобразования исходного текста в какую-нибудь визуализацию?

[jakobz.livejournal.com]

База существует в виде понятных ей одной бинарных файлов. Ну, и часто - в виде diff-скриптов в source control-е, которые если последовательно запустить - получится такая же база. Где ты там исходник видел?

[metaclass.livejournal.com]

У меня два разных исходника: для создания с нуля и для миграции между разными версиями.
В конечном итоге - diff-скрипты и есть исходник.

[jakobz.livejournal.com]

А как ты эти исходники синхронизируешь?

[metaclass.livejournal.com]

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

[theaspect.livejournal.com]

Ребе, а ты используешь какую-нибудь тулзу для накатывания и донакатывания миграций?

[fraks-nsk.livejournal.com]

Что бы эти бинарные файлы создать требуется дать серверу команды.
Либо эти команды даются в текстовом виде скриптом и это и есть исходник
либо это делается через ГУЙ.

Если у какого-то сервера есть возможность создать объекты в базе только через гуй и мышку - это адов пиздец и втопку такой сервер.

Некоторые сервера даже бэкапы баз делают в текстовый вид.

[jakobz.livejournal.com]

Речь о том, что исходники базы обычно являются последовательностью SQL-команд, которые меняют схему от начала существования базы. Читать это чтобы понять текущую схему базы никто в здравом уме не будет.

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

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

[fraks-nsk.livejournal.com]

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

[jakobz.livejournal.com]

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

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

[berezovsky.livejournal.com]

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

[jakobz.livejournal.com]

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

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

[berezovsky.livejournal.com]

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

[jakobz.livejournal.com]

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

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

[berezovsky.livejournal.com]

Серьёзно. Но это, похоже, в рамках одной конторы.

[jakobz.livejournal.com]

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

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