![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Гуе-визардо-мышедизайнерская разработка софта
А вот скажите, как вы относитесь к инструментам, в которых для подключения, например, к БД, нужно пройти 5-10 экранов визарда? Ну или там поработать полчасика в неудобном мышедизайнере.
С одной стороны, для начинающих это сильно снижает порог входа - нажимаешь "сделать чо нибудь", оно задает кучу вопросов и это чо нибудь делает. С другой стороны - внутренности либ для подобных инструментов чуть более чем всегда совершенно не
пригодны для обычной разработки - "чтобы создать что-то из кода, надо выполнить страницу неадекватных вуду заклинаний".
Я подобные вещи стараюсь не использовать, благо, разработчики все делают для того, чтобы это было неудобно и медленно для сколько-нибудь сложных задач и подобное ретроградство и луддизм находят понимание среди коллег, особенно тех, кто ничем, кроме текста и его редакторов, принципиально не пользуется.
С одной стороны, для начинающих это сильно снижает порог входа - нажимаешь "сделать чо нибудь", оно задает кучу вопросов и это чо нибудь делает. С другой стороны - внутренности либ для подобных инструментов чуть более чем всегда совершенно не
пригодны для обычной разработки - "чтобы создать что-то из кода, надо выполнить страницу неадекватных вуду заклинаний".
Я подобные вещи стараюсь не использовать, благо, разработчики все делают для того, чтобы это было неудобно и медленно для сколько-нибудь сложных задач и подобное ретроградство и луддизм находят понимание среди коллег, особенно тех, кто ничем, кроме текста и его редакторов, принципиально не пользуется.
no subject
no subject
no subject
Основную работу все равно приходится вести в тексте (контроль версий, сборка, итд). Два эквивалентных представления (внутренний формат ER/UML софтов и SQL-скрипты) создают лишнюю работу по преобразованию и могут привести к противоречиям.
no subject
Просто в source control-е же этого нет ничего обычно - там diff-скрипты лежат от нулевой версии, которые чтобы получить текущее положение дел надо еще накатить.
Можно, конечно, нарисовать тулзу, которая будет в текст высовывать все таблички, и связи. Но чот мне кажется сделать это в картинку - намного ловчее.
Я бы не отказался, скажем, от такой же визуализации зависимостей проектов, всяких диаграмм классов. Само собой на входе должен быть только код, и никаких больше дополнительных данных.
no subject
Вообще-то база изначально в виде текста и существует, исходник так сказать.
Можно поставить вопрос иначе - а что используется для преобразования исходного текста в какую-нибудь визуализацию?
no subject
no subject
В конечном итоге - diff-скрипты и есть исходник.
no subject
no subject
Особенно что касается живых данных в продакшене.
no subject
no subject
Создавать таблицы в стиле "добавил 10 полей, удалил 5, добавил еще 20" меня огорчает, поэтому я для новых деплойментов создаю базу из финальных скриптов.
Я в голове не смогу удержать разработку, если таблица будет разбросана по нескольким файлам.
no subject
no subject
no subject
Либо эти команды даются в текстовом виде скриптом и это и есть исходник
либо это делается через ГУЙ.
Если у какого-то сервера есть возможность создать объекты в базе только через гуй и мышку - это адов пиздец и втопку такой сервер.
Некоторые сервера даже бэкапы баз делают в текстовый вид.
no subject
Как минимум будут как-то выгружать из поднятой из исходников базы ее метаданные, и как-то их читать. Можно выгрузить SQL-скрипт, можно какой-нибудь еще текст красивый, можно картинку. Картинка для многих случаев очень удобна.
Никто не говорит про то, что картинку хранить в VCS и по ней поднимать базы. Нет, картинка - производная, артефакт получаемый из текстовых исходников.
no subject
>> начала существования базы. Читать это чтобы понять текущую схему базы никто в здравом уме не будет.
Как по мне - скрипты для перевода базы из старого состояния в новое - это не есть исходник базы.
Исходник - это один скрипт прогнав который получаем базу требуемой структуры.
Другое дело что когда в базе есть какие-то данные (а это практически всегда) то исходника обычно не достаточно и требуются специально написанные скрипты по изменению базы с данными. Они тоже нужны и хранятся в CVS но исходником не являются, это уже типа инструмент.
no subject
Речь идет только о схеме данных. Всякие хранимки и вьюшки - это тот же код, их надо хранить также как остальные исходники.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
Я пользовался когда надо сделать что-то посложнее добавления колонки. Ну и диаграммы просто сами по себе полезны таки.
no subject
Никогда не знаешь, что лишнего туда генератор напихает и заебёшься сравнивать каждый раз.
А когда каждый символ написан тобой, точно знаешь, чего ждать.
Если нужно видеть схему, почти любая мышедизайнер умеет реверс инжиниринг, как из базы, так и из скрипта.
no subject
Оно на удивление нормально генерирует скрипты. Которые потом уже живут в виде текста - ревьювятся, тестируются, выкладываются в контроль версий, откуда их потом CI прогоняет по тестовым и боевым базам.
no subject
no subject
- по коммиту - на базу-болванку, чисто отфильтровать сразу скрипты, которые падают
- по коммиту - на trunk-систему
- на системы девелоперов когда они забирают себе свежий код
- по кнопке/расписанию на QA/UAT-систему
- по кнопке на Staging-систему, куда скидывается база с прода
- по кнопке на прод
Никаких кривых рук на прод-систему в идеале вообще не допускается, для деплоя используется та же утилита, тот же набор скриптов, и тот же их порядок, который для этого использовался для поднимания нескольких тестовых систем, и проверен руками и роботами.
no subject
no subject
На многих других проектах варианты попроще в плане автоматизации, но вообще обычно порядок примерно такой везде. Иначе ад - забытые скрипты, базы потихоньку разъезжаются, девелоперы вынуждены работать с общей базой постоянно пересекаясь и друг другу все ломая.