Pull to refresh
11
0
Evgeniy Pavlyuk @wizi4d

User

Send message
Сделал новый тестовый проект, в нем нет пункта Matches, что означает отсутствие функции поиска игры. При этом Challenges, Events и Messages на месте, именно они отвечают за контекст игровой сессии и онлайн обмен между клиентом и сервером (via websockets). Хотя не удивлюсь, если поведение у них отличается.
В старом проекте все на месте и работает. Хотя в FAQ сказано, что функции Matchmaking and Realtime останутся рабочими только в играх выведенных в продуктив (в моем случае это не так).

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

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

Со второй статьи начну описывать реализацию игровых механик.
Я не отрицаю полезность этих знаний. Я всего лишь говорю о том, что их значение очень часто переоценивают.
Не думаю, что в команде нужно, чтобы все были шикарными алгоритмистами. Знание паттернов, умение писать «чистый» код и прокачанные softskills, как правило, более полезны в реальной работе.
Сразу вспомнилась статья Эти токсичные, токсичные собеседования
Цитата из статьи:
«Ведь нужно проверять фундаментальные знания»
Вы так в этом уверены? Кому именно нужно? Здесь всё же не кафедра университета и не олимпиадный кружок, предлагаю вспомнить, зачем вы вообще ищете человека. Правильно. Писать API, проектировать инфраструктуру, рисовать кнопки, чинить баги, понимать задачу из общения с бизнесом, делать продукт дороже и круче. И делать всё это в срок и за деньги.
  1. Где-то 20% не стали играть. Пока ничего с ними не делаю, возможно втянутся.
  2. Начисление Сил происходит в ручном режиме, поэтому кто-то обязательно лично проверяет проделанную работу.
  3. Хотелось бы ответить, что просадки нет, по факту до 20% времени может уходить на рефакторинг и авто-тесты. Просто мы понимаем, что это инвестиции в будущее. Либо вкладываешься сейчас и потом не теряешь скорость на доработках, либо не вкладываешься, но зато теряешь скорость потом, причем уже с набежавшими процентами.
Если технический долг только накапливается и никогда не отдается, то очень скоро стоимость внесения изменений начнет зашкаливать. Работа, которую можно было бы сделать за несколько часов, будет выполняться несколько дней.
Кстати, о явном выделении рабочих часов на рефакторинг никто не говорит. Суть в применении правила бойскаута:
Всегда оставляйте код чище, чем он был до вас
Это надстройка над обычным рабочим процессом, причём вход и выход свободные. Т.о. ежедневная работа выглядит точно также, просто сотрудник может заодно выполнять квесты, зарабатывать ресурсы и использовать их на свое усмотрение.
На самом деле система получилась никак не связанной с аджайлом. Ее предназначение — обучение персонала, а к чему это «приложить» уже дело каждого.
Спасибо за идею использования матрицы Эйзенхауэра при распределении задач. Подумаю над идеей (стоит себе прикрутить или нет).
Сам пользуюсь maxdone, почему то его никто не упомянул. Инструмент бесплатный и достаточно функциональный.
Не знаю, почему ты решил, что Gherkin меня не впечатлил. Я вполне нормально к нему отношусь и очень даже вижу область его применения.
Цель статьи — показать, что для Gherkin'а неверно выбрана целевая аудитория и что стоит начать продвигать этот инструмент среди тестировщиков aka инженеров по качеству.
Похоже, что в приведенном примере, бизнес-аналитики прокачали или им помогли прокачать скилл проектирования сценариев тестирования.
Уже пару дней как отправил запрос на участие в мероприятии…
Очередной раз предлагаю смерждить проекты в один и дать ему новое название.
Основная мысль из первой части статьи (немного адаптированная для коммента):
Модульные + сценарные тесты — по мне так прекрасная синергия. Я считаю, что для создания высококачественного ПО нужно использовать оба подхода вместе! Совмещенные тесты обоих видов создают отличную защиту от регрессии.

Для этого мне было бы удобно пользоваться одним инструментом, а не несколькими.
Фреймворк тестируется сам на себе, поэтому в исходниках все есть. Например:
API файлового загрузчика нового вида
API файлового загрузчика старого вида
ЭтоНе() выглядит интересно, спасибо! Обязательно попробую применить совет.
Нужно будет только по другому обыграть другие зарезервированные слова (Истина, Ложь, Null, Неопределено) в утверждениях, возможно это окажется легче.
Рассматривал этот вариант. На мой вкус:
Ожидаем.Что(5).Не_().Равно(7);

лучше чем:
Ожидаем.Что(5).Нет().Равно(7);
Потому что почти для каждого утверждения есть свой антипод и тогда нужно будет реализовывать в 2 раза больше утверждений. В текущей реализации любое утверждение можно инвертировать и дублировать ничего не нужно.
1) Написать падающий тест
2) Написать код, чтобы написанный тест прошел
3) Провести рефакторинг
4) goto 1
Сложно как-то не правильно понимать, что такое TDD.

Кто-то проектирует в голове, кто-то на бумаге, я же проектирую в тестах. Видимо у меня мозг заточен по «Кент Бековски», поэтому TDD прижился.
Подавляющее большинство задач, с которыми мне приходится сталкиваться (разработка всякой разной бизнес-логики), эффективно решается test-first подходом. Главное, чтобы слой логики был отделен от слоя UI.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity