Month: February 2021

Don’t wait to clean your codebase, keep it clean from the start.  Our team has had problems moving between branches and there are many reasons we have had issues.  Right from the start, none of us cloned the main branch before making our own branches, so we have no matching commit history, therefore we have been unable to merge branches together.

Additionally, we did the one thing that should never be done, we ignored the .gitignore.  Never do that!  Our repository was filled with personal preferences and config files, log files, library files, and large packages that had been downloaded from the Unity asset store.  This in combination with the fact that we started on distinct branches means that there were multiple copies of the files being uploaded and our free GitHub repository almost hit the size limit.  This also meant whenever we tried to change branches, we needed to spend thirty minutes to and hour downloading everything from the branch.  This has been a serious problem, and now is the time for it to stop.

So, this week has been a week of progress, but also a week of organization and cleaning the codebase.  I have spent hours cleaning, merging, and configuring gitignore files.

Configuring .gitignore:

Configuring these files were easier than I expected.  This page was very helpful in learning how via the examples provided: https://riptutorial.com/git/example/885/ignoring-files-and-directories-with-a–gitignore-file.

Cleaning:

Once the .gitignore files were configured, I was able to safely remove any of the files that were now being ignored by git.  If people’s local repository needed the files, it would not remove them, but it also meant that we did not need to download them when switching branches.

Merging:

Since none of our branches shared a commit history, merging was a bit more tricky, but I developed a method that works pretty well.  I simply created two Unity projects, one to be the one that in the main branch, and another that is temporary.  With the temporary project, I could pull any branch that needed it’s code to be merged to the main branch, then could navigate to the local repository and simply copy and paste the files into the main project.  This worked easily because none of us were working on the same files.  I did need to rename one scene before copying it over because it shared a name with the scene from the main branch.

All in all, I probably spent about 6 hours this week trying to clean the codebase.  We should have kept it clean from the beginning, but it has been a great learning experience.  But please, don’t be like us.  Keep your repository clean from the beginning, and above all, don’t ignore gitignore.

This week I did my first code review.  I have never reviewed anyone else’s code before, and this was an interesting experience.  At times, the scope of this project feels insurmountable, but this code review gave me a great amount of confidence that we will be able to complete it.

Xinpeng was responsible for writing code to create, move and destroy the note blocks that will be used for our rhythm game.  The approach he chose was different than I expected, and I think quite elegant, with a waypoint object storing destinations, and the move function causing the blocks to move towards those destinations.  This method could allow us to create unique movements for the blocks as opposed to just a simple straight line.  I had never considered an option like this, but immediately saw the potential.

This simple and elegant solution has given me a great amount of faith in my team, not that I didn’t have faith in them before.  But this has showed me that even when I am not involved at all in a portion of the project, it will be done well.  The code was clean and probably better written than my own.

I also feel I learned a lot from this short exercise.  I learned how important documentation is, because I had no idea what the purpose of the waypoint code was until I read the README file that Xinpeng provided.  I was able to read the code and understand exactly what it was doing, but without the documentation I didn’t know the purpose. 

I also learned about keeping the code clean and a way to structure code that should have been obvious to me.  In the code I reviewed, the Update method was used exclusively to call other methods.  Those methods were all very clearly and descriptively names.  This made it so easy to see what was happening, and in what order.  I am going to implement these as I go forward, because I don’t want others to have to read through messy code.

I was dreading the code review, and honestly didn’t have much faith in the process.  It seemed like it might just be a way to discourage people.  I am pleasantly surprised, and happy to say that I was dead wrong.