Главная » Игры » Принцип KISS в разработке

Принцип KISS в разработке

Следующий доклад с Pixonic DevGAMM Talks, который мы расшифровали, немного философский — это выступление Константина Гладышева. Он Lead Game Programmer в 1C Game Studios и рассказывал о принципе управления сложностью разработки в контексте всего продукта, а не отдельных фичей. И на примерах показал, почему главное в разработке — это определить, чего делать не надо. Про другие доклады можно почитать по ссылкам в конце статьи.

Хотел рассказать про севера, но решили сделать философский доклад, что надо делать проще. Я работал над Postal III, Indestructible, War Robots и сейчас делаю Caliber — сессионный онлайн-шутер от 1С и Wargaming.

Потому что даже сеньоры с 20-летним опытом или CTO часто продолжают что-то лепить и придумывать. Почему мы решили поговорить о KISS (Keep it simple, stupid)? На самом деле тут больше про YAGNI (You ain’t gonna need it) и немного философии. А нужно делать проще.

Сразу отмечу, что мы не говорим про совсем идиотские решения, типа «найди х», мы говорим про более-менее простые решения.

Все начинается из благих намерений, а они, как известно, ведут в ад. Почему иногда бывает слишком сложно? Вот комикс по этому поводу.

Причины этого примерно одинаковые, но я по-разному их назвал:

  • Универсальные решения. Есть какая-то фича и мы сразу делаем из нее библиотеку, миллион дополнительных кейсов. А то вдруг наш шутер превратится в ферму? Или «я буду в следующий раз делать еще один точно такой же шутер». Вряд ли, скорее всего он у вас поменяется.
  • Future proof. Практически то же самое — это несуществующие проблемы. «А если у меня будет миллион юзеров сразу, мне нужно выдержать 22 промежуточных сервера?» и т.д. Чтобы начать зарабатывать, вам хватит и одного сервера на всё.
  • Использование неправильных инструментов. Когда вы используете инструменты, которые не подходят и упорствуете в своем заблуждении.
  • И всем известная преждевременная оптимизация.

У нас был пример, когда делали Caliber. Парни, которые тогда нам помогали, решили сразу сделать суперсериализатор на последнем С++.

Баги, которые были в этом шаблонном коде, не понимал со временем даже автор. В итоге он не работал, как хотелось, было неудобно отправлять частичный стейт, потому что шаблоны не очень понимают, где надо, а где нет или делаешь какие-то флаги.

И оно работало чудесно. Тогда один из программистов буквально за два часа переписал всё это добро на одну страницу С кода, который делал только то, что прямо тогда нам было нужно.

У нас был Postal III и он делался на движке Source. Другой пример. В итоге весь BSP не работал. Там такой открытый мир, можно ходить между картами, камера от третьего лица, много одноэтажных домиков в американском стиле с окнами, боты могут бегать и в панике открывать двери. Он занимал много памяти и долго грузился. Он очень долго считался, из-за окон получался миллион секторов и все равно ничего не делал.

Всё полезное от Half-Life нам не подходило совсем. Half-Life, для которого был сделан движок — это шутер от первого лица, а от третьего некоторые вещи делать было неудобно. Надо было менять движок, но тогда варианта не было. Также предполагалось большое количество анимации, потому что от третьего лица нужно перелезать и т.д.

Во-первых, делать фичи в правильном порядке, потому что оптимизирование раньше времени — одна из проблем. Что же делать, когда все плохо, сложно, а нас подгоняют? Некоторые начинают наклеивать стразики до того, как сшили платье, а потом шить не могут, потому что стразики мешают.

Именно в этом порядке, всё остальное — неправильно. Сначала делайте самую простую фишку, чтобы она просто работала, потом стабилизируйте, а потом — оптимизируете.

MVP (minimum viable product). Под визуализацией мы понимаем, что она минимально рабочая, т.е.

Допустим, геймдизайнеры придумывают фичи, программист прибегает и говорит «я буду делать хорошо, плохо не буду, поэтому сразу рисуйте обалденный геймдизайн». Дальше вы оцениваете её потенциал. Он не играл, не знает, хорошо это или плохо. Но откуда он знает? Не нормально — выкинули, не жалко. Поэтому в идеале вы делаете фичу, играете, если нормально — значит делаете её дальше.

Т.е. Еще тысячу лет назад Сунь Цзы говорил, что одержать победу в 100 битвах это не вершина, вершина — выиграть без сражения. не занимайтесь тем, что можно не делать.

Вы сделали фичи и дальше стабилизируете её без лишних дополнений. Стабилизация. Оно и висит. Вам нужно колесо на дереве, на веревке? Больше ничего.

Просто делайте прототип, стабилизируйте, а не пытайтесь наперед угадать. Соответственно, если вдруг обнаружилось (без всяких future proof), что фича должна поменяться — начинайте заново. Всё равно не угадаете.

Это всегда плохо. Ну и преждевременная оптимизация. Оптимизировать нужно в самом конце, когда вы точно знаете, что эта фича важная, ее стоит оптимизировать и она в ближайшее время принципиально не изменится.

Ухудшается читаемость кода, ломаются абстракции и портируемость, как правило, тоже сильно ухудшается. Потому что оптимизация — это набор частных случаев.

