As a software developer version control you will undoubtedly run into version control of any projects which you are working on. Eventually a developer will have to fix bugs or add a feature to a product. In order to learn more about version control there is no better website to learn from than Github.

What is Version Control?

Github gives an amazing allegory: Imagine you’re a violinist in a 100-piece orchestra, but you and the other musicians can’t see the conductor or hear one another. Instead of synchronized instruments playing music, the result is just noise.

Version control is a tool used to prevent this noise from happening. It helps streamline development, keep track of any changes, and allow for upscaling of projects.

Version Control tool factors

Version control may not be necessary depending on the scale of your project, however most of the time it is useful to have it set up. Some of the factors of deciding to use version control include:

• Scalability: Large projects with many developers and files benefit from VC
• Ease of Use: User friendly UI helps manage learning curves and adoption.
• Collaboration features: Supporting multiple contributors and communication between them.
• Integration with existing tools: Using tools everyone already has access to.
• Supports branching: Ability for developers to work on different parts of development benefits a project greatly.

Common Version Control pplications

• Git: Git is an open-source distributed version control tool preferred by developers for its speed, flexibility, and because contributors can work on the same codebase simultaneously.
• Subversion (SVN): Subversion is a centralized version control tool used by enterprise teams and is known for its speed and scalability.
• Azure DevOps Server: Previously known as Microsoft Team Foundation Server (TFS), Azure DevOps Server is a set of modern development services, a centralized version control, and reporting system hosted on-premises.
• Mercurial: Like Git in scalability and flexibility, Mercurial is a distributed version control system.
• Perforce: Used in large-scale software development projects, Perforce is a centralized version control system valued for its simplicity and ease of use.

Final thoughts

Every developer has at one point heard of Git, and without a doubt it may be one of the best developer tool ever invented. I have prior experience using version control but this research was an important refresher to learn from. If you wish to learn directly from Github you can read the article this blog was inspired by here.

From the blog CS@Worcester – Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Sometimes when a program undergoes consistent updates it can get messy, in cases like this it can be useful to refactor it. I’ve had a few experienced cleaning a program however I have never refactored an entire program. The developers over at refactoring guru luckily have a website dedicated to this subject.

Purpose for refactoring

When you refactor a program you are fighting something they call technical debt and create clean code. With clean code comes a few benefits including:

• Obvious for other programmers
• Doesn’t contain duplicate code
• Minimal number of classes and other moving parts
• Passing of all tests
• Easier and cheaper to maintain

What is technical debt?

“Technical debt” as a metaphor was originally suggested by Ward Cunningham using bank loans as an example.

You can make purchases faster If you get a loan from a bank however now on top of principal you have interest. and with time you can rack up so much interest that the amount of interest exceeds your total income, making full repayment impossible.

The same concept can be applied to code. Speeding up without testing new features will gradually slow your progress.

Some causes of technical debt include:

• Business pressure
• Lack of understanding the consequence
• Failing to combat the strict coherence of components
• Lack of tests, documentation, communication.
• Long-term simultaneous development in several branches
• Delayed refactoring
• Incompetence

So when should one refactor?

Refactoring guru comes up with a few instances on when to refactor.

• Rule of three:
  • When doing something for the first time, just get it done.
  • When doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
  • When doing something for the third time, start refactoring.
• Adding a feature:
  • If you have to deal with someone else’s dirty code, try refactoring it first; Easier for future features.
• Fixing a bug:
  • Clean the code and errors will discover themselves
• Code reviews:
  • Last chance to tidy up the code
  • Best to perform these reviews in pair with an author

We know when, but how?

Refactoring is done via a series of small changes, each making the existing code slightly better while leaving the program in working order.

Here is a checklist on refactoring done the right way:

• The code is cleaner
• There should not be new functionality
• All existing tests pass

Final Thoughts:

Overall, I found this website on refactoring to be really informative and would recommend refactoring guru as a starting point. The most important thing that I got out of this is that developers should always try to write clean code or clean code as its undergoing development. Unfortunately sometimes software development can be very time containing and its not always possible which is why refactoring is important.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.