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

Данная статья отвечает на вопрос, где тот корневой критерий в понимании людей, из которого можно затем вывести достаточно полную и достоверную характеристику абсолютно любого человека. Физика становится понятна, когда мы в объяснениях доходим до системы самых элементарных частиц: кварков, электронов и прочих лептонов. Химия стала действительной наукой, когда все элементы были выстроены в систему с базовым элементом водородом, содержащимся во всех прочих элементах. Классификация всех биологических видов стала возможна только тогда, когда был обнаружен базовый элемент любого живого организма — клетка, и к ней был применен эволюционный метод. Так и в "человековедении" первоочередная задача — это найти ту базовую клеточку, из которой раскручивается то невероятное многообразие характеров и типов, присущих людям.

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

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

В прошлый раз мы отделили логику от инфраструктуры и разбили последнюю на четыре слоя: Server → Parser → Application → Repository. Классы инфраструктуры составляют основной фреймворк, который берет на себя всю рутинную работу, а нам предоставляет писать одну только логику.

Логика состоит из контроллеров, которые составляют пятый и пока что последний слой. Они полностью независимы не только от инфраструктуры (им доступно только хранилище), но и друг от друга. Контроллеры — это, на данный момент, базовые единицы бизнес-логики.

Если сильно обобщить, то контроллеры занимаются преобразованием одних команд в другие с сопутствующим изменением состояния приложения (Repository). В зависимости от команды и текущего состояния пользователя Application выбирает соответствующий контроллер и передает ему ссылку на Repository. Контроллер обрабатывает команду, изменяет состояние хранилища и возвращает другие команды, которые должны быть отправлены инфраструктурой по назначению. В общей схеме контроллеры занимают промежуточное место между движком и хранилищем:

... → Application → Controller → Repository.

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

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

При такой организации кода отдельные игры — это лишь соответствующая настройка и использование классов из жанровой библиотеки. Идеальный проект тогда будет состоять вообще из одного main-скрипта в пару строк и yml-файла конфигурации.

О том, как писать классы такого уровня обобщения, чтобы исходный код проектов состоял всего из нескольких строк, как раз и пойдет речь в данной статье:

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

Главная наша задача — совместить несовместимое, выработать такое решение, которое бы позволяло создавать игровые приложения любой сложности качественно и максимально быстро! Сочетание этих несовместимых, казалось бы, условий обеспечит нам фреймворк, эволюцию которого мы и намерены здесь проследить. В первой статье будет описано создание инфраструктурного фреймворка, а во второй — разработка логики на его основе. Всего — две статьи на описание методологии разработки всей серверной части.

В качестве языка программирования выберем Python за его простоту и элегантность. Мы начнем в сокетов (asyncio), а закончим HTTP-сервером. Наша задача состоит в том, чтобы код логики не зависел от типа сервера и задействованных сетевых протоколов.

Прежде мы рассмотрели отделение логики отображения от графики, а также разные вспомогательные классы и менеджеры. Все вместе они образуют каркас наших приложений и были вынесены в отдельную библиотеку — Core Framework. Осталось еще разработать методику по написанию остальной логики. В нее входит бизнес-логики и правила игры, данные и их обработка, а также взаимодействие с сервером.

Вся логика будет разбита на слои. Основной смысл слоев тот, что классы одного слоя максимально независимы от классов с соседних слоев и абсолютно независимы от остальных. Все это уже относится не к основному фреймворку (Core Framework), а к фреймворкам для разных групп жанров (Base Game Frameworks) и для каждого отдельного жанра (Game Frameworks).

Рассмотрев компоненты в общем виде, можно приступить к построению полноценного приложения на их основе. Первым делом нам нужно реализовать смену экранов и показ диалогов. Потом мы добавим возможность конфигурировать приложение и легко подставлять измененные реализации классов с помощью инверсии управления (IoC). Используя IoC-контейнер как контекст приложения создадим возможность запускать параллельно несколько игр в одном приложении, что позволит проводить сеансы одновременной игры, как это делается, например, в шахматах или в онлайн-покере. Под конец мы добавим централизованный доступ к ресурсам, локализации и управлению звуками, а также сделаем свою реализацию для логов и сигналов как более экономичную замену событиям.

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

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

