Summary

A brief overview of some things that seemed to come up a lot in interviews and/or things I learned on the job that proved useful. Aimed at intermediate level users.
GitHub

Planning

Planning is arguably the most important part of a project. It makes for faster/more efficient development. Companies use softwares like Jira to organise groups/tasks so it’s a good thing to learn.
Even for smaller projects it’s good to have an outline of the specs just so you have a basic outline.
It also helps with staying motivated. Being able to clearly see the progress you’ve made, as well as granting clear goals for a certain timespan. All will help you finish your projects.

Layered Architecture

A layered architecture refers to the different levels of abstraction in one’s code structure. By having a clear divide between layers we can reduce interdependence and help prevent spaghetti code. A common approach is the five software layers:

1. Presentation Layer: Displays information to users and handles user input.
2. Application Layer: Implements core functionality and orchestrates interactions between different parts of the system.
3. Business Logic Layer: Contains the business rules and logic governing the behavior of the system.
4. Persistence Layer: Manages the storage and retrieval of data from a permanent storage medium.
5. Database Layer: Represents the actual database system where data is stored and retrieved.

In the linked project, we forgo a few layers. We combined the Application down into the Logic layer. We could have kept them split, with the Logic Layer holding the StackManager/Builder and the Application manager handling things like the Camera Controller and Test Stack feature; things directly controlled by the user.
However you do it, it’s important to have separation and (preferably) avoid interactions that skip over layers.

Assemblies

A way to accomplish this is with assemblies. Assemblies are compiled units of code. Usually all the source code in your Unity project will be under Assemply-CSharp.dll but that means changing one file will cause the entire project to be recompiled. This is costly in larger projects.
Breaking up their structure into more organised assembly definitions (even if it’s just by layer) can help reduce compile times as changes only compile files within that assembly (and any assemblies that depend on the one being compiled).
Furthermore they enforce this decoupling of code by only allowing references to happen one way. The UI should be aware of the Logic but the Logic should never care about the UI. It’s the UI’s responsibility to call functions on the Logic and respond to certain events that happen on it.

Solid & Agile

Solid principles are coding principles that can help improve the scalability of your code. A lot of them feel obvious or even redundant, imo. Still, here’s a basic overview of them:

1. Single Responsibility Principle: A class should basically do one thing only
2. Open/Closed Principle: You should be able to expand code without modifying existing code
3. Liskov Substitution Principle: Convinced they just wanted to find an L for the acronym, but the gist is that child classes should be able to replace parent types in code. I should be able to use the Ford class any time I would have used the Car class, for example.
4. Interface Segregation Principle: Basically the same as SRP but for interfaces. A class implementing an interface should (preferably) be using all the aspects of it. Do not make them too large.
5. Dependency Inversion Principle: Classes shouldn’t rely on classes that you use, but instead rely on abstract classes and interfaces. Others take this as far as making every class either Sealed or Abstract.

Agile methodologies are a design promise that about focusing on adaptability and delivering consistently. Working with the clients rather than with your original plan.

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

In addition to being considered a business practice, much of it can be important in your own work. It’s essentially planning ahead for those inevitable moments when a mechanic doesn’t feel good, or you come up with something new and cool. It’s good to build with the future in mind and make sure your code isn’t too spaghetti’d to implement something new.

Design Patterns

Design patterns are simply just named coding practices. You’ve probably used some yourself without knowing they were set in stone by the programming gods many moons ago. A lot of it comes naturally. Like the first time I gave a class a static reference to itself so I didn’t have to link it everywhere, and only found out later that was something called a “Singleton”. Anyway, there’s too many to list, even briefly, so get reading because even if you don’t plan on being asked about them in an interview, they’re good to know.

Self-Commenting Code

Turns out I’ve been ahead of the curve on this one! Except for the whole readability part…
When I learned to code (back when the seas were young) commenting was just another skill to master. Not too many but not too few. That’s no longer the case. Code should be self-commenting. Readable and easy to follow. Sensible and not overly convoluted.
Aim to break functions down (even into local methods) and make sure variable names are consistent and easy to interpret. No BHlthMod but insead BossHealthModifier for example.

Optimisation

Important to show you know about optimisation when looking for a professional role. Things like LODs and mesh culling and using sprite sheets to reduce gpu calls are good to know about.
Along with object pooling and asynchronous programming.
Though note that in Unity, async is actually pseudo asynchronous. It’s not running in parallel/on separate threads as the entire program runs on the main thread (which is why Task.Run() blows everything up).
The more you know!

Last Notes

A portfolio is important. Even a piece of work that is not the best demonstration of your skill is better than no demonstration at all. So get creating!