🦾 IT-Качалка Давида Шекунца 💪
2023-09-19 12:09
Gennadii ИТ-К Khotovytskyi
А как при таком флоу, без ревью и тестовых инстансов, уберечься от ошибок в самой бизнесс логике?
Тестовые инстансы есть, ревью по желанию разработчика (каждый несет сам ответственность за свой код)С самой логикой чаще всего у нас все в порядке, вопрос в проблемах деплоя или которые без деплоя не увидишьВ целом, придерживаемся некоторых best practice:– Обратная несовместимость? Пили новые ручки, а не меняй старые– Не знаешь допустил ли ошибку в SQL / коде? Используй интеграционные тесты (у нас развернута очень быстрая и удобная система интеграционных тестов, поэтому для создания нового ты просто копируешь файлик, меняешь названия вызываемых функций, немного входных аргументов и все работает)– Боишься что изменение сущностей разломает консистентность? Используй Event log, то есть строй так, чтобы делать INSERT каждой новой версии, а не UPDATE, тогда можно откатиться до нужной версии или поправить на лету, увидев где пошло не так (еще лучше EventSourcing, но это сложнее)– Многоступенчатый процесс на каждом этапе которого все может пойти по пизде? Делаешь на такие процессы джобу, все изменения состояния и результаты которой храниш в БД. У нас есть джобы по 10 этапов, на каждом создается по сотне сущностей, все связи этих сущностей храняться на джобе, поэтому если произошла ошибка на каком-то этапе, всегда можно запустить скрипт, который удалит все эти сущности и перезапустит джобуИ еще много таких правилОсновная философия: не избегать баги, а делать так, чтобы их появление (а они появятся) не рушило всю систему, их можно было легко обнаружить и поправить