Ошибки разработчиков, которые работают с 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-разработчик
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: