Hey guys,

Recently I got my 1 year evaluation at the company I am working at and got some feedback from colleagues about my performance and such as a programmer. The main thing that could be concluded from this (which to me, wasn't that big of a surprise) was that the architecture/design of my code could be improved.

From the feedback provided it was more of a general thing. Odd choices on proper ownership and when/where to execute closely relevant code (for example initiating a death sequence from a separate health class instead of a dedicated class). Anticipating the general architecture/design of project so I don't need to refactor (certain parts of) systems already in place.

I've already had some short talks with others about this subject and it boils down to a couple of things: proper communication in general about the project on where everyone is heading. Discussing made choices with others to see if they have valuable (better) suggestions on design choices and time. With time I mean that most others also said that learning architecture will improve over time when you get more insight of different projects and face certain problems.

Now I really want to get better at this and not just for the companies sake, but also because I simply want to be the best I can be. Some of the lacking parts I mentioned above are being worked on, but I would like to broaden my horizon a bit more and for that I come to ask help of others! I did a little bit of research and it mostly boils down to: Write code and learn from it! This is something I am doing in my everyday job. I would love to know how others improved their design/architecture of their projects. Any literature/websites or general suggestions/pointers are very welcome!

TL;DR

I'm trying to improve my code design/architecture where several persons are involved in the project and would love any suggestions.

Doing this so far:

• Discuss with colleagues
• Write code
• Review code (Both looking at others as getting my own reviewed)

Thanks in advance! :)

P.S.

We're working with Unity3D and C# if that helps.

My share; also review code of others, who didn't get that feedback.
Could be a win/ win: both better synchronized overall code and learn from the other code "ways"

There's many opinions so it's hard to say what they are criticizing or how valid it is. I would ask for as much specificity as possible and see what you can think of. If you have more experienced programmers around you guys should also be talking about design a bit as you go, which is actual software engineering. It should not really come up all of a sudden, but then maybe your issues are pretty minor.


I would get the big book on UML, forget its title. There's a lot of special case stuff and things that are sketchy but look at use cases, and look at object models. Learning that back in college days helped me a lot to be a good designer from the start instead of trying to fix my issues later.


Sometimes I write down pseudocode as well, even if it's an easy process. So you can easily see what you expect to happen, and see what objects interact with what. The worst thing you can do is just arbitrarily say something like "let's make a sound object, graphics object, pathfinding object" and so on. That may be what you actually do, but it's important to understand when you do this that your relational object model is NOT simply "classes you will declare".


You need to look at what the reactions between objects will be, and determine how things should be organized from there. So if you arbitrarily came up with an "event manager" then you can find it has consequences you did not foresee. Soon it is tied into your GUI and into your animation system at the same time, and things are a big mess. If you had thought more maybe you'd come up with something much different.


Mostly I think it takes experience (both in the domain and general experience) to see what will cause a problem, but if you put some serious thought into everything you do (maybe 10% of your time just thinking how to best proceed) then you will improve a lot. If you work at a company with many people that have a lot of what you might call laterally extensive complexity (ie you have many subsystems, many engineers, many code dependencies) you may actually wind up spnding much more time just making sure you are not causing a future catastrophe, than you actually do coding. But for games you can probably get away with 10-20%.


I would try not to go under than unless you REALLY know what you are doing. If you have 20 years experience making game engines you could probably just start coding, but if you don't then you might want to spend a loooong time just figuring out basics like what APIs you will rely on.

Thanks for the suggestions and tips so far!

Yeah I think the most obvious way thing to do is proper communication. There's certainly room from my side when it comes to communication, especially discussing design choices before actually implementing them.

Reviews are something we're already doing, but I have to admit that as of our latest project it has not been followed as strict as it could/should. Though I think I will have to go after that a bit more myself.

Consistency, even if it's bad. It's easier to digest a consistently bad code, rather than reading a mix of good and bad practices thrown in together. For example, it is more frustrating to see code that uses snake_case_for_its_method_names with other methods in camelCase and even lptrHungarianCase mixed in together. If the code is already in Hungarian notation, even if you don't agree with it, keep it in Hungarian.

Luckily, this is not the case. We have coding guidelines we should be following (and actively try to remind others who do not follow them).

But it in order to save time discussing some things it is a good thing to learn about design patterns and the SOLID principles

I think reading up on design patterns is certainly something I could and should do. I did have to read up on the during college, but I must admit that it became rather rusty.