Кав'ярня біля Лісового

Наталю я знайшов через знайому знайомої — типовий для України ланцюжок. «Якщо ти хочеш поговорити з людиною, яка тримає продуктивність на in-house 1С-команді у великому ритейлі, — це Наталя. Я тобі скину контакт. Тільки май на увазі: вона не з тих, хто розкаже за п'ятнадцять хвилин. Вона думає повільно і структурно».

Наталя відповіла за два дні. «П'ятниця, шоста вечора, кав'ярня "Перебендя" на Лісовому. У п'ятницю я зазвичай нікуди не поспішаю — субота вихідна. Можемо посидіти годину-півтори».

У п'ятницю о шостій вечора я знайшов «Перебендю» — маленьку кав'ярню за два повороти від метро Лісова, у житловому масиві з типовою київською забудовою кінця сімдесятих. Усередині — приглушене світло, дерев'яні столи, на стінах — фотографії старого Києва, з програвача — Бетховен.

Наталя сиділа у глибині, біля вікна. Біля неї — закритий ноутбук, склянка чаю з лимоном, шкіряний блокнот старого формату, A5, обтріпаний по краях. Тридцять вісім років, темне волосся коротко підстрижене, окуляри з тонкою металевою оправою, темно-сіра в'язана водолазка. Виглядала не як технічна людина — як шкільна вчителька історії, з тих, які люблять свій предмет понад усе.

— Денис? Сідай. У мене блокнот зі мною — там у мене конспект з нашої внутрішньої методички. Я тобі покажу. У вас на запис?

— Так, якщо не проти.

— Не проти. Тільки прізвище не пиши.

Наталя — тех-лід команди семи розробників у великому продуктовому ритейлі. Не той самий, у якого Юрій лагодив сорок сім хвилин — інший. У них тридцять п'ять регіональних магазинів, центральний офіс на Подолі, кілька логістичних хабів. Усе на BAS КУП плюс декілька внутрішніх розширень.

— Я тут із сімнадцятого, — каже вона. — Прийшла з франчайзі. До того у мене було вісім років франчайзі-практики. Я знала всіх цих клієнтів, у яких щось не працює, які кличуть нас раз на квартал. Прийшла сюди — і зрозуміла, що тут не клієнт, а ми самі. Ніхто з вулиці не прийде лагодити пожежу. Тільки команда. Я подумала: треба зробити так, щоб пожеж не було.

— Виходить?
— Виходить. Перші два роки я переписувала їхню культуру. Зараз у мене performance playbook на двадцять сторінок, обов'язковий до читання кожному новому розробнику. Я тобі прочитаю кістяк. Десять правил, які я вибрала з нашої практики. Якщо їх застосовуєш — пожеж зазвичай нема.

— Десять?
— Десять. Більше не запам'ятовується.

Я відкрив блокнот.

— Перше правило — performance budget на нову роботу.

Наталя відкрила свій блокнот, провела пальцем по списку.

— Коли мій розробник проектує новий документ — наприклад, «Замовлення постачальникам» — він перед написанням коду оцінює: скільки рядків у середньому буде у табличній частині? Скільки разів на день створюватимуть документ? Скільки часу він має проводитись?

— Це формалізовано?
— Так. У нас є шаблон проекту, у ньому є секція «Performance Budget». Для документа — максимум часу проведення, максимум часу відкриття форми, максимум часу побудови списку. Якщо проектує і бачить, що не вкладається у бюджет — або переробляє архітектуру, або іде до мене з обґрунтуванням, чому бюджет треба підняти.

— Як виглядає бюджет?
— Документ оперативного обліку: проведення — максимум півсекунди для типового, дві секунди для великого (200+ рядків). Звіт: побудова — максимум три секунди для типових даних, десять секунд для великих. Форма списку: відкриття — максимум секунда.

— Це здається жорстким.
— Це здається жорстким, поки ти не побачиш, що буває, коли ці бюджети не контролюються. Юрій, якого ти зустрічав, — він наслідок відсутності цих бюджетів. Хтось колись написав документ, який проводиться за десять секунд. На етапі впровадження це здавалося нормальним. Через п'ять років база виросла — це стало сорок сім хвилин. Бюджет — це профілактика від Юриного бізнесу.

— Друге — індекси на старті, не в кінці.

Наталя гортала свій блокнот.

— Коли у новому об'єкті додається реквізит, за яким будуть фільтрувати — одразу позначити його як індексований у метаданих. Не чекати, поки база виросте і запит почне гальмувати. У 90% випадків розробник знає на етапі проектування, які поля будуть у ГДЕ і УПОРЯДОЧИТЬ ПО. Він просто лінується позначити їх. Або не думає.

