What is your guys advice for transition into team based development with github and etc? I currently only have experience as a solo dev or solo scripter on a project and am unfamiliar with the best way to work within a team. What is your guys advice for this?
Good question!
There are a lot of aspects regarding these that are different from normal solo development just inside of Roblox Studio. There’s too much information to go into full detail here, but I will cover the basics.
Git & Github
Generally speaking, you should try to use the following strategies with your git branches:
-
Develop each logical feature on its own branch, separate from other features.
This is really useful since it allows features to be developed & tested separately. In large teams, this is really beneficial since multiple large features can be developed in parallel without any issues! -
Only have one developer per branch. Having multiple developers on a single branch causes a plethora of issues, both technical and interpersonal. The phrase “too many chefs in one kitchen” comes to mind, and it holds true here! Having one developer per branch (and, ideally, per feature) keeps things organized & moving smoothly.
-
Branching strategy is never going to be the same every time, it is very situational and it depends on the context of the state of your project. Sometimes, Feature A and Feature B can both be merged into
masterfrom their pull requests at any point willy nilly with no issue. Sometimes, Feature A has to be merged in before Feature B. Sometimes, a hotfix / patch branch needs to get merged intomaster, then merged into all open pull request branches before they can be merged, etc etc. It’s going to depend on the state of your repository, the context of what your team is trying to do in the project, and more.
Commits should be granular, one commit per logical unit of work. Updated the UI to fix a missing icon? That’s a commit. Added the API Avatar:DoRagdoll()? That’s a commit. Modified the behavior of a function without changing parameters? That’s a commit. The size of a single commit is going to depend on the context of the work that is being done.
Having granular commits not only makes the repository easier to maintain, it also makes the lives of people doing code reviews easier - their brains don’t have to digest massive walls of code, only tiny segments!
Code review
Code review is a very useful tool that can improve code quality & prevent issues from being shipped to production. Generally speaking, code review will be done when someone has filed a pull request targeting the master branch. Code review should be a type of a conversation, where the reviewers and authors discuss problems with the code, potentially fixing them or purposefully leaving them.
For example, let’s say Bob files a pull request. Emily reviews the commits & code in his pull request, and notices that he tacked on an extra parameter in one of the game module APIs : AvatarAbilities:ShootFire(Distance,ExpirationTime). ExpirationTime was the new parameter he added. Emily however, sees this as a problem - there is a function elsewhere in the codebase that handles the cleaning up of fire at a given time, therefore there is no need for a 2nd parameter - it’s a code smell! Emily brings this up with bob in github discussions & discord. Bob explains that he explicitly added that 2nd parameter as a temporary measure - the ability system doesn’t support contextual expiration times for projectiles, so he quickly patched some code to make it support it. The solution was a bit messy, but it’s a one-off implementation for now, it can be refactored later on down the line when more abilities are added! Therefore, it’s not worth the time cost implementing a full solution now, since the code works and is ready to be shipped.
In this example here, you can see the value of code review - a potential issue was caught, discussed, and the relevant people now have it on their radar, even though they intentionally kept it in. This also helps keep technical debt in everyone’s mind!
CI/CD
Having automated CI that runs when pull requests are filed is a massive help, especially on larger teams. Github allows you to automatically block pull requests until things such as linters and unit tests give the code on the pull request a digital “thumbs up”. Humans make mistakes, having automated systems that catch these mistakes can be a livesaver. No one wants to bring down production because they made a basic logic error!
Technical debt
This is a big one, especially with a large team. As a solo developer, you can usually skirt by ignoring technical debt. But in any sizable team (even just four people!), it will pile up very quickly. And it will kill your project, which is not a desirable scenario. Keeping technical debt at bay is usually relatively simple - establish conventions for your codebase, and enforce them. If Bob files a pull request, but his design pattern, the APIs he added, the style, or anything really doesn’t follow codebase conventions - that pull request will be blocked until it follows conventions, unless Bob has a legitimate reason for doing things the way he did. Usually the technical lead / project manager / studio owner (depending on team & company size) will be the ones to establish & enforce conventions. Conventions cover a broad area of how code should be written & added to the codebase - covering the visual code style all the way to the design pattern.
On a bit of a tangent - document the codebase. I will say it again. Document the codebase. If your module has an API method, document it! Put a big comment block above it, describe each of the parameters it takes and what they do, describe what the function does, etc. If the codebase is large, make a static documentation site for it! Alongside API documentation, document overall top-level systems behavior. This makes the onboarding process of new & existing developers on the team much less complicated. No one likes being told “hey, here’s some arbitrary code, you have 5 days to make it do <x>. Have fun!”. Having documentation makes this scenario almost non-existent. In larger teams, there’s always going to be new APIs being added, interfaces being modified, variables being changed. Having documentation allows a developer to understand how to use / modify a system without needing to actually study every detail of its internals, saving lots of time. It also makes the maintainers of that system happy, because there isn’t 50 hands touching it! As stated above, too many chefs in one kitchen is usually an irritating scenario!
Human / interpersonal interactions
Your team is made up of people. People, of course, are all very different - different tastes, likes, ideas on how to approach problems, different sleep schedules, etc. So how exactly does a team function with all of these differences?
There’s a lot of tools & practices that teams can use to make it work. While this alone is its own entire field of study, some of the basics are:
-
Scrum meetings. Scrum meetings might be a useful tool for smaller, broken down teams (4 - 10 people). A scrum meeting is essentially a quick stand-up meeting where everyone discusses what they are working on, what they want to have done by Friday / some date (this will depend on your company’s release cycle interval), and what is currently blocking them from doing their work. Work blockers are resolved first, then normal work is done.
-
Accountability. Hold eachother accountable. Things like Scrum only work if everyone is playing ball, pulling their weight and doing what they need to do. If Bob says “Yeah, I can have
<x>done by Thursday”, but consistently doesn’t, then they’re either bad at estimating (which is ok, it takes practice) or they’re just… not getting work done. Hold them accountable to this (nicely, of course)! Ask them why their goals are usually not met - they might even have a rational explanation! Perhaps some system needed a refactor to meet the requirements, perhaps other technical issues came up, perhaps they were dealing with the loss of a family member, it could be anything! Everyone’s ultimate goal should be to make the project as great as it could be. -
Mutual teaching. More often than not, there’s going to be at least one “senior” on a team who just happens to have more experience, insight & knowledge than other developers on the team regarding a particular topic. Spread that knowledge! If someone on the team doesn’t know something and you do, teach it when it comes up! The better off the team is, the better off you are.
-
Nice work environment. No one wants to work at your typical boring “corporation” where you clock in, do
<work>, clock out, then go home and flop on a bed only to repeat the same thing over again the next day. That’s boring & soul crushing. Keep things fun & interesting for the team! Meme it up, joke during meetings, do events for your community that directly involve the developers, take the day off and have a movie night together, whatever works! The work environment should be a nice place, and the team should be consisting of people that genuinely care about the project. Don’t fill the team with people who just want money, or just want exposure, etc. That will only result in a toxic workplace.
Conclusion
Overall, as mentioned above, this is a very broad topic. I’ve barely even scratched the surface here, there’s lots of great youtube videos, ted talks, and various other lectures on these topics. Ultimately, use what works. If something works great for your team & gets the job done efficiently, use it! Even if it’s not an industry standard, “if it works it works”. The needs of your team, codebase, and overall company will be changing on an almost weekly basis, so being able to adapt to these changes in requirements should always be the ultimate goal when enacting policies, procedures or standards. Don’t get tied down by bureaucracy and red-tape.
4 Likes