Development Process

KISS

Nobody in programming loves to debug, maintain, or make changes in complex code. “Keep It Simple, Stupid (KISS)“ states that most systems work best if they are kept simple rather than making it complex, so when you are writing code your solution should not be complicated that takes a lot of time and effort to understand.
If your code is simple then other developers won’t face any problem understanding the code logic and they can easily proceed further with your code. So always try to simplify your code using different approaches like breaking a complex problem into smaller chunks or taking out some unnecessary code you have written.

“Make Simple Tasks Simple!” - Bjarne Stroustrup’s

DRY

The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". “Don’t Repeat Yourself (DRY)” principal goal is to reduce the repetition of code. The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.

The opposite of the DRY principle is WET (“write everything twice” or “waste everyone’s time”) which breaks the DRY principle if you are writing the same logic at several places.

To avoid violating the DRY principle, divide your system into pieces. Divide your code and logic into smaller reusable units and use that code by calling it where you want. Don't write lengthy methods, but divide logic and try to use the existing piece in your method.

SOLID

The SOLID principle stands for five principles which are Single responsibility, Open-closed, Liskov substitution, Interface Segregation, and Dependency inversion.

The SOLID principle helps in reducing tight coupling. Tight coupling means a group of classes are highly dependent on one another which you should avoid in your code. Opposite of tight coupling is loose coupling and your code is considered as a good code when it has loosely-coupled classes. Loosely coupled classes minimize changes in your code, helps in making code more reusable, maintainable, flexible and stable.

Law of Demeter

This principle was first introduced by Ian Holland in 1987 at Northeastern University. It is also known as the principle of least knowledge. This principle divides the responsibility between classes or different units and it can be summarized in three points.

- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.

- Each unit should only talk to its friends; don’t talk to strangers.

- Only talk to your immediate friends.

The Law of Demeter helps in maintaining independent classes and makes your code less coupled which is very important in software development to make your application flexible, stable, maintainable and understandable.