Изменять работающую систему — не то же самое, что писать код в пустом файле

Когда создаёшь новую систему, всё кажется проще.

Файл пустой. Правила определяешь ты. Никто ещё не привык к этой системе.

Но в реальных проектах всё обычно происходит иначе.

Большинство изменений вносятся в систему, которая уже работает. Кто-то использует её каждый день. Другой сервис зависит от неё. В базе уже есть данные, которые нельзя просто взять и изменить.

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

«Небольшое изменение» не всегда небольшое

В ticket может быть написано:

• «Нужно просто добавить одно поле».
• «Давайте просто изменим статус».
• «Давайте немного смягчим это правило».

На экране всё это действительно может выглядеть как небольшое изменение.

Но перед тем как менять код, появляются другие вопросы:

• Если этого поля раньше не было, что будет со старыми данными?
• На какие процессы повлияет изменение статуса?
• Если сделать правило менее строгим, какие операции, которые раньше не проходили, теперь начнут проходить?
• Затронет ли это изменение другие сервисы, отчёты или процессы оплаты?
• Останутся ли старые данные и процессы корректными после изменения?

Написать код, не задумываясь об этом, легко.

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

Сначала я думаю о том, что нельзя сломать

Перед тем как начинать новую feature, я стараюсь понять существующий процесс.

• Как он работает сейчас?
• Кто им пользуется?
• Какой код и какие процессы от него зависят?
• Что можно изменить, а что лучше оставить как есть?
• И самое главное — будут ли старые данные и процессы продолжать работать корректно после изменения?

Особенно хорошо это понимаешь при работе с банковскими системами.

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

Но это касается не только банковских систем.

Если человек каждый день использует одну и ту же систему, любое твоё изменение влияет и на его ежедневную работу.

Иногда ты делаешь её проще, даже не задумываясь об этом.

А иногда небольшое на первый взгляд изменение создаёт проблему совсем в другом месте.

Что для меня значит хорошее изменение?

Для меня хорошее изменение — это не просто изменение, которое выполняет новое требование.

Оно должно решать новую задачу и одновременно сохранять то, что уже работает.

Например:

• Новое поведение должно быть понятным.
• Старое поведение не должно случайно ломаться.
• При ошибке система не должна молча создавать некорректные данные.
• Причина изменения должна быть понятна разработчику, который будет читать этот код в будущем.

Писать код, конечно, важно.

Но добавлять код в работающую систему — совсем не то же самое, что писать новый код в пустом файле.

Здесь уже есть пользователи, данные, другие сервисы и существующие бизнес-правила.

Поэтому для меня процесс выглядит так:

• Сначала понять существующий процесс.
• Потом определить, на что может повлиять изменение.
• И только после этого писать код.

Мне кажется, это одна из важных частей software engineering: добавляя что-то новое, не сломать случайно то, что уже работает.