I transitioned from Artist who can script to Tech Artist 2 years ago.
In that time I’ve worked in studios where I was the only on-site TA.
In my previous studio, a sattelite studio, I was able to occasionally run my pyhton scripts past other off site TAs and get feedback, but never a formal code review process.
The engineers had regular formal code reviews.
At my current studio, I have no code reviews.
Being pretty new this level of coding, I have a beginners grasp of best practices, common design patterns, and smart, robust organization of code.
I fear I am missing out on potentially helpful feedback.
we do code reviews here using software called Code Collaborator. we have 3 TA here who generally review each other’s work. sometime we loop in a proper programmer for more complicated scripts.
One thing that really helped us was moving the TAs into the programming department, so things like code-reviews became more natural and less crazy sounding. The real programmers get caught up on the languages we use at first, but after a few sessions, things get much more constructive.
1st meeting: “PYTHON REQUIRES THAT YOU FORMAT YOUR CODE LIKE THAT!!!”
…
…
3rd meeting: …something more constructive than complaints about the language…
Being the only programmer I have no one to do code review with, but I’m using Kiln a lot lately for organizing and tracking my code and it has a system for reviews that might be worth looking into.
Helped me switch from SVN to hg also, love the workflow with DVCS!
Bringing this back because I am interested in the topic.
Currently, we do have formal code reviews once a week. Our department has a meeting where I go over some code from a developer (usually an intern but it can be anyone’s). I run the meetings because I am the senior developer. I will also go over useful modules, resources, etc. that I find.
A major reason why I started this is because we have more people writing code, and I wanted to get an idea of what was out there. The meetings have been helpful in that regard. We have had issues in the past with interns writing some pretty questionable code, and the meetings definitely help them. However, I am not sure if the other developers are “getting it” when it comes to best practices. One issue is that many of the other developers are beginners.
Is this the most effective way to do reviews? I want to hear about other approaches.
Here’s what I do… when I can corral people into doing it right. Some people really want reviews, others think they slow one down too much. I’m definitely in the pro-review camp but it can be a hard sell.
Couldn’t agree more that code-reviews, particularly on big pipelines are really important. We regularly submit directly to our clients tools repository in Perforce and having reviews means that not only does their lead TD see what changes there are, but it forces them to look at those changes and accept them. For us thats a crucial step and it helps them to understand updates and the impact those may have on their own code.
When I was working at both Crytek and Eurocom the same thing was in place so I’ve always come to expect code-collab or something similar to be in place, it’s just good practice. Also it’s gives you a buffer so that stupid mistakes don’t go straight into your workflows.
We do peer reviews of each others work as part of the scrum user story / ticket. Technically the person reviewing the work could be anyone in the scrum team, as long as it makes sense. (e.g. Maya specialist for maya code). It works like a mini two person meeting where you present what you have done and why, we discuss pro/cons of the approach, possible risks things that might require more attention, and then we go through the code together. Sometimes we also send the git commit via email / chat before the actual code review. When everything is ok then the name of the person who peer reviewed will be added to the release notes. (Senior dev foo bar has peer reviewed the above change).
I think it works well, in the beginning it took a while to get used to, but it is a great way for developers to share feedback and to come up with better techniques. However we don’t have a formal structure to the review it self (like a form or anything like that, I have worked with bigger game studios who had that in place and then they attached that to the commit on release).