Командная разработка

Командная разработка

Любой дурак способен написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям. — Мартин Фаулер, автор книги «Рефакторинг»

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

KISS («не усложняй») Признаем: инженеры и разработчики склонны все усложнять, хотя вычисления и программирование и без того непросты. Пусть принцип KISS — «не усложняй» — помогает находить самое простое решение текущей задачи.

Не нужно изобретать велосипед, если задачу уже решает проверенный и простой прием. В Scripting API Unity есть множество готовых решений. Например, если для вашей стратегии подходит Hexagonal Tilemap, а UnityEngine.Pool удовлетворяет требованиям к пулу объектов, не пишите собственную реализацию. Лучший код — тот, который не пришлось писать.

Принцип KISS Известный принцип KISS ставит во главу угла простоту проектирования. Эта идея была популярна в разные эпохи, что подтверждают следующие высказывания: «Простота — высшая степень изощренности».

— Леонардо да Винчи «Делайте простые задачи простыми!»

— Бьёрн Страуструп «Простота — необходимое условие надежности».

— Эдсгер В. Дейкстра «Все следует упрощать настолько, насколько возможно, но не более того».

— Альберт Эйнштейн В программировании это означает: делайте код как можно проще и не вносите в него лишнюю сложность.

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

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

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

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

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

Планируйте, но адаптируйтесь В книге «Программист-прагматик» Энди Хант и Дэйв Томас пишут: «Программирование больше похоже не на строительство, а на садоводство». Разработка программного обеспечения — живой процесс, поэтому будьте готовы адаптироваться, когда все идет не по плану. Даже самый подробный план сада на бумаге не гарантирует желаемого результата: растения могут цвести не так, как вы ожидали. Чтобы ваш сад процветал, придется подрезать, пересаживать и заменять отдельные части кода. Проектирование программного обеспечения не вполне похоже на архитектурные чертежи: оно гибче и менее механистично. По мере роста кодовой базы вам придется реагировать на изменения.

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

Качество кода — общее дело Как говорит американский инженер-программист и автор Роберт К. Мартин, известный также как «Дядя Боб», чистый и простой код отвечает интересам всех, но «чисто и просто» не означает «легко». Такая работа требует усилий как от начинающих, так и от опытных разработчиков.

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