Пятничное чтиво

Канал выходит из отпуска. Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

Evolutionary Database Design

Если говорить об изменении технической системы — рефакторинг базы данных попадает в личный топ 1 самых проблемных активностей. По этой причине приходится уделять много времени моделированию данных. Поэтому сегодня лонгрид от thoughtworks, в которой рассказывается как справляться с эволюцией базы данных.

Текст начинается с примера, где необходимо из одной строки бд получить три. Далее авторы пишут вводную часть связанную с тем, что нужны эволюционные изменения нужно вносить контролируемо и вносить изменения итеративно. Плюс, авторы говорят об ограничениях у описанных подходов, связанные с multi-tenant приложениями (где баз для изменения сотни).

Дальше описываются 11 принципов. В тексте найдете как очевидные принципы (изменения только через миграции и CI, изменения лежат в гите, частый деплой, у каждого разраба собственный инстанс бд). Так и не очевидные: описание шагов разных видов рефакторинга бд (разделение таблиц, перенос данных и так далее), использование SQL DDL и DML.

#system_evolution #db

—————————————

Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo

Когда работал в toptal, встретился с ситуацией, что прогон всех юнит/интеграционных тестов занимал часы (с парализацией в 60+ потоков). Для ежедневной работы ждать часами билд идея так себе, поэтому, с помощью сетей петри, сделали библиотеку для запуска тестов только вокруг связанного кода. С похожей проблемой столкнулся stripe (1.2 миллиона тестов), о чем пишет в статье.

Текст начинается с понятия Selective Test Execution (STE) — выборочный запуск тестов, связанных с фичей. Для этого в компании сделали «статический анализатор зависимостей», т.е. граф того, какой кусок кода с каким тестом связан. Для этого прогоняются тесты и записываются файлы с кодом, которые были вызваны. (при каждом изменении кода граф перестраивается). Реализация связана с метамагией руби и в тексте найдете описание обработки пограничных случаев и разграничение scope тестов. Дальше описывается, как CI/CD решает какие тесты запустить, основываясь на полученном графе. Отдельно советую почитать о том, как версионирование граф зависимостей тестов под билды.

#testing

—————————————

How to Write an Effective Software Design Document

Еще один лонгрид, на этот раз о том, как писать техническую документацию. Начинается текст с примера документации, которую написал автор по собственным советам. Далее автор отвечает на вопросы: когда писать документацию, сколько времени потратить, что должно быть в документе.

После начинаются советы по компонентам из которых состоит дока: заголовок, метаданные (автор, кто утвердил, когда сделана, статус и так далее), цель текста, background, цели проекта, диаграммы и так далее. Из интересного: автор советует добавлять глоссарий, правовую информацию, таймлайн проекта и осисание свойств (security, SLO).

Если искали «темплейт» для Solution Architecture Document или хотите улучшить техническую документацию в компании — стоит ознакомиться.

#documentation