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

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.