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

Проблема с API

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

Несмотря на то, что все в моей команде должны были читать Photon API (наш плагин сетевого кода), я быстро понял, что помимо всей работы, которую они должны были сделать, чтение какого-то плотного, технического и откровенно скучного материала не будет лишним. так продуктивно, как мы думали. API абсолютно полезен, но мы не используем его в полной мере; есть многое, что я мог бы изменить, чтобы работать более привычными способами.

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

Создание оберток API для непрограммистов

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

Имея это в виду, я использовал свой текущий проект в качестве объекта тестирования, чтобы составить некоторые основные рекомендации по разработке API для геймдизайнеров, которым на каком-то этапе разработки придется писать код, но которые не являются волшебниками в этой области:

Четкие имена методов лучше, чем короткие

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

Делайте что-то последовательно

Как упоминалось ранее, многие трения можно устранить, заставив ваши инструменты работать аналогично движку, к которому привыкла ваша команда. Метод, который Photon использует для создания экземпляров объектов в сети, принимает в качестве аргумента путь к префабу; с этим можно работать, но Unity использует ссылки на префабы, поэтому моя оболочка берет имя объекта или ссылку на префаб, а затем находит его по специальному пути, который я сделал, и он работает за кулисами. С точки зрения дизайнера уровней это работает как по волшебству.

Пользовательский код кода

При повторной реализации API-интерфейсов на C# вы можете эффективно использовать инструменты языка для повышения удобочитаемости кода. Используйте необязательные параметры, где это уместно, значения по умолчанию на случай, если кто-то что-то забудет, и даже напишите один и тот же метод несколько раз с разными типами аргументов! Существует также множество вариантов комментариев, которые вы можете использовать, чтобы облегчить жизнь людям, использующим ваш инструмент; Комментарии к XML-документации просто фантастические, и они настолько эффективны, что мои товарищи по команде даже не знали, что я автор.

Обработка ошибок имеет важное значение. При разработке интерфейса программирования для человека, который не является инженером, не думайте, что он поймет, когда что-то пойдет не так. Будьте описательными с ошибками и, в этом случае, сделайте все возможное, чтобы предположить, что человек, использующий инструмент, имел в виду. В моей обертке объекты, переданные в методе «Instantiate», должны быть проверены на наличие компонента «Photon View», если у них его нет, выдается очень описательная ошибка с инструкциями по ее устранению. Кроме того, чтобы предотвратить возникновение этой ошибки, когда дизайнеры добавляют префабы в список сетевых объектов (что-то необходимое для создания их экземпляров в сети), к объекту автоматически добавляется компонент Photon View, если он не найден. Знание того, что он находится в списке сетевых объектов, оправдывает изменение префаба без запроса дизайнера, при этом в консоли появляется сообщение, когда это происходит.

Используйте кнопки, когда можете

Большинство движков гибки, когда дело доходит до пользовательских инструментов редактора, так что используйте их! Если какое-то действие постоянно используется через код с похожими параметрами, сделайте его где-нибудь кнопкой и автоматизируйте! Просто не забудьте добавить всплывающие подсказки, сообщения об ошибках и значения по умолчанию; мы бы не хотели, чтобы инструмент взорвался без объяснения причин, не так ли?

Будьте службой поддержки!

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

Выводы

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