Живий досвід роботи з великим ентерпрайзом і що з цього винести
Зазвичай я розробляв застосунки, які міг запускати і тестувати на своєму комп'ютері. Але зараз я працюю з проєктом, з яким це можливо, але невиправдано.
Раніше я працював переважно з проєктами, які легко вміщалися у мене на ноутбуці. Запустив код, підняв базу в Docker, перевірив усе локально — і вже можна деплоїти. У гіршому випадку на запуск йшло хвилин десять, але зате я був повністю автономний.
А потім я зіткнувся з справжнім ентерпрайзом.
Проєкт написаний на Java, складається з півтора десятка модулів і важить десятки гігабайт. І це не враховуючи бази даних, яка потрібна для тестування та налагодження. Запустити все це на моєму "дорожньому" MacBook Air навряд чи можливо. Навіть потужний стаціонарний ПК не завжди впорається.
Тому вся робота йде через тестові стенди. І тут починаються нюанси:
-
якщо хтось запускає збірку, стенд блокується для інших мінімум на пів години;
-
перед деплоєм потрібно попередити колег і переконатися, що ніхто інший не збирає проєкт;
-
будь-яка дрібна помилка перетворюється на годину втраченого часу.
Спочатку це було незвично. Здавалося, що розробка перетворюється на постійне очікування. Але з часом я виробив кілька правил, які роблять процес більш керованим.
1. Міні-оточення локально
</b>Повністю проєкт не підняти, але можна зібрати собі мікро-стенд: тільки потрібні модулі плюс заглушки для зовнішніх сервісів. Це дозволяє перевірити базову логіку "на колінці".
2. Тести — не опція, а необхідність
</b>Раніше я ставився до юніт-тестів як до "корисного доповнення". Тепер розумію, що кожен тест — це мінус пів години простою. Іноді простіше написати маленький інтеграційний тест для перевірки гіпотези, ніж витрачати час на збірку.
3. Маленькі зміни
</b>Якщо можна розбити задачу на кілька маленьких pull request’ів — потрібно розбити. Чим менший шматок коду, тим нижчий ризик і швидша перевірка.
4. Code review як фільтр
</b>Перехресний рев'ю з колегами є обов'язковим етапом. Часто друга пара очей помічає те, що сам може упустити. Помилки відловлюються ще до збірки — і це економить години.
5. Планування деплою
</b>Запуск на стенді — це ресурс, і ним потрібно керувати. У нас негласно діє правило: домовся про "своє вікно" заздалегідь, щоб не заважати іншим.
Ентерпрайз навчив мене ставитися до розробки інакше. Тут немає місця філософії "спочатку зроблю, потім виправлю". Кожна зміна вимагає підготовки та перевірки. Але натомість ти отримуєш більш чистий і надійний код, а сам починаєш поважати час колег і цінувати дисципліну.
По суті, такі умови формують зовсім інший стиль мислення: ти вчишся писати так, щоб помилки було максимально складно допустити ще до першого деплою.