— Що, ставити індекс на все підряд?
— Ні. Усе, що буде ключем фільтрації. У нас правило: якщо реквізит з'являється у запитах у двох і більше місцях — індекс. Якщо лише в одному — обговорюємо. Якщо ніде — без індексу.

— Третє — регістри замість документів для агрегатів.

— Коли треба часто отримувати залишки, обороти, рейтинги — завжди регістр накопичення. Не запит по документах. Не своя таблиця підсумків. Регістр — це і є та структура, яку платформа оптимізувала під цей сценарій. Віртуальні таблиці Остатки і Обороты працюють миттєво, бо платформа підтримує підсумки за тебе.

Я пригадав Богдана у попередньому розділі — він те ж саме казав. Наталя кивнула, коли я це згадав.

— Так. У нас з Богданом одна школа. Я його статті читала ще у дев'ятнадцятому, вони мене переключили на правильне мислення. Він — теоретик, я — практик. Ми по-різному це формулюємо, але кажемо одне і те саме.

— Четверте — запити повертають мінімум.

Наталя налила собі ще води з графина.

— Молодший розробник часто пише: ВЫБРАТЬ * ИЗ Документ.РеализацияТоваров. Або: ВЫБРАТЬ Документ — без зазначення полів, повертаючи об'єкт як ціле. Це жирні запити. Платформа тягне всі реквізити, читає всі підпорядковані таблиці, навантажує пам'ять.

— Як треба?
— Кожен запит — конкретні поля. ВЫБРАТЬ Документ.Номер, Документ.Дата, Документ.СуммаДокумента ИЗ ... — і все. Не повертати об'єкт цілком, якщо тобі потрібно три поля. Це дисципліна, яка тренується практикою.

— П'яте — точкова навігація обмежена.

— Це болить. Розробники люблять писати Реализация.Контрагент.НомерТелефона у звітах (так, російською — типова інакше не вміє). Це виглядає елегантно, але платформа додає LEFT JOIN на довідник «Контрагенты» за лаштунками. У звіті з тисячами рядків — це тисячі лукапів. Замість одного JOIN.

— У формах теж не можна?
— У формах — можна, бо там зазвичай одна сутність. Платформа кешує. Проблема — у звітах і у запитах з великими вибірками. У нас правило: якщо у запиті більше п'яти рядків — точкова навігація заборонена. Замість того — явний JOIN з вибором тільки потрібних полів.

— Шосте — фоном замість синхронно.

— Усі довгі операції — у фон. Користувач не чекає на формі, поки звіт побудується десять хвилин. Він тисне «Сформувати», отримує повідомлення «Звіт запущено, ви отримаєте сповіщення». Звіт виконується у фоновому завданні на сервері, результат зберігається. Користувач отримує email або сповіщення в системі.

— Це більше коду?
— Так. Це обгортка над звітом, плюс роутинг результату, плюс інтерфейс відстеження прогресу. Перший раз — два дні. Далі — копіюєш патерн. У нас усі звіти довше п'яти секунд — за замовчуванням у фон.

— Сьоме — batch для масових операцій.

— Імпорт даних, перерахунки, масові оновлення — пакетами, з commit-ом через кожні N записів. У нас стандарт — тисяча записів на пакет. Записати тисячу — commit. Записати тисячу — commit. Чому не один великий запис? Бо одна транзакція на сто тисяч записів блокує таблицю і ламає продакшен.

— А не можна було просто менше блокувати?
— Можна було, у теорії. На практиці — це архітектурний компроміс. Менше блокувати — означає писати окрему логіку керованих блокувань, відстежувати, що зачеплено, що ні. Чи простіше — комітити пакетами. Перше — складно. Друге — повторюваний патерн.

— Восьме — обов'язкове code review.

Наталя зробила паузу.

— Це культурне правило, не технічне. Але без нього всі попередні сім — нездійсненні. У нас жоден коміт не вливається у головну гілку без перевірки іншою людиною. Жоден. Це здається бюрократією, але це повертається подвійно: коли ти знаєш, що твій код прочитає колега — ти пишеш краще. Коли ти читаєш чужий — ти бачиш, де можна оптимізувати.

— Як ви це робите технічно? У 1С же не Git.
— У нас з 2020-го — git. Через EDT і конвертації туди-сюди. Я тобі це окремо розкажу, у наступному розділі. Зараз — суть: код потрапляє у git pull request, людина дивиться, коментує, схвалює. Тільки тоді merge у головну гілку.

— Дев'яте — performance monitoring у продакшені.

— Технологічний журнал — постійно ввімкнений, з фільтром на запити довше трьох секунд. Грубий, але працює. Окремий скрипт раз на годину аналізує лог, агрегує по контексту, надсилає мені у Slack топ-10 повільних місць за останню годину. Якщо там з'являється щось нове — я знаю того ж дня. Не через місяць, як це буває без моніторингу.