Метод нашей разработки прост. С одной стороны, чтобы избегать дублирования, мы будем выносить блоки кода сначала в цикл или функцию, потом в класс, а затем и в библиотеку. (И так до тех пор, пока у нас не появится фреймворк.) С другой стороны, мы будем ограничивать себя, создавая только тот код, который нужен именно сейчас, не фантазируя наперед о том, что может или не может понадобиться в будущем. Вот простая пара принципов: избегать дублирования и при этом не усложнять сверх необходимого.

Все примеры реализованы на Haxe + OpenFL), но код должен быть понятен всем, кто знаком с семейством языков ECMAScript. Главное же тут не код, а те идеи, которые за ним лежат.

Допустим, мы хотим построить систему команд для игры покер. Но при этом желательно, чтобы она подходила и для других карточных игр, ведь когда-нибудь мы захотим реализовать и их. Более того, хорошо бы реализовать клиент так, чтобы он управлялся с картами без привязки конкретно к покеру, а подходил бы и для дурака, и для преферанса и т.д. Различия в правилах игры существуют только на сервере, а клиент просто получает и отображает всегда одни и те же команды: add, move, remove и другие.

Да и почему только карточных? Разве команды add, move, remove не подойдут для match-3 или стратегий? Для какой игры они вообще могут не подойти, если только в игре есть что перемещать? Вот и получается, что всегда можно подобрать такую достаточно общую и абстрактную систему команд, которая была бы универсальна и подходила для абсолютно всех жанров. Реализация была бы, конечно, везде разная, но названия и параметры — одинаковыми. А значит, не нужно держать у себя в голове кучу протоколов и не нужно тратить время на раскачку, когда переходишь к разработке другой игры. Так, можно одному программисту разрабатывать и поддерживать сразу несколько жанров и не чувствовать себя несчастным по этому поводу. Не говоря уже о серии игр одного жанра.

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

Выше мы рассмотрели, как появились генераторы, как они работают и как их можно использовать в роли сопрограмм. Еще раньше было разобрано, как реализовать асинхронность на колбеках с помощью модуля selectors. Теперь соединим оба материала и реализуем настоящую асинхронность — на сопрограммах (coroutines).

В конце мы создадим минимально возможную версию asyncio и используем ее как лабораторный макет для изучения внутреннего устройства данной библиотеки. Как по мне, это лучший способ понять, как работает асинхронное программирование в Python.

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

Поскольку асинхронность в Python реализована через сопрограммы, или корутины (coroutines), сопрограммы произошли из генераторов, генераторы появились из итераторов, а итераторы были созданы для перебора последовательности, то начнем с перебора последовательности и пройдем всю приведенную цепочку в обратном направлении.

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

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

Но, к счастью, существует и третий вариант — кооперативная многозадачность с помощью системного вызова select и его аналогов (poll, epoll и других). Он позволяет мультеплексировать несколько задач в одном потоке выполнения и в сущности является обычной синхронной программой. А потому никаких дополнительных трат процессорного времени и времени разработчиков не требуется.

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

Дабы исчерпать до дна тему сокетов в Python я решил изучить все возможные способы их использования в данном языке. Чтобы всех их можно было испытать и попробовать на зуб, были созданы 19 версий простого эхо-сервера: от примитивного использования класса socket до asyncio. Блокирующие и неблокирующие сокеты, процессы и потоки, select'ы и selector'ы, коллбеки и сопрограммы — все эти темы расположены в эволюционном порядке, чтобы один пример плавно перетекал в другой.

Отдельно разобрано появление асинхронности в Python. На примерах детально показано, как и зачем появились итераторы, из них — генераторы, сопрограммы. Ближе к концу построен учебный макет библиотеки asyncio с минимально необходимым кодом, чтобы любой (даже такой, как я) смог разобраться, как на самом деле устроена асинхронность, как там все внутри работает.

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

Скорость разработки и качество кода — вот, пожалуй, одно из главнейших противоречий IT-индустрии. Можно долго продумывать архитектуру приложения, потом ее совершенствовать, улучшать, а в итоге так ничего и не сделать. А можно быстро что-то сварганить, а потом и зарелизить, но из-за ошибок проектирования завести весь проект в тупик. На каждые два часа разработки, шесть часов будет уходить на поиск и исправление багов, в результате чего вся последующая разработка фактически застопорится.

Таким образом, вопрос: качество или скорость переходит в проблему: хороший, но вечно незаконченный проект или хоть как-то, но работающая программа. Любой менеджер как реалист, естественно, выберет второе.

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

Как тут быть, что поделать? Попробуем разобраться.