Введение

История началась с хакатона по разработке игр на блокчейне. На старте мероприятия я встретил человека, который в качестве хобби создает настольные деловые игры (я был на плейтесте одной такой игры), мы объединились, вместе нашли команду, с которой за выходные “слепили” простую стратегическую игру. Хакатон прошел, а задор остался. И у нас родилась идея многопользовательской карточной игры о счастье, мировом сообществе и выборах.

В цикле статей будем отражать наш путь по созданию игры, с описанием граблей, на которые уже наступили и будем наступать по мере продвижения вперед.
Под катом будет:

• Краткая информация об игре
• Как принималось решение на чем делать backend. Где это будет “жить” так, чтобы за это не платить на этапе разработки
• Первые шаги в разработке — аутентификация игроков и организация поиска игры (matchmaking)
• Дальнейшие планы

В качестве предисловия

Ты сидишь перед монитором, разбираешь утреннюю почту, и вдруг воздух вокруг начинает дрожать.

— Что происходит?!

Все резко темнеет, и несколько долгих мгновений ничего не видно и не слышно. Только собственный стук сердца. В следующий миг свет возвращается…

— Где я? Что это за место?

Начав говорить, твое внимание привлекает человек в робе с капюшоном, надвинутым на глаза.

— Приветствую, %UserName%, ты в оплоте магов! Мы знаем, что ты способен пользоваться Источником Силы. Я расскажу тебе о нем. Источник содержит пять Сил — Земля, Воздух, Вода, Огонь и Дух. Земля олицетворяет устойчивость, Воздух — свободу, Вода — изменение, Огонь — мощь, Дух — дисциплину. В большинстве случаев для выполнения необходимого действия вполне достаточно какой-либо одной части из пяти. Так потоки Огня позволяют зажечь свечу и контролировать горение пламени. Но более сложные задачи требуют плетения потоков из большего числа Сил. Для примера, тому, кто захотел бы воздействовать на погоду, потребовалось бы сплести одновременно потоки Воздуха, Воды и Духа. Но для того, чтобы начать обучение, тебе придётся пройти испытание...

Сценарий: Определение причин слабой распространенности Gherkin
  Допустим я решил разобраться, почему Gherkin используется небольшим количеством команд
  Когда начал анализ причин
  Тогда понял, что неверно выбрана целевая аудитория

Не так давно среди моих знакомых возник вопрос: “Зачем Gherkin?”. Причем вопрос был поставлен не как вброс на лопате, а чтобы понять его применимость.

Старт обсуждению дал kuntashov в G+ заметкой со следующим содержанием (сюда я привожу сухой остаток, совсем немного подкорректированный мной):

Gherkin был создан, чтобы сценарии использования можно было редактировать как нарратив (повествование), т.е. “почти на человеческом языке” в простой, лаконичной форме и доступном формате. Т.е. назначение формата было — быть в первую очередь лицом к не-технарям, но при этом сохранить более-менее достаточную формальность, чтобы можно было автоматически обрабатывать.

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

Может все же использовать языки, которые больше повернуты лицом к программистам?

Если есть желание совместно разобраться в полезности Gherkin и для кого он предназначен, добро пожаловать под кат.

До релиза новой версии фреймворка по тестированию “xUnitFor1C” осталось совсем немного, а значит пришло время рассказать о проделанной работе и о том, что ожидает пользователей.

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

Зачем все перепиливать?

Насколько я понимаю, на момент, когда проект только рождался, основной целью было понять, насколько модульное тестирование может быть востребовано в среде 1С. Понятное дело, что продумывать и выделять уровни абстракций на этапе прототипирования — дело не особо перспективное. Прототип не обладает эластичностью настоящего кода. Прототип — это эксперимент, результаты которого нужно выбрасывать.

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

Мне нравится метафора Алана Купера:

Создание большой программы можно сравнить с постройкой столба из кирпича. Этот столб состоит из тысячи кирпичей, положенных один на другой. Столб может быть выстроен, только если класть кирпичи с большой точностью. Любое отклонение приведет к падению кирпичей. Если кирпич с номером 998 сможет отклонить на пять миллиметров, столб, вероятно, сможет выдержать тысячу кирпичей, но если отклонение на 5-ом кирпиче, столб никогда не станет выше трех десятков.

Немного истории

Благодаря классному дядьке Кенту Беку (Kent Beck) родилась замечательная методология test-driven development. Не смотря на необычность подхода, переворачивающего привычный процесс написания кода с ног на голову (тест на функционал создается до реализации), сейчас уже можно сказать, что разработка через тестирование стала стандартом де-факто. Практически в любых вакансиях фигурирует требование к знанию и опыту использования методики TDD и соответствующих инструментов. Почему, казалось бы, ломающая привычную парадигму мышления методология прижилась и стандартизировалась? Потому что “Жизнь слишком коротка для ручного тестирования”, а писать авто-тесты на существующий код иногда просто не возможно, ведь код, написанный в обычной парадигме, как правило совершенно тесто-не-пригодный.

Стоит отметить, что за время своего существования методология успела обзавестись ответвлением (fork) в виде BDD. Дэн Норт (Dan North) в своей статье (Introducing BDD) указал на сложности внедрения TDD среди разработчиков и для решения обозначенных проблем предложил практику, которая называется behaviour-driven development. Основной фишкой BDD можно назвать микс из TDD и DDD, которая в начале выражалась в правильном именовании тестовых методов (названия тестовых методов должны быть предложениями). Апогеем BDD, на текущий момент, можно считать рождение языка Gherkin и инструментария, который его использует (Cucumber, RSpec и т.п.).

Наверное, каждый из нас сталкивался с ситуацией, когда нужно выполнить большой объем вычислений или передать/получить большой объем информации за ограниченный промежуток времени. А сколько из нас остановилось на последовательном алгоритме и закрыли глаза на продолжительность выполнения? Ну и что, что 20 часов ведется расчет/отправка/получение (подчеркнуть нужное) каких-то данных? Ну, я «выжал» из системы все, что можно, быстрее не получится… При этом серверное железо загружено на минимум.

На самом деле, почти всегда доступна альтернатива в виде распараллеливания выполняемой задачи. Конечно, параллельные алгоритмы несколько сложнее — балансировка нагрузки, синхронизации между потоками, а так же, в случае разделяемых ресурсов, борьба с ожиданием на блокировках и избегание deadlock’ов. Но, как правило, оно того стоит.

Об этом мы сегодня и поговорим… в контексте 1С Предприятия.

В качестве предисловия

Началось все в феврале 2014 года с приглашения посетить конференцию AgileDays2014. Вечером того же дня я засел на сайте конференции, чтобы выделить интересные мне темы и спланировать посещение докладов. Через 5-10 минут я уже смотрел запись выступления с AgileDays 2013 «Свобода и ответственность» Антона Волкова из Alternativa Platform.

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

Для того, чтобы взрастить чувство ответственности нужно:

• Добровольное принятие ответственности. Например, когда человек сам называет срок выполнения задачи, он принимает ответственность. А если срок спускают сверху ни о каком принятии ответственности речи не идет, она на том, кто спустил срок;
• Свобода выбора — люди в праве решать какую работу брать, выбирать стратегию решения задачи, с кем работать (определяют состав команд);
• Последствия (положительные и отрицательные) от принятых решений, действий и бездействий. Например, сдал качественно выполненный функционал в срок, получил признание коллег и, возможно, дополнительное денежное вознаграждение. Или, допустил баг в продуктовой среде, получи нагоняй и порицание от коллег.