Так делать не надо: какие ошибки совершают Unity-разработчики и как это исправить

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

Поэтому мы решили разобрать самые распространенные ошибки в Unity-разработке, чтобы вы не повторяли их в своей работе.  

1Проблемы с эстимацией задач

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

Что с этим делать?

Работать по спадающей — начинать с главной задачи и постепенно делить ее на маленькие подтаски. Этот процесс называется декомпозиция.

С ее помощью мы планируем выполнение каждой мелкой задачи. Это приводит к более точной оценке выполнения задач, а результат эстимации отдельно каждой из них в сумме и даст нам финальный просчет главного результата. У такого подхода даже есть свое название — WBS (Work Breakdown Structure).

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

2Moonwalking (работа на нескольких фултайм-проектах)

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

Посвящать 16 часов в день двум проектам и при этом успевать отдыхать и восстанавливаться — практически непосильная задача.

И страдают от этого буквально все: вы и обе ваши работы. 

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

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

Что с этим делать?

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

3Преждевременная оптимизация кода

Во время одного из проектов у нас с коллегой разгорелся спор о том, что лучше работает: for или foreach. Он очень тщательно относился к чистоте написания кода, и все переменные, которые я объявлял внутри тела цикла, он хотел вынести за его пределы. Дошло до того, что я объявил 3-5 переменных (bool-флаги, integer-счетчики) очень высоко, потом у меня шел код, потом цикл for.

И когда я читал такой код, то просто терял контекст всех переменных уже до того момента, как доскроллил до самого цикла.

Дело в том, что мой коллега на тот момент не совсем понимал, как работает компилятор того же C#. Он не осознавал, что фактически на устройстве выполняется немного другой код, который был написан нами на C#. Это означает, что если мы объявляем переменную внутри цикла for, то это не значит, что компилятор представит ее в том же виде после компиляции в IL (intermediate language) или в коде C++ (при использовании IL2CPP scripting backend).

Что с этим делать?

Мы советуем не приносить в жертву читаемость кода ради микро- или нанооптимизаций. Главное тут — помнить, что с вашим кодом работают другие люди или через некоторое время будете работать вы сами. Поэтому старайтесь писать чистый и читаемый код, и не забывайте, как работает компилятор C#! 

Читайте также: 40 советов, которые навсегда изменят ваши навыки программирования

4Фейлы в работе с билдами

Фейл билда — очень часта проблема любого Unity-разработчика. Даже у нас она случалась на ААА-проекте Ori and the Will of the Wisps. Что именно произошло? Репозиторий проекта находился на SVN, и это накладывало множество ограничений на удобство использования, особенно на работу в различных ветках. И фишка была в том, что когда разработчик работал над какой-то фичей — ему приходилось коммитить код напрямую в главную ветку develop (в которой одновременно «живет» множество артистов, дизайнеров и других разработчиков). Это подвергало опасности работоспособность текущей ветки и команды в целом, а еще и замедляло или даже приостанавливало работу команды до момента исправления проблемы.

Как мы поступили?

Мы хотели сместить акцент с минимизации поломки на своевременную диагностику проблемы. А для CI/CD существует множество разных систем: Jenkins, Team City, GitHub Actions и другие. С их помощью можно автоматизировать и стабилизировать процесс сборки билдов. Благодаря таким процессам как ревью кода, автоматические билды, тесты, и QA-специалисты могут предотвратить максимум фейлов со сборкой и созданием билда. Главное — не забывать о них!

5Архитектурные упущения

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

А распространение такой проблемы обычно происходит со скоростью света. Система становится настолько жестко сцеплена в комбинации с нечитаемыми сложными зависимостями, что ее поддерживать, а тем более развивать, становится только сложнее. 

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

Как же с этим быть?

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

Тут важно задавать себе простые вопросы:

• Правильно ли я наращиваю новую систему?
• Нужно ли мне подумать про модульность (например, про сборки)?
• Нужно ли мне выделить независимые компоненты оттуда? Зачем это нужно?

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

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

Читайте также: Говорят, что тут даже не надо уметь писать код: чем занимается и сколько получает Unity-разработчик