The fun of refactoring...

Practitioners believes and so am I, that - "coding is Engineering", but "clean coding is an Art". If you are a coding artist, you will enjoy the art of coding by making it refined, and refined multiple times through an excellent skill called - refactoring.

Caution: Refactoring is a double edged sword and should be used with care. Otherwise, the fun can sometime break your software. Hold on for a moment till we get to a solution here.

Having worked with multiple teams, projects and engineers for more than a decade - it's sort of clear that not all teams/engineers see the art of refactoring and the joy of keeping code easy to comprehend and maintain. No worries. There are multiple books, talks, lectures and communities on this topic to google for. The below is an attempt to crisply summarize what I've learned over the years.

Any Tom, Dick and Harry can write a code to solve a business problem. The things that differentiates engineers from other are:

1. Is the unit level code/logic tested against CPU continuously - the unit test. A differential engineer keeps pride of his/her code executing continuously on a CPU in the form of unit test on the build systems (a.k.a Continuous Integration) and also in every other fellow engineers development cycles.
2. Are you sure there was no gold plating done or forgotten to remove? A differential engineer never goes for the gold first. He/She handles all degenerative cases first with sufficient supporting unit test cases driving them. A proper TDD cycle never guides you to do any gold plating in the first place.
3. Test (in)stability on CI - this is a major concern when the team has passionately jumped into writing code with supporting unit tests. Please note that Unit Test is a skill - as important as the coding itself. The instability in the unit tests or any other tests are primarily caused due to under estimating the skill/knowledge maturity needed for writing them. Key learning about tests - make sure the tests are "Readable, Maintainable and Reliable". If you can't write a readable code, you can't write a readable test. If it's not readable, it's not easy to maintain and if it's not easy to maintain, the team starts seeing tests as burdens!! :(
4. Effectiveness of code reviews - A differential engineer seeks active feedback (of course, only when he/she has a open mindset to listen) from all fellow engineers to see the interpretation of their code. The code is good only when most of the people can understand it in one go. As a result, code review helps to reduce all the complexity, unnecessary gold plating in code.
5. Simplicity is the most sophisticated thing - by refactoring the thrive is towards making the code simple, simpler and simplest. The fun is to do the sophisticated thing!

A code should read like a lovely prose to follow, instead of a complex puzzle to solve. Like it is impractical to get any book right in the first attempt which does involve multiple churns and reviews to get it right and readable, the code is no different and follows similar patterns called - Refactoring! :)