Как-то в бекенде школы меня перестало устраивать название приложения в Django. Когда я начинал проект, у нас можно было купить только курсы, и приложение с ними называлось courses. Потом к курсам добавились записи (record) и наборы (bundles). Конечно мне захотелось переименовать приложение courses в products, чтобы уменьшить когнитивную нагрузку при чтении кода.

К сожалению, я не нашёл ни одного решения, кроме стрёмного django-rename-app, который предлагал мне выполнять management-команды в консольке на проде. Кроме того, что это ломает любые пайплайны CI\CD, там ещё и код был не очень понятный. Так что в итоге я решил сделать это сам. Оказалось сложно, поэтому я написал эту инструкцию.

Исходные условия:

• CI\CD пайплайн, который запускает миграции при каждом деплое.
• Данные терять нельзя.
• Мы не стесняемся править старые миграции.

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

• Подменяем имя приложения в истории миграций: ./manage.py makemigrations <some-other-app> -n RenameOldApp --empty. Коммит.
• Деплоим миграцию на прод. После этого шага ничего нельзя деплоить до конца.
• Делаем новый пулл-реквест.
• Переименовываем папку с приложением: git mv courses products
• Заменяем все упоминания старого приложения в миграциях. Коммит.
• У всех моделей в новом приложения в Meta прописываем db_table с именем старого приложения. В моём случае, если модель называется bundle и лежала в приложении courses, нужно прописать db_table = 'courses_bundle'. Коммит.
• В старых миграциях, которые используют операцию CreateTable, добавляем новую db_table в options. Коммит.
• Меняем упоминания приложения в коде, можно автозаменой. Коммит.
• Проверяем, ./manage.py makemigrations --check. Новых автоматических миграцией был не должно, ошибок тоже.
• Деплоим на прод.

В итоге у нас получается два деплоя: первый подменяет миграции, а второй — код. В результате модели будут лежать по новому адресу, но ходить в старые таблицы. Для меня это было плюсом, т.к. не пришлось переделывать аналитические SQL-запросы, которые ходят в базу из Metabase.

Нас всех в детстве учили: если хочешь накопить себе на большую игрушку — приучайся экономить: трать поменьше, откладывай побольше. Это ужасный паттерн поведения, который сохраняется и во взрослом возрасте: поняв, что не хватает денег, мы начинаем экономить: пересаживаемся с такси на метро, ходим в магазины похуже, ведём строгий учёт бюджета. В запущенных случаях начинаем есть плохую еду.

Это неправильно потому, что силы, которые мы тратим на экономию, можно было бы потратить на то, чтобы больше заработать. Увеличить заработок можно всегда: договориться с боссом о повышении зарплаты, выучить новый язык и поменять работу, придумать пет-проект, который принесёт кучу денег, уйти с работы в собственный бизнес. Эти действия требуют сил — а если вы устали и полночи ругались с женой по поводу списка покупок на следующую неделю, вряд ли вы проведёте хорошие переговоры или вынесете что-нибудь полезное с нового образовательного курса.

Вместе с увеличенным заработком приходят возможности. Вот уже вместо списка покупок в «Ашане» вы заказываете доставку готовой еды, а освободившиеся 3 часа вкладываете в новый проект, который принесёт ещё больше денег.

Конечно я не призываю влезать в долги и тратить последние деньги, но что я точно знаю — лучше потратить силы, чтобы увеличить заработок, чем на то, чтобы уменьшить расходы.

Во всех коллективах, где я работал, самой большой ценностью для меня было услышать эту фразу. Не пассивное неодобрение, не мягкую критику, а именно «ты сделал говно». Неважно — про код, тексты, письма клиентам или результаты переговоров.

«Ты сделал говно» — это же самая обычная обратная связь. Когда коллектив видит говно, но не кричит о нём, его участники как бы соглашаются: да, у нас можно делать говно, и мы никого не будем учить делать неговно, пусть сами разбираются.

Представьте, если первоклассник принёс учителю решение, что 2 x 2 = 3, а учитель в ответ выражает просто мягкое неодобрение, но не говорит, что правильно будет 4? Математика никогда не откроется ребёнку как точная наука, скорее ощущение будет «ну, я что-то делаю, что-то, наверное, получается».

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

Важно — именно «ты сделал говно», а не «ты — мудак». Критиковать можно только работу, но не личность.

40 минут говорили о будущем Django, про асинхронщину в питоне и о том, стоит ли учить ей джунов:

Многие программисты почему-то рассчитывают на QA как на «тестировщиков» — чуваков, которым можно отдать задачу, а они проверят, сделал ты её или нет. Делать так нельзя.

Во-первых, это адская коммуникационная дыра. Передал задачу → через два часа QA принял → ещё через два прислал баг-лист — вот уже 4 часа и потерялись. Ты уже занят чем-то другим, а тут тебе баги прилетели, и хорошо, если в этот же день. Если в паре из программиста и QA кто-нибудь не умеет внятно выражать мысли письменно — людей нужно сажать в один офис, что вообще проблематично.

Во-вторых, это трата времени людей. Я говорю не об автоматических e2e-тестах на регресс, а о банальных интеграционных тестах. Какой смысл ждать по 4 часа ответа от кожаного мешка, когда можно за час написать робота, который проверит этот кусок работы? Причём робот сделает это не только сейчас, но и потом — в CI, при регрессионном тестировании, всегда.

А QA с радостью заберут работу, связанную с качеством, которую нельзя поручить роботам, — улучшение требований, построение и отслеживание метрик, документирование работы и т. д.