How to avoid Fat Git PRs with massive changes

Fat PRs with massive changes are a huge  and anyoing workitems for reviewers. The question is how to avoid these massive Git pull requests (PR)? But there is a more easy way.

Massiv PRs contains many changed files. If you look more into the detail you can recognize differtent pattern of code changes:

1. Code changes not related to the new function. These changes are clean-ups olf existing code without any relation to the new functionaliity. These changes are caused by the boy scout rule "Every time you work on some code it may get a little bit better." This is called Tidy First.
   
2. Changes that relates to the function but are only preparations for the following implementation. These changes are functional neutral.
3. The new feature itself.
4. Cleanup the new feature code. These changes are also functional neutral.

The idea is to split large PRs into smaller PRs by seperation of these concerns. This keeps PR small an easy to review.

The down-side of these PR seperation of concerns that all code changes are spread over multiple PRs. You review 3 times code that will properly change again. Rool-backs are maybe a little more nasty. 

At the end reviewing 4 PRs looks like extra effort but it isn't because every PR is bound to his own concern. That makes it much easier to review.

Fail Fast vs Fail Early

If you look into Stackoverflow or so, you see tha Fail Fast and Fail Early used as synonyms. But that is not true. Let me just explain it.

Fail Early

Fail Early is working on method level.  The idea of Fail Early is to verify at method entry the parameters. The result is an early return or an early exception. The downside of fail early is that you have multiple exit points. That's why you have to keep your method short. But you have always to keep the method short or you handle different concerns in it.

At the end fail early is a technique to verify method parameters at the start of the method to avoid issues caused by data. The Lombock annotation @NonNull is a simple kind of fail early.

Fail Fast

Fail Fast is working on System Level. It's a technique to improve the resilience of micro services. It's a server side implementation of a circuit breaker. I developed this idea 2014 for a German company but I think many other software engineer also has the same idea. The fail fast pattern could be implemented in diefferent ways and for differen aspects of the software system. Now two examples of the fail fast pattern show the different aspect of it:

Fail Fast Example 1: Health Check

The micro service monitors his own health and if the service in unhealthy maybe because of an unhealthy or not responding subsystem the service can decide of fail fast some related (HTTP) request without going the whole service to the unhealthy state.

Fail Fast Example 2: Performance Check

The micro service monitors his own  request runtime. If the runtime exceeded a timeout the the service can cap the reuqest execution to free resources and response with an (HTTP) error code. This improves the performance resilience of the software system.

If you understand this pattern, you can imagine that are many more cases for Fail Fast.

Over all, the Fail Fast pattern avoid that slow or weak subsystems can shuts down all your services. It's a kind of an circuit breaker apttern.

Summary

• The difference between Fail Fast and Fail early is the Abstraction Level. Fail Fast protects your micro service. Fail early makes your methods more stable. At the end you should use booth.