Blogger news

Blogger templates

Monday, February 6, 2017

Check your code quality with basic object oriented principles

How do you know you have written good code? Well, what does it mean by good code? To explain it simply If your code is flexible enough to accept any changes without impacting other parts of the system or with very very minimal change then I would say have written good code. Here I will explain few basic principle which you can make your initial checklist to find you have written good quality code and you can find any code smells if it so.
If your code is WET then definitely yours is smelly code
So what is WET? Write everything twice. It is common tendency to copy code from other parts of the system to your working code. Maybe that's to ease your job or to save time or you don't want to think before you write code. No matter what duplicating code is a practice you should avoid for writing good quality code. Think a bit before you write code and always refactor your code before conclude it as a final solution. Always keep in mind there may be several different ways you can improve your code to avoid any kind of duplication. As I told only thing you should do is think before you write.
If your code is DRY then you have written something good
So what is DRY? Don't repeat yourself. It is exactly opposite of WET. I would say you should focus your code to be DRY and that would be the first thing to focus while you write or refactor your code.
If your code is SOLID then you have written an amazing code
Well SOLID means 5 different set of object-oriented principles you should follow if you are writing object-oriented code. If you are following those principles while writing code then I would say you will end up with a good quality code. Let's see each of those principles
S - Single Responsibility Principle: - This means a class should be responsible for doing one thing or there should never be more than one reason for a class to change. It means don't try to write everything in one place or never mix up things together. You should logically group you functionalities and distribute responsibilities to different classes instead of writing things in one place. "It is not the load but the overload that kills"- a Spanish proverb.
O - Open / Closed Principle: - The Open / Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. It means once we have implemented something it shouldn't modify to satisfy additional requirements. One classic example I can think of is, say if you have a "switch case" statement to decide an employee type and some logic based on employee type. What if you want to add another 5 employee type? You will add it to the same "switch case" and so on right. So based on your requirement changes you will modify the logic you have written right? If so you are violating open/closed principle hence yours is not a good design.
L- Liskov Substitution Principle: - The Liskov Substitution Principle states that Subtypes must be substitutable for their base types. It means while you designing a subclass that inheritance should be "is substitutable for " with base class but not "is a base class".
I- Interface Segregation Principle: - The Interface Segregation Principle states that Clients should not be forced to depend on methods they do not use. This means while you implement an interface no client should force to override a method which it doesn't really require. In other words, an interface should never be fat. It should be lean and logically grouped to avoid forceful implementation. Say for simple example if you have class "Ostrich" implemented from the base class "Bird" with functions "Fly" and "Walk" the class "Ostrich" should be forced to implement the function "Fly" which it doesn't require at all as "Ostrich" can't fly.
D- Dependency Inversion Principle: - Dependency Inversion Principle states that High-level modules should not depend on low-level modules. Both should depend on abstractions. This principle is exactly same as the real world scenario of using sockets/switches to connect your electrical devices. Sockets never know which device it is connected to and if you want to connect another device to the same socket you don't want to rewire the complete system. We should design classes exactly in the same way we use sockets to connect devices. All classes should be decoupled in such a way that if we want to remove one class with another one then the class already using that class should never impact or that class should never know which class state and behavior it is using. In other words, details should depend on abstractions.
KISS your code: - I really mean it, always KISS you code. Keep It Simply Stupid, I mean always write what you really want. Don't write too much which makes the code super complex. In other words, write code for the human. The computer can understand whatever you write as long as if you are following correct syntax but good code means human readable and understandable.
Check your unit tests are following the F.I.R.S.T rule (by Robert C. Martin alias Uncle Bob),
F - Fast: - Test should run quickly. If your unit tests are slow then you may not feel to run it frequently. Also, slow tests may be the hint of something smelly.
I- Independent: - Your tests should be able to run independently. It means your tests should not depend on anything else. It should depend on any other classes, files, database etc. When you disconnect all the wires / Wi-Fi still your tests should pass. It means mock all your dependencies
R- Repeatable: - Test should be repeatable, which means you should be able to run tests in any environment or you should be able to run your tests wherever you are. It can be on your dev machine, SIT, UAT, Production or even in your laptop without any kind of connectivity.
S- Self-Validating: - Your test should be independently passed or fail. It means you tests case should be able to validate itself. t should read a database or any other external dependency to decide test is a success or failure.
T- Timely: - It means unit test should write before you write your business logic. It is the same as "Red-Green-Refactor" principle of Test Driven Development, write your test first then it will fail as your actual code is not yet ready. Next, write your code and make the test pass. Make sure you write only a piece code which makes the test to pass. Next, refactor your code to a better design and so on.
Have a happy coding :)

No comments:

Post a Comment