Красивый код 🚀 vs 🩼 скорость разработки
В инди-команде иногда можно «грязно» решить задачу, лишь бы она работала.

Известный пример – разработчики Celeste выложили в GitHub 5400 строк жёсткого говно-кода без документации. Да, с точки зрения «чистого кода» это ужасно, но главное, что они сделали игру. Авторы сами отмечают: они тратили время на главное — игровой процесс, а не на архитектуру.

Как сказал Рами Исмаил: «Самый бесполезный код — это тот, который вы никогда не написали, потому что слишком боялись начать». В малой команде важно сначала сделать рабочую игру, а не идеальный фреймворк для игры.

💡 Принцип YAGNI («You Ain’t Gonna Need It») здесь в деле: откладывайте абстракции до возникновения реальной потребности в них.

Стоит всегда помнить, что идеальная архитектура бывает очень дорогой. В инди‑проектах обычно не хватает ресурсов на «архитектуру мечты». Даже создание простого MVP может стоить существенно.

❕Поэтому:

→ Фокус на цели, а не на идеале.

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

→ Делайте YAGNI.

Откладывайте сложные абстракции «на потом». Нужно простая дверь в игре? Не стройте архитектуру для 10 видов дверей, систему сохранения состояний и репликации для возможного мультиплеера.

→ Автоматизируйте разумно.

Постепенно внедряйте CI, автотесты и деплой. Начните хотя бы с простого сборочного скрипта и запуска smoke-тестов. Автоматические тесты особенно полезны при большом количестве контента и мультиплатформенной поддержке. Но не автоматизируйте всё подряд – для одноразовых «ручных» операций скрипты чаще усложняют жизнь. При малой команде иногда быстрее «прокликать» контент вручную, чем тратить полдня на написание автотестов.

→ Бюджетируйте архитектуру.

Оценивайте стоимость сложных решений. Если желаемая архитектура требует времени, компенсирует ли она это экономией в будущем? В инди больше ценится MVP с возможностью раскачки.

→ Управляйте техдолгом.

Заносите техдолг в ваш трекер задач, отслеживайте, как он влияет на скорость разработки фичей. Иногда лучше жертвовать качеством (в виде долга) ради быстрой фичи, но тогда сразу отдавайте себе отчёт в этом. Малый долг – нормальное явление, главное – не допускать «эффекта снежного кома».

#gamedev #сode