— Тобі самій надсилає?
— Так, я це тримаю на собі. Колись делегую, поки що — це мій канал-замикач. Я знаю продакшен як свої п'ять пальців. Якщо щось вибивається — я перша це бачу.

— Десяте — культура pre-mortem.

Наталя злегка усміхнулася.

— Перед великим релізом ми робимо зворотне планування. Сідаємо командою, я кажу: «уявімо, що цей реліз пішов у продакшен у понеділок. А у вівторок все упало. Що пішло не так?». І ми по черзі озвучуємо: «база заблокувалася на проведенні», «звіт впав з нестачею пам'яті», «інтеграція з банком зламалася». Потім по кожному пункту — вживаємо превентивних заходів.

— Це передбачає катастрофу?
— Це проектує сценарії катастрофи. Багато з них виявляються реалістичними. Ми їм запобігаємо. Решту — занотовуємо як ризики і моніторимо насамперед у продакшені.

— Скільки часу це займає?
— На великий реліз — три години команди семи людей. Двадцять одна година. Так, дорого. Але жодне велике падіння за три з половиною роки відтоді, як я це ввела. До цього у мене падало приблизно раз на квартал. Підрахуй, скільки коштує одне падіння продакшену на чотири години у мережі з тридцяти п'яти магазинів.

— Підсумуй мені цю філософію, — попросив я. — Як ти її саму описуєш.

Наталя замислилась.

— Продуктивність — це не оптимізація. Це проектування. Юрій оптимізує — це лікування. Я проектую — це профілактика. Юрію я завжди говорю: «ти потрібен, але мене у твоєму світі не існує. Я роблю так, щоб тебе у моєму світі не було». Він не ображається.

— У чому різниця в підходах?
— Він приходить, коли вже пізно. Я ставлю стандарти, поки ще рано. Мої правила — на півгодини довше пишеш кожен документ. Він — за три дні переписує те, що я б писала тиждень. Разом — це швидко і надійно. Поодинці — або повільно і надійно, або швидко і ламко.

— Це працює у твоїй компанії, бо in-house. А у франчайзі?
— У франчайзі — складніше. Клієнт не платить за «правильне проектування». Клієнт платить за «зробити документ». Якщо ти три години думаєш над архітектурою, а потім за дві години пишеш — клієнт бачить п'ять годин. Якщо ти за п'ять годин просто пишеш, без думки — він бачить ті самі п'ять годин. Різниця проявиться через рік, коли база виросте і всі його повільні документи стануть Юриним хлібом. Це ринкова проблема, не технічна. Франчайзі-економіка винагороджує швидкість зараз, не надійність потім.

— А у вас — навпаки?
— У нас — повільність потім коштує мені прямо. Якщо у понеділок усі тридцять п'ять магазинів стали — це наш збиток, наш репутаційний удар, мій бонус скорочується. Тому я тут можу інвестувати у проектування. У франчайзі ця математика не сходиться. Це структурна різниця.

Я записав у свій блокнот десять правил Наталі. Над ними — її фразу: «проектування, не оптимізація».

Наталя розрахувалась за чай, ми вийшли на Лісовий. Вона жила тут поряд, у одному з тих самих сімдесятих будинків. До зупинки тролейбуса — півтори хвилини. Я провів її до зупинки.

— Дякую, — сказав я. — Це найбільш структурована розмова за всю книгу.

— Я так розмовляю, — усміхнулась вона. — Якщо в книзі щось не зрозуміло — пиши, я доточую. Я б тобі допомогла з оглядом цілої частини про практику. Якщо хочеш.

Тролейбус підійшов. Вона помахала мені і поїхала.

Я повернувся до метро, думаючи про одну річ.

Наталя — антипод усіх моїх попередніх героїв. Антон всередині чужої моделі світу. Юрій лагодить пожежі. Михайло прийшов до чистої типової через розширення, але реактивно — у відповідь на біль. Наталя ж — планує. Вона єдина у книзі, яка чітко проектує культуру, а не реагує на ситуацію.

Можливо, тому її голос рідкісний. Більшість 1С-розробників живуть у реактивному режимі — лагодити, оновлювати, шукати рішення. Проактивних — мало. Наталиних — ще менше. Це питання не лише особистості, це питання інституції, у якій ти працюєш. У франчайзі такої культури не може бути за визначенням, бо економіка не дозволяє. Тільки у in-house — і то лише у великих, в яких є простір на стратегію.

Це означає одну неприємну річ: більша частина 1С-розробок в Україні структурно приречена на «по-юриному». Не за бажанням розробників. За структурою ринку. Поки не зміниться структура — Наталиних правил буде менше, ніж потрібно.

У наступному розділі — про той самий git, про який вона згадала. Як Git зустрічає 1С — і чому це окрема історія, якій є двадцять років. Розділ тринадцятий.