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

[metaclass]

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

Comments

[metaclass.livejournal.com]

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

[jakobz.livejournal.com]

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

[metaclass.livejournal.com]

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

[jakobz.livejournal.com]

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

[metaclass.livejournal.com]

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

[theaspect.livejournal.com]

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

[metaclass.livejournal.com]

Самодельная софтина-обновлятор. Она все накатывает - базу, бинарники, итд.