«Це було не DI, це був DIablo». Unity Developer поскаржився на катастрофічно низький рівень навичок свого тім ліда

Привіт, спільното! Натрапив на примітну історію — український Unity Developer Олександр Чижевський у своєму дописі на LinkedIn розповів, як його запросили «підсилити команду» і яким на проєкті виявився тім лід.

«Натрапив нещодавно на дуже... цікавий проєкт. Мене туди запросили типу як «посилення команди». Кажуть: «Ось тобі наш Лід, він же Сеньйор з величезним досвідом. Будеш з ним працювати». Ну, думаю, кайф — зараз буду черпати мудрість, як з відкритої книги. Але замість книги — відкрив банку з павуками.

MonoBehaviour lifecycle? — «А це що?»

MVC / MVP / MVVM? — «Чув, але не юзаю — заморочено»

UI-патерни? — «А це точно про Unity?»

Ну ок, думаю, не всім же бути архітекторами. Але коли я побачив архітектуру, яку він побудував через Zenject... Це було не DI, це був DIablo. Zenject використовувався як священний синглтон у кожній дірі, залежності летіли як кулі в COD, назви класів не відповідали їхній поведінці, логіка зв’язків — як після трьох ночей без сну. А головне — він цим ПИШАЄТЬСЯ, адже він senior із заробітною платою від 5к.

Я питаю: «А чого так?». Він: «А що? Працює ж! В мене великий досвід, тож я шарю як треба». І в той момент в мені щось тріснуло. Це не прототип, не геймджем, не MVP. Це продукт, який уже 4 роки на ринку, має реальних гравців і приносить дохід. А я сиджу і думаю: «А як так можна було?» — зазначив Олександр.

Ситуація не нова, але такі випадки завжди дуже цікаво розбирати. То хотів спитати у вас:

Чи зустрічалися ви з ситуацією, коли керівник чи просто вищий за рангом колега має помітно гіршу експертизу? Наскільки це була критична різниця? Як реагували на таке? Діліться досвідом в коментарях!

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев

Теми: Unity, геймдев

Ctrl + Enter

Mari Levi 13.07.2025 21:28

Так, це було в зникнувшій конторі dio-soft. Там був лід-дебіл, котрий говормв часто про патерни та код-конвеншен, але дупля не відстрілював, як це все виглядає на практиці (короче, нахватався на якійсь співбесіді, а коду ні стрічки не міг написати). Але вони ще й з кацапами працювали, тому і не дивно, що там за ліди, код та в цілому — культура були. Кращі кодери покинули це дно, а сама контора — навернулась

Відповісти

Підтримати

Dmitry 13.07.2025 20:01

Це продукт, який уже 4 роки на ринку, має реальних гравців і приносить дохід. А я сиджу і думаю: «А як так можна було?» — зазначив Олександр.

Вместо того, чтобы аккуратно и спокойно определить основные сложности проекта и предложить плавный план перехода, который сделает лучше этот Шурик не нашел ничего лучше как публично начать метать ... в общем — показал себя во «всей красе». Не знаю как кто, я бы 100 раз подумал стоит ли брать такого ... в свою команду.

Mukola Derevlo 13.07.2025 18:31

дуже далекоглядно, палить своє ім’я і критикувати проект. хоча може це такий маркетинговий хід, «дивіться який я розумний а лід дурбелик». хайріть мене)
а по сабжу. проект приносить гроші, якби робили все по книжці, довелось бу туєву кучу часу витратити на запуск. а так х¥як і в продакшен

Oleksandr Ivanov 13.07.2025 14:29

Це вкотре доводить що важливо вивести продукт на ринок щоб заробляв гроші а вже потім по можливості займатися організацією коду

Sashko Peremot Senior Editor in GameDev DOU 13.07.2025 16:44

важливо вивести продукт на ринок щоб заробляв гроші

Тільки не дуже багато людей розуміють, як це зробити, на жаль :(

Oleksandr Ivanov

flyman 12.07.2025 22:00

Це продукт, який уже 4 роки на ринку, має реальних гравців і приносить дохід.

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

Дмитрий Мирошник Lead QA Automation Engineer 12.07.2025 11:55

Было такое. Собес был аццкий, 5 стадий. 2 с нашей стороны, 3 — с клиентской. Взяли как лида, который должен был с укр стороны развернуть QA команду, только вот остальных кандидатов (довольно неплохие были в том числе) — зарубили на их части собесов. Хотели, чтоб в архитектуре разбирались все словно боженьки.
Окей, думаю, что ж там эти монстры наваяли-то? А там... мрак )))
Код на Python, притом использовать типизацию — зась! Нигде нет ))
Классы — такое чувство, что ООП QA команда освоить не смогла. Там тупо свалка статических методов, не объединённых ничем вообще.
А сами методы — это вообще трешак. Переиспользования — нет и в помине, если надо метод, отличающийся на 2 строчки — пишется новый метод. Использование коментов — это для слабых духом. В результате чего в классе лежит по 5..10 почти одинаковых методов и невозможно сказать без дебага, какие же типы данных они принимают и чем вообще отличаются. Более того, когда я пытался писать нормально, переиспользуя общий код с вынесением общей части, то меня рубили на код ревью мол ты ж чужой метод поменял, а вдруг тесты завалятся)))
Аргумент «да я их прогнал, всё норм, вот пруфы» — не действовали.

