Командная разработка
Командная разработка
Любой дурак способен написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям. — Мартин Фаулер, автор книги «Рефакторинг»
Разработчик не существует в изоляции. По мере роста технических требований игры вам понадобится помощь, и команда неизбежно пополнится специалистами с разными навыками. Чистый код задает стандарты для растущей команды и помогает всем придерживаться общего подхода. Благодаря этому каждый может работать над одним проектом по единым правилам. Прежде чем переходить к конкретным руководствам по стилю кода, вспомним несколько общих, не зависящих от стиля правил, которые помогут масштабировать разработку на Unity.
KISS («не усложняй») Признаем: инженеры и разработчики склонны все усложнять, хотя вычисления и программирование и без того непросты. Пусть принцип KISS — «не усложняй» — помогает находить самое простое решение текущей задачи.
Не нужно изобретать велосипед, если задачу уже решает проверенный и простой прием. В Scripting API Unity есть множество готовых решений. Например, если для вашей стратегии подходит Hexagonal Tilemap, а UnityEngine.Pool удовлетворяет требованиям к пулу объектов, не пишите собственную реализацию. Лучший код — тот, который не пришлось писать.
Принцип KISS Известный принцип KISS ставит во главу угла простоту проектирования. Эта идея была популярна в разные эпохи, что подтверждают следующие высказывания: «Простота — высшая степень изощренности».
— Леонардо да Винчи «Делайте простые задачи простыми!»
— Бьёрн Страуструп «Простота — необходимое условие надежности».
— Эдсгер В. Дейкстра «Все следует упрощать настолько, насколько возможно, но не более того».
— Альберт Эйнштейн В программировании это означает: делайте код как можно проще и не вносите в него лишнюю сложность.
Принцип YAGNI Связанный с ним принцип YAGNI («вам это не понадобится») предписывает реализовывать возможности только тогда, когда они действительно нужны. Не тратьте силы на функции, которые, возможно, пригодятся при идеальном стечении обстоятельств. Создайте самое простое решение, необходимое сейчас, и добейтесь его работоспособности.
Не маскируйте проблему кодом Первый шаг разработки программного обеспечения — понять, какую именно проблему вы решаете. Это кажется очевидным, однако разработчики слишком часто погружаются в реализацию, не разобравшись в сути задачи, или меняют код, пока он не заработает, так и не поняв почему.
Допустим, вы устранили NullReferenceException, добавив в начало метода простую проверку на null. Уверены ли вы, что причина была именно в этом, а не в вызове другого метода где-то глубже в коде? Не добавляйте код лишь для того, чтобы скрыть симптом. Исследуйте первопричину и спросите себя, почему возникает ошибка, вместо того чтобы ставить временную заплатку.
Улучшайте понемногу каждый день Создание чистого кода — непрерывный итерационный процесс. Вся команда должна разделять этот подход и воспринимать наведение порядка в коде как часть повседневной работы разработчика. Обычно никто не намерен писать плохой код — он постепенно становится таким со временем. Кодовая база требует постоянного ухода, поэтому заранее выделяйте на это время и действительно выполняйте такую работу.
Делайте хорошо, а не идеально В то же время не стремитесь к недостижимому совершенству. Когда код соответствует производственным стандартам, зафиксируйте изменения и двигайтесь дальше. В конечном счете код должен решать задачу. Соблюдайте баланс между реализацией новых возможностей и наведением порядка. Не проводите рефакторинг ради самого рефакторинга — делайте это, когда он принесет пользу вам или другим разработчикам.
Планируйте, но адаптируйтесь В книге «Программист-прагматик» Энди Хант и Дэйв Томас пишут: «Программирование больше похоже не на строительство, а на садоводство». Разработка программного обеспечения — живой процесс, поэтому будьте готовы адаптироваться, когда все идет не по плану. Даже самый подробный план сада на бумаге не гарантирует желаемого результата: растения могут цвести не так, как вы ожидали. Чтобы ваш сад процветал, придется подрезать, пересаживать и заменять отдельные части кода. Проектирование программного обеспечения не вполне похоже на архитектурные чертежи: оно гибче и менее механистично. По мере роста кодовой базы вам придется реагировать на изменения.
Будьте последовательны Выбрав способ решения задачи, применяйте тот же подход в похожих ситуациях. Это несложно, но требует постоянной дисциплины. Следуйте этому принципу во всем: от именования классов и методов и выбора стиля регистра до организации папок и ресурсов проекта. Главное — согласуйте руководство по стилю всей командой и затем соблюдайте его.
Качество кода — общее дело Как говорит американский инженер-программист и автор Роберт К. Мартин, известный также как «Дядя Боб», чистый и простой код отвечает интересам всех, но «чисто и просто» не означает «легко». Такая работа требует усилий как от начинающих, так и от опытных разработчиков.
Если ничего не контролировать, проект неизбежно придет в беспорядок. Это естественное следствие того, что множество людей работают над разными его частями. Предотвращать захламление кода обязаны все, поэтому каждый участник команды должен прочитать руководство по стилю и следовать ему.
Developing as a team
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. – Martin Fowler, author of Refactoring
No developer is an island. As the technical needs of your game application grow, you’ll need help. Inevitably, you’ll add more team members with diverse skill sets. Clean code introduces coding standards for your ever-expanding team so everyone is on the same page. Now everybody can work on the same project with a more uniform set of guidelines. Before looking into the specifics of code style guides, let’s revisit some general, style-agnostic rules to help you scale up your Unity development.
KISS (keep it simple, stupid) Let’s face it: Engineers and developers can overcomplicate things, even though computing and programming are hard enough. Use the KISS principle of “keep it simple, stupid” as a guide for finding the simplest solution to the problem at hand.
There’s no need to reinvent the wheel if a proven and simple technique solves your challenge. Unity already includes numerous solutions in its Scripting API. For example, if the existing Hexagonal Tilemap works for your strategy game, or the UnityEngine.Pool solves your object pooling system needs, skip writing your own. The best code you can write is no code at all.
The KISS principle The well-known KISS principle emphasizes simplicity in design, an idea that’s been popular throughout different times, as these quotes attest: “Simplicity is the ultimate sophistication.” – Leonardo da Vinci “Make simple tasks simple!” – Bjarne Stroustrup “Simplicity is a prerequisite for reliability.” – Edsger W. Dijkstra “Everything should be made as simple as possible, but no simpler.” – Albert Einstein In programming, that means keeping your code as streamlined as possible. Avoid adding unnecessary complexity
The YAGNI principle The related YAGNI principle (“you aren’t gonna need it”) instructs you to implement features only as you need them. Don’t worry about features that you might need once the stars align. Build the simplest thing that you need now and build it to work.
Don’t code around the problem The first step of software development is to understand what you are trying to solve. This idea might seem like common sense, but too often developers get bogged down in implementing code without understanding the actual problem, or they’ll modify the code until it works without fully grasping why. What if, for example, you fixed a Null Reference Exception with a quick if-null statement at the top of a method? Are you sure that was the real culprit, or was the problem a call to another method deeper inside? Instead of adding code to fix a problem, investigate the root cause. Ask yourself why it’s happening rather than applying a band-aid solution.
Improve incrementally, every day Making clean code is a fluid, iterative process. Get the whole team into this mindset, and expect code cleanup to be part of your day-to-day life as a developer. Most people don’t intend to write broken code. It just evolves that way over time. Your codebase needs constant maintenance and upkeep, so budget time for that and make sure it happens.
Make it good, not perfect On the flip side, don’t strive for perfection. When your code meets production standards, it’s time to commit it and move on. Ultimately, your code needs to do something. Balance implementing new functionality with code cleanup. Don’t refactor for the sake of it. Refactor when you think it will provide a benefit to you or somebody else.
Plan, but adapt In The Pragmatic Programmer, Andy Hunt and Dave Thomas write, “Rather than construction, programming is more like gardening.” Software engineering is an organic process, so be prepared and adapt for when things don’t go according to plan. Even if you make the most elaborate drawing, designing a garden on paper will not guarantee results. Your plants may bloom differently than you expected. You’ll need to prune, transplant, and replace parts of your code to make this garden successful. Software design isn’t quite like an architect drawing blueprints because it’s more malleable and less mechanical. You’ll need to react as your codebase grows.
Be consistent Once you decide how to tackle a problem, approach similar things the same way. It’s not difficult but will take constant effort. Apply this principle to everything from naming (classes and methods, casing, etc.) to organizing project folders and resources. Above all, have your team agree on a style guide and then follow it.
It takes a village As Robert C. Martin, an American software engineer and author also known as “Uncle Bob” says, although keeping code clean and simple is in everyone’s best interest, “clean and simple” is not the same as “easy.” Clean and simple takes effort and is hard work for beginners and experienced developers alike. Your project will become messy if left unchecked. It’s a natural consequence of so many people working on different parts of a project. Everyone is responsible for pitching in and preventing code clutter, and each team member will need to read and follow the style guide.