Check out my books on Amazon at https://www.amazon.com/John-Au-Yeung/e/B08FT5NT62
Subscribe to my email list now at http://jauyeung.net/subscribe/
Building software requires some basic tools. To build software, we’ll have to use source control and debuggers to track our changes and debuggers to help us step through our code to debug them.
In this article, we’ll look at why and how we should use source control and debuggers.
Source Code Control
We need to check in our code to source control systems so that code change history can be tracked.
This makes reverting our code easy if anything goes wrong.
It’s also very good for letting people review our code since people can see what we changed and compare them.
Also, we can use it to merge people's code together easily. There’s just no alternative way to merge different people’s code together in a systematic way if there are no source control systems to control the merges.
It’s also great since we know who worked on which piece of the code so we can get help on that part of the code from that person if needed.
Furthermore, source control systems let people branch code so that different people can work on different copies of the same code base and apply their own changes.
Once they’re done, then they can merge their changes in after it’s been reviewed.
Always Use Source Control
With all the benefits that source control systems brings, we should definitely use them whether we work by ourselves or within a team.
If we’re working by ourselves, we can track our own change history and revert code to a previous state from the change history if needed.
If we work on a team, then we use the undo feature plus, we can merge things from different branches in an easy, systematic way.
When 2 branches have code that conflicts with each other, then we can fix them with the built-in programs to diff and merge changes by fixing them ourselves.
Another good thing about source control systems is that some systems like Git are distributed.
This means that one copy of the repository is stored remotely in some server outside our computed, mostly remotely, and the other is stored locally.
It a repository is stored in a remote Git host, then we can treat that as a backup.
Source Control and Builds
Source control systems create the possibility to create automatic and repeatable builds.
A computer can automatically check out the code and then build it with an automated system of some kind.
Also, we can run regression tests automatically on that computer to make sure that our code didn’t break anything.
It’s repeatable because we can always check out the code and rebuild the code to create a new build artifact.
Therefore, it’s time to use control. There’s just no excuse not to use them for any sized project.
Debugging
To make our lives easier when we run into issues with our code, we should use a debugger to see what’s wrong.
With a debugger, we can run each line of the code with the debugger and check the values of the variables that are in each step.
Then we can easily see what’s going on in each line of the code.
With that, we’ll see what happens to our code in no time.
In the end, debugging is just problem solving, so we should attack it as such.
It’s not good to blame people. Instead, we should help each other instead of blaming others.
It’s easy to panic if we’re rushed or have a nervous boss or client breathing down our necks.,
However, panicking is just going to make matters worse. We just got to calm down and ignore everyone.
We shouldn’t eliminate any possibility until they can be proven that they can be eliminated.
This way, we won’t ignore anything. For instance, the error that takes the longest to fix may be a simple typo because we have overlooked it when we’re debugging.
Conclusion
Source code control is a must so that we can revert code easily. Also, it lets us work from a branch of the code instead of working on the code itself.
Also, we should use a debugger to debug, don’t panic and don’t eliminate any possibility when we’re trying to find the cause of a bug.