Но тут показана ситуация, когда есть куча унылых фичей и прототипов, все плохо, и кажется, что всё разрушится. Это провокационный слайд, потому что на самом деле костыли — это плохо. Посмотрите — это опалубка, в нее заливается бетон, а «костыли» подпирают, пока он сохнет. Но это не так. ситуация абсолютно нормальная, «костыли» потом уберут, но не сразу, без паники. Т.е.

Нет универсально верных решений. Вкратце о философии. Не пытайтесь сделать фреймворк на 100 лет вперед или на все случаи жизни.

Выкидывайте ненужное при первой возможности, не пытайтесь это саппротить. Лучше сделайте много мелких кусочков, которые хорошо делают свое дело. Иногда лучше написать явный код, который сериализуете руками, вместо рефлекшена или еще чего-нибудь. И когда пишите код — делайте его явным. Это очень тяжело читается, половина ошибок в рантайме. Использовать dependency action, когда он вам не нужен, тоже плохая идея. И делайте как можно проще, чтобы избежать ошибок, когда кто-то что-то не понял или вообще забыл. Явное лучше неявного.

Однажды актер, которого он обучал своему Джит Кун-До, спросил у него: «В чем суть твоего боевого искусства Джит Кун-До?». Как говорил Брюс Ли, простота — высшая степень искусства. В этот момент Брюс Ли уронил кошелек, актер подобрал и Брюс Ли сказал: «Вот видишь, ты просто нагнулся и подобрал кошелек, а если бы ты встал в позу всадника, делал каты — ты бы никогда его не поднял».

Вопросы из зала

— Ты говорил, что преждевременную оптимизацию — это зло. А стоит писать преждевременные тесты, когда проект только начинается?

В тестах я не очень силен, потому что в геймдеве (во многих случаях) тесты ближе к концу разработки. — В моем понимании вообще все преждевременное вредно. Я считаю, что плохо тратить силы на тест того, что через два часа изменится. Вначале все так быстро меняется, что пока напишешь тест, геймдизайнер уже все поменяет. Но не на этапе прототипа. Это нужно делать на этапе стабилизации. Если нет, то нет. Но если команда умеет быстро тесты писать, наверное, это хорошо.

Все мы работаем в геймдеве, у нас сроки, продюсеры, потом новая фича и так далее. — Ты упомянул, что костыли будут убраны, но есть замечательный тезис — нет ничего более постоянного, чем временное. И убирали ли их в ноль? Как часто ты видел ситуацию, когда вы вычищали костыли?

Если проект живой, у тебя всегда будут какие-то костыли. — В ноль, наверное, нет. Т.е. Это все работает, если их чистить систематически. вы сделали фичу — тут же зафиксировали.

должен быть построен некий процесс в компании? — Т.е. Типа официальной фазы чистки костылей?

Т.е. — Да, я считаю что это должно входить в таск. Грубо говоря, даже слова рефакторинг нет — это внутри таска. если нужно зарефакторить в процессе таска — рефакторишь.

Приходишь к продюсеру и говоришь на планировании новой итерации, что нам нужно две недели, чтобы почистить, порефакторить и т.д. — А удается это делать на практике? Как быть в такой ситуации? А он говорит, что бизнес велью ноль, сейчас делаем фичу х, а это вы потом как-нибудь вечером после работы почистите.

Продюсер в курсе, что есть какие-то долги, которые ты исправляешь, но своевременно. — У нас удается. Просто выбирайте правильного продюсера. А не так, что у тебя новый релиз, в нем ни одной новой фичи, а тут какой-то рефакторинг.

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

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

— Если уже есть что-то очень сложное, что используется на нескольких проектах, и эта сложность уже не помогает, а скорее мешает — как проще перейти к простым решениям?

В идеале — какая-то отдельная команда, прямо с нуля. — Мое мнение, просто начать делать заново. На новой и чистой библиотеке. Скорее всего вы восстановите 80% функциональности очень быстро. А дальше будете догонять.

— К примеру, есть какой-то мощный сериализатор и редактор игровой логики, вот он достаточно устарел...

Возьмите удобные. — Это те самые неудобные инструменты. Unity, например.

Главный программист решает все мелкие вопросы, все задачи? — Расскажи, какое у вас планирование в коде, насколько оно детальное?

Мы доверяем всем и просто распределяем, кто будет брать прототип, а кто нет. — У нас такая анархия, достаточно плоская структура, не очень много людей. Это может быть любой произвольный человек.

Еще доклады с Pixonic DevGAMM Talks


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Триумф и трагедия «Бурана»

В полностью автоматическом режиме он совершил 2 витка вокруг Земли и успешно приземлился спустя 205 минут. Ровно 30 лет назад с космодрома Байконур на ракете-носителе «Энергия» в свой единственный полёт отправился корабль «Буран». Это стало несомненным триумфом советской космонавтики, впервые ...

[Из песочницы] Несертифицированный GPS-трекер из Китая. Законно ли в России?

Иностранные интернет-магазины завалены разнообразными устройствами, оснащёнными GPS, GSM-модулями, позволяющими отслеживать местоположение наблюдаемого объекта и управлять устройством посредством SMS и мобильных приложений. И, конечно же, большинство из них не сертифицированы и запрещены для ввоза/использования в России. Простой обыватель, услышав слова «несертифицированный» ...