Kostiantyn Kudriavtsev Head of .NET team в Luxoft 12.07.2025 12:21

...а вдруг тесты завалятся
...«да я их прогнал, всё норм, вот пруфы»

Тобто у вас були тести на тести?

Дмитрий Мирошник

Дмитрий Мирошник Lead QA Automation Engineer 12.07.2025 12:23

Не, обычные автотесты.

Kostiantyn Kudriavtsev

Kostiantyn Kudriavtsev Head of .NET team в Luxoft 12.07.2025 12:43

Ось до чого я веду. Гарна типізація, відсутність дублюванняф коду і так далі — це гарно для продакшен коду. А для коду автотестів це може бути навіть погано.
Тести повинні бути атомарними і незалежними одне від одного. Думаю, з цим ніхто не наважиться спорити. А як ви гарантуєте незалежність, якщо тести у вас зав’язані на спільний базовий код? не буду давати руку на відсіч, проте думаю, що чуваки боялись що ви зробите тести невалідними і це буде важко помітити без ретельної перевірки.
Це той самий випадок, коли антипатерни в продакшен коді стають патернами в автотестах.
Одночасно створювати бібліотеку максимально простих інструментів для банальних дій на майбутнє це норм. Просто не треба поспішати з заміною старого дубльованого коду на свій «новий ідеальний». Рано чи пізно по мірі роботи ви б дійшли і до того старого коду і планово б його замінили.

Дмитрий Мирошник Lead QA Automation Engineer 12.07.2025 13:01

Тести повинні бути атомарними і незалежними одне від одного

Естессно. Но атомарность тестов достигается не так.
Приведу простой пример (не с того проекта, просто абстрактный, но будет понятно).
Пусть есть некая страничка, где надо ввести значения в 2 поля и кликнуть на кнопку.
def input_values(value1, value2):
input(value_1)
input(value2)
click_button()

А теперь у нас есть страничка, где надо сделать то же самое, только ещё выбрать чекбокс. Как это решали чуваки:
def input_values_2(value1, value2):
input(value_1)
input(value2)
click_checkbox()
click_button()

А как решу я:
def input_values(value1, value2, checkbox_present:boolean):
input(value_1)
input(value2)
if(checkbox_present):
click_checkbox()
click_button()

def input_values(value1, value2):
input_values(value1, value2, false)

Kostiantyn Kudriavtsev Head of .NET team в Luxoft 12.07.2025 13:36

Тут я бачу, що ваш тест не покриває другий їхній тест повністю. Їх тест впаде, якщо чекбокса немає, а ваш пройде.
Я б таке теж завернув.
Поспішив трішечку, був неправий. Але все ще залишається питання розширення. Що як в перший тест захочуть додати ще 5 полів? Додвавати кучу іфів? не заскладно?

Дмитрий Мирошник Lead QA Automation Engineer 12.07.2025 14:42

То я сделаю что-нить ещё. Например, list полей или ещё как-нить выкручусь. Если там прям много расширений будет — применю Strategy паттерн или его аналог. Но уж точно не буду клонировать ещё 5 методов.
И ещё 1 момент: это ж не тест. Это — метод, который в тесте потом где-нить используется.
Т.е., тест потом выглядит как-то так:
def test_smth:
Blablabla...
input_values(smth, snth_another)
blablabla...

А теперь представьте себе, что на вот таких методах строится всё. И каждого есть по 3 и больше модификаций, написанных разными людьми в разное время. После чего при попытке использовать существующие методы основной челлендж — догадаться, какой из них тебе вообще подойдёт, патамуша разницу между ними без дебага понять практически невозможно, особенно когда внутри input_values тоже могут быть вызваны какие-нить input_2 или input_5. И это только верхушка того трешака )))

Вова Москаленко 13.07.2025 12:25

