[Проектирование и рефакторинг, Разработка игр, Игры и игровые приставки] Параллели между Factorio и проектированием ПО (перевод)

Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
18-Авг-2020 09:30

Я уже долгое время работаю проектировщиком ПО и могу с уверенностью сказать — это интересно. Это отличная работа, и я не променял бы её ни на что другое. Это настолько увлекательно, что некоторые люди стремятся передать самые интересные аспекты нашей работы и выразить их в играх.
Я играл в две такие игры. Первая — это Shenzhen.io. Она похожа на то, чем бы мог заниматься инженер, проектирующий встроенные устройства. Инженер решает головоломки путём писания ассемблерного кода для устройств с низким энергопотреблением. В этой игре здорово то, что её разработчики убрали из неё раздражающие аспекты написания кода и его ввода в эксплуатацию.
  • Требования понятны и на удивление точно соответствуют задаче.
  • Цикл редактирования, отладки и компиляции невероятно быстр. Благодаря этому, а также отличной системе тестирования можно за минуту проверить несколько потенциальных решений.
  • Платформа, от которой зависит код игрока (сама игра) не имеет багов. Не нужно чинить зависимости перед тем, как приступать к написанию собственного кода.

Должен ли проектировщик ПО сыграть в Shenzhen.io? Геймплей этой игры не для каждого. Некоторым он «слишком напоминает работу». В конце концов, играя, хочешь расслабиться, а не работать над задачами, которые уже выполняешь по восемь часов в день. Несмотря на это, я считаю, что стоит сыграть, просто чтобы понять, насколько интересной становится задача, когда требования понятны, а средства разработки — быстры. Все знают, что инвестирование в развитие и инструменты оправдывает себя, но удовольствие от игры подкрепляет это ощущение.
Вторая игра — это Factorio, которую выпустили в прошлую пятницу, хотя в раннем доступе в неё можно было играть уже почти четыре года. Те, кто в неё играл, сейчас, вероятно, недоумевают — ведь это игра о постройке фабрики, а не о кодинге. Игрок работает с конвейерами, металлом, нефтепродуктами и создаёт ресурсы, необходимые для изготовления космического корабля.
Извините, данный ресурс не поддреживается. :(
И тем не менее, эта игра больше любой другой напоминает мне о проектировании программного обеспечения. Позвольте объяснить, почему.
  • Технический долг. Создать ли временный «грязный хак» или реализовать всё правильно? Ответ всегда один — это зависит от условий. Хакинг приближает нас к решению текущих задач, но позже нам придётся вернуть долг. Новички (типа меня!) начинают с соединения различных частей базы конвейерами, пока база не начинает напоминать спагетти, похожее на плохо поддерживаемые кодовые базы. Постепенно мы осваиваем способы укрощения этой сложности, поэтому становится проще обдумывать нашу игровую базу/кодовую базу.
  • Принцип «Не повторяйся» (Don’t Repeat Yourself, DRY). Один из таких способов — снижение количества дублируемых элементов. Если нам нужен компонент, который требуется в нескольких местах, стоит ли создать его один раз и использовать повсюду, или копипастить по необходимости? Ответ всегда один — «это зависит от условий». Проектируя ПО, вы иногда используете библиотеку, а иногда копипастите. Это зависит от сложности компонента — пару функций можно скопипастить, а что-то сложное, скорее всего, не стоит. Так и в Factorio — определённый компонент (электронные схемы) производился в 4-5 местах. Я заменил их одним централизованным производственным массивом для упрощения структуры фабрики.
  • Масштабирование. В этой игре часто бывает так, что мы создаём производственный массив, а позже обнаруживаем, что необходимо повысить его производительность в 3-5 раз. Когда такое происходит первые несколько раз, для исправленя ситуации требуется полная переделка с нуля. Когда мы становимся умнее, то начинаем проектировать массивы с учётом пространства для масштабирования. Так же происходит и с ПО — наши системы необходимо масштабировать под гораздо большее количество пользователей, иногда без каких-либо предупреждений. Мы проектируем наши системы, помня об этом.
  • Пересборка. При пересборке компонента в однопользовательской игре или личном программном проекте мы обычно не беспокоимся о кратковременной приостановке работы этого компонента или целой системы. Однако когда я играл в мультиплеер с друзьями, то пытался сделать так, чтобы компоненты, над которыми я работаю, ничего не ломали. Я создал новую нефтеперерабатывающую систему, перенёс новых потребителей на неё, и уже потом вывел из строя старую. Нулевое время простоя!
  • Отладка для поиска первопричины проблем. Наша фабрика далека от идеала, поэтому при добавлении новых элементов постоянно что-то ломается. Поиск первопричин таких проблем — сложная задача, особенно когда их устранение приводит к другим проблемам. Вчерашний пример — нам не хватало электричества, поэтому мы добавили больше котлов, но теперь нужно было исправить водопровод. Исчезла проблема с водой, но появились перебои с углём. Всё это отражает реальную жизнь
  • Командная работа. Большинство задач при наличии времени можно решить в одиночку. Но быстрее и интереснее работать с командой, которая тебе нравится. Можно двигаться скорее, разделяя ответственность по членам команды. У нас, среди прочих должностей, был один ответственный за нефть (я), ответственный за поезда, министр обороны. Другие не занимались тонкостями нефтепереработки, им важен только интерфейс, они используют выходные ресурсы и сообщают мне, если что-то ломается. То же самое происходит с крупными программными проектами — все не могут знать тонкостей работы всей системы. Поэтому каждый изучает API всех компонентов, и только немногие отвечают за реализацию.
  • Исследование. БОльшую часть времени мы тратили на использование уже имеющегося знания, чтобы оставаться в точке локального максимума выработки. Однако один умный игрок потратил какое-то время на изучение новых техник. В нашей игре угольные электростанции нам не подходили, а от ядерной энергетики мы отказались из-за нехватки урановой руды. Я снова обратился к ней, когда нам отчаянно не хватало энергии и мы производили слишком сильное загрязнение. Оказалось, что при правильной реализации даже небольшого количества руды хватает на питание базы в течение 100 часов. То же самое и с ПО — уже готовый стек может работать хорошо, но будет мудро посмотреть, какие ещё есть возможности, и учиться у других. В этом могут помочь и новые члены команды — для них всё новое, поэтому они тратят на обучение больше времени, чем вы. Они могут обнаружить нечто, о чём вы не знаете, и использовать это знание для нахождения более высокого максимума. Свежий взгляд на ситуацию — это всегда хорошо.
  • Автоматизация. Большинство задач можно выполнять вручную, просто это требует времени. Но если вы делаете что-то много раз, то это нужно автоматизировать. Игра мягко подталкивает вас к этой мысли, требуя автоматизации некоторых аспектов. Позже, когда вы разблокируете строительных роботов, всё становится лучше. Вы можете указать им схему спроектированного вами производственного массива, дать им материалы, и они построят всё за вас. Это напоминает мне AWS CloudFormation и похожие инструменты — хоть мы и можем настраивать серверы вручную, быстрее и правильнее будет указать конечное состояние и позволить всё сделать инструменту за вас. Однако если вы разрабатываете ПО, то знаете, что автоматизация — не только средство достижения цели, но и сама цель. Мы реализуем её, потому что это делает нас счастливее, даже если её становится слишком много и мы забываем, чем занимались изначально.
  • Тушим пожар. Иногда бывает слишком сложно реализовывать новые возможности, потому что мы отвлекаемся на устранение сигналов тревоги — такое в командах разработки ПО происходит очень часто. Обычно в таком случае одному члену команды поручают решать проблемы, а другие продолжают работать над расширением возможностей. В игре происходит то же самое.

Но в первую очередь это игра о том, как справляться со сложностью. О том, как проектировать спецификацию и реализовывать системы, соответствующие этой спецификации. О поддержке и постепенном расширении этой системы.
Мне кажется, что игра в Factorio не сделает вас более умелым проектировщиком ПО. Но если вы проектируете ПО, то игра может показаться вам увлекательной. И наоборот — если вы хорошо справляетесь с игрой, то вам определённо стоит попробовать себя в проектировании ПО.
Купить Factorio можно на официальном сайте или в Steam. Если вы хотите попробовать игру перед покупкой, то у неё есть бесплатное демо. (Только один совет — не ждите распродажи. У этой игры никогда не было распродаж, а возможно и не будет.)
Благодарю Минеша Патела для вычитывание черновика и предложения по улучшению статьи.
Комментарии можно прочитать на Hacker News и на reddit.
===========
Источник:
habr.com
===========

===========
Автор оригинала: Krishna Sundarram
===========
Похожие новости: Теги для поиска: #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_razrabotka_igr (Разработка игр), #_igry_i_igrovye_pristavki (Игры и игровые приставки), #_factorio, #_pesochnitsa (песочница), #_sandboxigry (sandbox-игры), #_shenzhen_i/o, #_igry_dlja_programmistov (игры для программистов), #_proektirovanie_sistem (проектирование систем), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
)
, #_razrabotka_igr (
Разработка игр
)
, #_igry_i_igrovye_pristavki (
Игры и игровые приставки
)
Профиль  ЛС 
Показать сообщения:     

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

Текущее время: 22-Ноя 20:34
Часовой пояс: UTC + 5