Живой опыт работы с большим энтерпрайзом и что из этого вынести

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

А потом я столкнулся с настоящим энтерпрайзом.

Проект написан на Java, состоит из полутора десятков модулей и весит десятки гигабайт. И это не считая базы данных, которая нужна для тестирования и отладки. Запустить всё это на моём "дорожном" MacBook Air вряд ли возможно. Даже мощный стационарный ПК не всегда справится.

Поэтому вся работа идёт через тестовые стенды. И тут начинаются нюансы:

- если кто-то запускает сборку, стенд блокируется для остальных минимум на полчаса;

- перед деплоем нужно предупредить коллег и убедиться, что никто другой не собирает проект;

- любая мелкая ошибка превращается в час потерянного времени.

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

1. Мини-окружения локально

Полностью проект не поднять, но можно собрать себе микро-стенд: только нужные модули плюс заглушки для внешних сервисов. Это позволяет проверить базовую логику "на коленке".

2. Тесты — не опция, а необходимость

Раньше я относился к юнит-тестам как к "полезному дополнению". Теперь понимаю, что каждый тест — это минус полчаса простоя. Иногда проще написать маленький интеграционный тест для проверки гипотезы, чем тратить время на сборку.

3. Маленькие изменения

Если можно разбить задачу на несколько маленьких pull request’ов — нужно разбить. Чем меньше кусок кода, тем ниже риск и быстрее проверка.

4. Code review как фильтр

Перекрёстное ревью с коллегами является обязательным этапом. Часто вторая пара глаз замечает то, что сам человек может упустить. Ошибки отлавливаются ещё до сборки — и это экономит часы.

5. Планирование деплоя

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

Энтерпрайз научил меня относиться к разработке иначе. Здесь нет места философии "сначала сделаю, потом поправлю". Каждое изменение требует подготовки и проверки. Но взамен ты получаешь более чистый и надёжный код, а сам начинаешь уважать время коллег и ценить дисциплину.

По сути, такие условия формируют совершенно другой стиль мышления: ты учишься писать так, чтобы ошибки было максимально сложно допустить ещё до первого деплоя.