TFS, Git, Pull Requests and Code Reviews

I have been using Team Foundation Server for a few years now in my day job. Side jobs have also used TFS from time to time. Leveraging GIT and the pull requests to control code reviews has definitely improved my code and the code of my fellow developers.

Communication is hard. Developing software is hard. Communicating and developing software is harder.

The ability to feature branch and merge to different environments to kick off automated builds gives a developer such a deeper look in the happenings of their code base. It improves the ability for multiple developers to work on a code base and have their code work and not wait on someone else to commit. The merge is easily the best part of Git in the .NET developer world. In the past I’ve used SVN and the merging was always complicated and clunky. Feature branching is built-in to the core of Git and TFS shines with Git as the code management feature.

The gate keeping of pull requests to a production environment helps stop bad code from getting into the wild. It is not a silver bullet, but having more eyes on code is always a good function. Utilizing the code reviewer for basic QA services, is a time consuming activity, but the quality of code that is delivered is almost always better. The ability to compare branches against staging, production or other environment ensures everyone is keeping up-to-date.

Speaking of code reviews; it is a function that I believe is critical to deliver software. It is a safety net for a number of different areas:

Reliability

Maintainability

Quality

Communication

Usability

Reliability – Fix those easy bugs that get through code. Simple bugs: order of operations bugs. Typos.

Maintainability – Will someone else understand the code? Is the developer making it too hard?

Quality – Does the developer have the latest version? Has the developer pushed the code to testing / QA?