Виходить page object теж не можна використовувати, а то раптом два різних теста натиснуть одну кнопку.
І взагалі, атомарні тести можуть лежати тільки на низьких рівнях піраміди, на е2е рівні (не плутати з ui), яким традиційно займаються aqa атомарність — це суцільні недоліки. По-перше, це суперечить самій ідеї е2е тестування, де мала б перевірятися взаємодія різних компонентів, які атомарно якраз працюють нормально, а разом можуть бажити. А по-друге, це ще й дорого. Бо вам на кожен тест доведеться розгортати базу певного стану зі снапшоту. Це повільно (з точки зору самого прогону) і готувати набори тестових даних в цьому випадку це той ще гемор. Замість цього можна написати не атомарний тест, який робить save, а потім read і зекономити купу часу і точно бути впевненим, що наприклад read after write працює (погуліть проблему read after write на реплікованих бд). Так, якщо такий тест впаде, то сходу не скажеш, це зламався read чи write, але встановити це — 1хв, а зекономити на підготовці снепшотів можна години

Михаил Катасонов 12.07.2025 11:16

Лід на те й лід, щоб вирішувати що дійсно потрібно проекту, структура коду це не одна універсальна структура, а комбінація патернів адаптована до розміру проекту, типу гри, потреб у масштабуванні і тестуванні. Тому казати що скрізь треба MVC і DI це помилка.

Kostiantyn Kudriavtsev Head of .NET team в Luxoft 12.07.2025 09:23

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

Igor Artyomov Senior Java developer 11.07.2025 21:47

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

Kostiantyn Kudriavtsev Head of .NET team в Luxoft 12.07.2025 09:34

Звідкись же людина отримала довіру від бізнесу. Скоріше за все тому що змогла зробити щось, що приносить гроші.
Тут цікаво інше, керівництво бачить, що якість на проекті просіла, тому й позвали когось зі сторони. Хто ж знав, що то буде токсичний правдоруб максімаліст.
С приводу ринкової ціни... ну таке... якщо робота драйвить, основні потреблеми закриті, то починаєш ставитися до грошей спокійно. Особливо зараз коли ринок просів.
Проблема з актуальністю знання є, але це вже кожен сам має вирішувати, як підсилювати свої знання та компетенцію. Це не така вже й проблема насправді, глянути на ринок і довчити по ключових.словах.

Igor Artyomov

Type Shift 10.07.2025 16:15

А був би цей підсилятор головним на проекті, то тижнями висіли б ПРи через невідповідність якійсь специфікації, і проект на 4й рік досі не дістався б до користувачів.

Vitalii D Frontend Engineer в Tide.co 10.07.2025 16:10

Це продукт, який уже 4 роки на ринку, має реальних гравців і приносить дохід

код який приносить бабки не може бути поганим...

Eugene Fides 11.07.2025 11:30

Можна і так сказати, бо кожен раз, коли я дивлюсь на кастомерський код і на гроші, які цей солюшен приносить то питання відпадають :)

Vitalii D

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 10.07.2025 15:52

Забавно, когда новые люди приходят в команду и хотят переписать всё с нуля.

Eugene Fides 10.07.2025 14:01

Ну, якщо він каже правду і "

Zenject використовувався як священний синглтон

тут цікаво, що мається на увазі «священий синглотон», бо це якби і є по всім канонам глобальний контейнер залежностей. Якщо там на кожному кроці робили контейнер інджект, ну тоді то інша справа...
По сабжу, срач на рівному місті :)

Vitalii Hladiienko Senior Producer в ROOM 8 GROUP 10.07.2025 13:10

Нормально. Кому подобаються подібні сюжети, можете ще оце глянути.

Alex Speleers unity developer в N-iX 10.07.2025 12:56

Глянув цього Чижевського на гіті — задаюсь питанням, чого в нього є робота, а в мене більше року ні.

Oleksandr Olegovich Unity Developer 10.07.2025 12:43

Прошу шановну спільноту насолодитися зразками правильної архітектури :
github.com/...e/blob/main/TrecCamera.cs

Andrii Kuriachyi Unity Developer 10.07.2025 12:54

Не хочу нікого тут виправдовувати чи засуджувати, але ця репа трирічної давнини, там же можна посвіжіше взяти як зразок...

Oleksandr Olegovich

Oleksandr Olegovich Unity Developer 10.07.2025 13:08

Я думаю, якщо в нього гіт в публічному доступі (на профілі лінки) то, є чим пишатись.
Може є щось дійсно цікаве, з задоволенням подивився б

Andrii Kuriachyi

Yevhen Denisov UX/UI designer at Room8Studio в ROOM 8 STUDIO 10.07.2025 12:34

Welcome to the reality

«Це було не DI, це був DIablo». Unity Developer поскаржився на катастрофічно низький рівень навичок свого тім ліда

29 коментарів

Підписатись на коментарі