Team 1540’s source code, which ran on Quasar and our prototype bot Helios, is available on GitHub!
We ran our robot software department on a code-review setup: everything got developed in a separate branch, pull-requested, and code-reviewed before merge. You can see the log of this on the project page. 107 pull requests!
This ended up working really well for us - it allowed us to edit each other’s code to be higher quality in a way that gave everyone rapid feedback and allowed team members to become much better programmers over the course of the season.
Once the main season was over, it proved slightly less helpful as we made changes at events - we would have to go through everything changed after each event - but it did at least help us keep most transient code from the competitions out of the repository.
We had a robot software team of four, including myself. Using code review might work differently for a department of a different size.
You can take a look at an example chain of code-review, which was for the initial version of mecanum code for our robot. (Make sure to hit Show Outdated Diff wherever it shows up to see old comments made during the process.) You can see how many times we went back and forth with suggested changes and implementing them - if we hadn’t used a code review setup, the improvements, if made at all, would have been made by someone besides the author of the code, so the author wouldn’t have gotten a chance to learn.
Of course, sometimes the code-reviewer is wrong too, in which case they also learn something.
Any questions on our code or on our development process?
(Also, for reference, our code uses the Common Chicken Runtime Engine, our dataflow-based robot code framework, which should explain some of the nonstandard coding.)