You need to know Java. Since there are an abundance of online resources already available, I won't write a java tutorial in this document. Instead, use one of these options: here or here or here or here or here or here or here.
FROM THIS POINT ON I SHALL ASSUME YOU KNOW JAVA
The thing about our robots is they need to constantly update from the driver inputs. We accomplish this with loops. As long as the robot is turned on, the robot code is constantly looping. In FRC, the main loop is handled by WPILib. In the Robot.java file generated by WPILib, there are several "init" functions and several "periodic" functions. The init functions run once and the periodic functions run continuously after the init functions. To make life easier, the loops are divided based on the state the robot is in (mainly autonomous or teleop). We can swap between the different modes manually in the driver station when testing. In matches, the Field Management System (FMS) automatically enables/disables the robot in teleop and autonomous at the appropriate times.
You can put all your code in the Robot.java file, using these loops.
FRC Robots usually use a lot of code. If you put it all into Robot.java, you are going to have a giant mess that's very difficult to navigate. So, how do we split things up?
Subsystems are the core of our model for robot programming. Here's how I define a subsystem: a subsystem of your robot is the smallest subassembly of the robot that can do a specific task. For example, the drive base is a subsystem - it drives without needing any other part of the robot. One swerve module is not a subsystem. It can't fill any robot task by itself - It requires the other swerve modules to be useful. If you get your subsystems wrong, you can usually still get everything working. It just makes things more difficult and probably less reliable.
Commands are the other half of our command bassed architecture. They define each action the robot can take. They can then be bound to a trigger (like a joystick button) or be a "default command" that runs whenever no other commands are running.
The nice thing about breaking it up like this is that in our commands, we specify which subsystems the command uses (requires). That allows the Command Scheduler to automatically prevent two commands from trying to control the same subsystem at the same time (which causes very unpredictable results). Instead, whichever command gets scheduled later overrides the command that was running before.
If you forget to define your requirements, then things will go awry. It can be difficult to diagnose if you haven't seen it before.
Please visit this page for more details on using Command Based programming.
Now, I'd take some time to look through this project and see how the subsystems and commands for the swerve drive are defined.