How to rate your code from 1 to 10?

Rating code can be hard. Especially when reports to upper management are required. This can seem difficult and daunting. However, it doesn’t have to be. The following questions can be answered in 5 minutes by someone with as little as 90 days in a code base. Or it can take someone unfamiliar with the code base time to do some spot checks (at least 5).

I’m not saying this is the most accurate measure. Neither is T-Shirt sizing a story. This is a quick generalization that actually works for rating code quickly. I’m not saying a full tech audit should be replaced with this simple questionnaire, but you are less likely to be surprised by a tech audit’s results if this is done this first. Also, this will give plenty of ideas for what to work on.

10 out of 10 Code

This is a simple code quality questionnaire.

Note: If a lead dev can answer this off the top of their head, great, have them do so. Otherwise, this may take time. Each question has some hints underneath with questions that can be answered positive and negatively and how to check some objects. The scoring assumes 5 objects are checked. Spot checking 5 objects from various parts of the code should be enough.

Scoring:

  • Yes = 1 (positive answers and 4 out 5 object checks is a yes, otherwise, it is a no.)
  • No = 0

Questionnaire:

  1. The code has 70% code coverage.
    Just trust your coverage tool. But you should know not all coverage tools are the same. For example, if testing a bool, if only one test exists passing only true or false but not both, one cover coverage tool might call it 100% covered and one might consider it 50% covered.
  2. S = Single Responsibility Principle
    Does each object in your code have 1 responsibility? Check 5 classes from various parts of the code base.
  3. O = Open/Closed Principle
    Does your architecture lend to avoiding breaking changes. Look at a number of check-ins that touch existing code. Do they include breaking changes (i.e. a change to a public signature.)
  4. L = Liskov Substitution principle
    Find inherited classes. Should they be usuing inheritance or should they have been written with a “has a” over an “is a”. Do they have the ability to crash where a parent wouldn’t?
    If you don’t use inheritance because you always use “has a” over “is a” or because you always use interfaces, then give yourself a yes here.
  5. I = Interface segregation principle
    Check your interfaces, are they very small? No more than 5 signatures in the interface on average?
  6. D = Dependency Injection (with most objects using constructor injection)
    Does the code entry points have a composition root? Check 5 classes from various parts of the code base. How many use constructor injection?
  7. Dry = Don’t Repeat Yourself (the inverse of S, not only one responsibility, but no more than one class has that one responsibility).
    Do you have duplicate code doing the same thing? Are there groups of lines copy and pasted in many places, etc.
  8. Cyclomatic Complexity average under 3.
    What are the average number of branches in a method? Don’t know. Spot check 5 methods from different parts of your code. Or just guess based on number of lines in a method. Not including the signature, are the guts of each method 10 lines or less.
  9. The code follows 90% the Joel Test?
    Google Joel Test
  10. The code has a gated CI/CD pipeline including 2 code reviews, build, unit tests, deploy, automated tests, that must pass before check-in is allowed.
  11. Even if you are 0 if your code is working and making your company money, and still selling new customers, give it a +1. Bad code that works is still a solution and is still better than nothing.

What is your code quality score out of 10?

Reacting to the Code Score

These are generalizations about what to do based on your score.

Warning! Neither me nor this blog are your company’s CTO or expert. Each project is different. These generalized suggestions should be analyzed by a company’s CTO and the expert team members the CTO trusts. It is solely their responsibility to make any decisions.

  • If you are 10 out of 10, keep doing what you are doing.
  • If you are 7-9 out of 10, keep doing incremental improvements.
  • If you are 4 to 6 out of 10, you may need to look at your weaknesses and address them as projects, as incremental improvements may not be enough.
  • If you are 2-3 out of 10, you need multiple major refactor projects. Likely you don’t have Dependency Injection. Start your big projects by adding it.
  • If you are 1 out of 10, you need everything refactored, which will be very expensive, and you need to heavily weigh the pros and cons of a rewrite. For both a rewrite or a refactor, much of the code and logic can remain in place. One option is to bring in an expert who can help you follow the strangler pattern to replace your code with new code a piece at a time. If the code is a coupled single piece, there may be prerequisite projects to decouple a piece.

Congratulations on knowing the state of your code.

Leave a Reply

How to post code in comments?