На gamedev.ru пользователь AlexeyLarin создал тему с интересными вопросами о резюме программиста в геймдеве. Я ответил на форуме, а тут приведу развёрнутые версии ответов.
Продолжение жизни и работы с ошибками — обсудим штуки на уровень выше.
Эссе получилось большим, но точно найдутся упущенные моменты. Если я что-то забыл — пишите. Буду благодарен и за более интересные примеры.
Итак. Давайте подумаем, как мы предсказываем будущее всякое.
Предсказаниями мы занимаемся постоянно — это буквально суть нашего существования:
Это примеры «гарантированных» предсказаний, но даже они могут не исполнится:
Фактически, мы никогда не знаем актуальное состояние мира вокруг нас:
Мы даже не обладаем всей информацией о прошедших событиях.
Поэтому.
Каждое наше решение и действие основывается на предположениях о прошлом, настоящем и будущем.
Штуки, которыми мы создаём предсказания, называются моделями.
В теории с миграциями всё сложно. Но на практике надо с ними работать. Или совсем отказаться от них. Посмотрим какие рабочие варианты существуют.
В основном я пишу на Python, использую реляционные БД, поэтому и инструменты буду смотреть с ориентировкой на эти технологии. Конечно, только open source. На полноту обзора не претендую.
Если я упустил какой-то софт или описал его с ошибками — пишите в комментариях или в личку — исправлю. В конце концов, досконально изучить документацию всех утилит я не пытался — это потребовало бы слишком много времени.
Недавно смотрел чего за последние годы сделано в области решений для миграций схем и данных в базах данных и как-то мне все решения не понравились. По крайней мере из open source ни одного проекта без косяков нюансов не нашёл.
Поэтому я решил порефлексировать и копнуть глубже — миграции баз данных всегда казались мне частным случаем общей проблемы обновления версий проекта.
Я предполагаю, что вы более-менее понимаете суть миграций в БД и сможете ориентироваться в моих допущениях: явных и неявных.
Первая часть эссе описывает миграции, пользу и проблемы от них. Вторая часть — мои пожелания к идеальной системе миграций.
Экспресс пост в ответ на вопрос.
Кратко: чтобы лучше кодить, надо больше кодить :-) и вдумчиво читать код.
Если чуть подробнее, то вопрос сложный и что-то посоветовать из чтения мне сложно:
Я больше писал, чем читал :-D В итоге, когда я начал читать шаблоны проектирования, я подумал: «и что тут такого, я уже с этим сталкивался», когда листал совершенный код, я подумал аналогично. То есть моя практика обгоняла теорию.
Из книг я читал то, что советовали преподаватели в универе, благо было кому советовать, и то, что считал интересным. Страуструпа, например, 2 раза прочитал.