Improve Code Coverage Metric

 I know, every body knows that Code Coverage is a weak metric (Link). But there are two ways to improve the value of he code coverage metrics:

1. Remove all exclusion pattern
2. Remove integration test from the calculation

Point 1 should avoids that you cheat your self.

Point 2 is not so obviously but it's easy to explain. Integration tests ensure that the whole software or larger parts work. Unit tests are the result of TDD and code coverage could measure the TDD impact. That's the reason why only unit tests should part of the code coverage calculation.

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.

Rule: Never Deploy on Friday

 

Many developers know the unwritten rule: Never deploy on Friday. The reason for this rule is that nobody wants to repair a live system at the weekend.

If you live this rule, it's a very good indicator for three things they are wrong in your software development:

1. Your application is not well tested for resilience e.g. with Chaos Engineering tools.
2. Your deployment pipeline is not stable enough or you not trust them and your tests.
3. Your not familiar with roll-backs or you have no feature toggles.

One of the major goal is to trust your software and the test so that you feel comfortable to deploy on every Fridays.

One of my major project goes online on Friday afternoon, most developers was not in the office, with success.